PC still playing Amiga catchup

[the_leander]

Something like it, but it does not change the scheduler itself

Being able to switch modes was your big "win" for the Executive drop in replacement for the Amiga. You can't replace Exec with Executive and not have the Amiga in question reboot in order to change it.

, but merely gives you one of two choices.  You might call it Scheduler-Lite, you know, the margarine of scheduling GUI's.

It fulfills the requirement of being able to fundamentally change sheduling within the OS without requiring a reboot. Interesting that since I pointed to it you're now trying to dismiss it as something lesser when it clearly matches the original complaint.

firstly do KNOW or merely suspect?  Secondly I doubt it would interest non-coders to dabble with the kernel source code.

rotfl. Re read what you've written there, now compare it to what you're accusing everyone else who disagrees with you of doing.

[stefcep2]

Being able to switch modes was your big "win" for the Executive drop in replacement for the Amiga. You can't replace Exec with Executive and not have the Amiga in question reboot in order to change it.

Err I remember that you need to restart the Executive *server* when changing schedulers, not reboot.  But I already said it doesn't matter either way, as it only takes 5 seconds longer, so who cares really?

It fulfills the requirement of being able to fundamentally change sheduling within the OS without requiring a reboot. Interesting that since I pointed to it you're now trying to dismiss it as something lesser when it clearly matches the original complaint.

Changing the scheduler to one of seven different types is not the same as changing the behaviour of a single scheduler.


rotfl. Re read what you've written there, now compare it to what you're accusing everyone else who disagrees with you of doing.[/QUOTE]

AGAIN.  ANSWER THE QUESTION:  DO DIFFERENT PRECOMPILED SCHEDULER MODULES EXIST AND CAN THEY BY SIMPLY DROPPED INTO THE LINUX KERNEL?  IF SO WOULD THE AVERAGE USER PREFER THIS TO A SIMPLE DOUBLE-CLICK INSTALLATION?

[koaftder]

Err I remember that you need to restart the Executive *server* when changing schedulers, not reboot.  But I already said it doesn't matter either way, as it only takes 5 seconds longer, so who cares really?


Changing the scheduler to one of seven different types is not the same as changing the behaviour of a single scheduler.


rotfl. Re read what you've written there, now compare it to what you're accusing everyone else who disagrees with you of doing.

AGAIN.  ANSWER THE QUESTION:  DO DIFFERENT PRECOMPILED SCHEDULER MODULES EXIST AND CAN THEY BY SIMPLY DROPPED INTO THE LINUX KERNEL?  IF SO WOULD THE AVERAGE USER PREFER THIS TO A SIMPLE DOUBLE-CLICK INSTALLATION?[/QUOTE]

Average user doesn't care one way or the other. Average user doesn't even know what a scheduler is. Folks who do care are usually configuring machines to provide services, and a kernel recompile is a hell of a lot easier to deal with than tweaking apache or mysql for optimal performance.

[the_leander]

Err I remember that you need to restart the Executive *server* when changing schedulers, not reboot.  But I already said it doesn't matter either way, as it only takes 5 seconds longer, so who cares really?

Executive is a service within the OS, when switching between modes yes, sure it'll need to stop and restart, just like the windows scheduler. Ripping out Exec and replacing it with Executive is different altogether, and as such you're not comparing like for like.

Changing the scheduler to one of seven different types is not the same as changing the behaviour of a single scheduler.

By that omission you've just discounted Executive, since that is precisely what you're doing.

AGAIN.  ANSWER THE QUESTION:

NO U.

See, I can act a complete twunt too with caps.

[bloodline]

Changing the scheduler to one of seven different types is not the same as changing the behaviour of a single scheduler.

AGAIN.  ANSWER THE QUESTION:  DO DIFFERENT PRECOMPILED SCHEDULER MODULES EXIST AND CAN THEY BY SIMPLY DROPPED INTO THE LINUX KERNEL?  IF SO WOULD THE AVERAGE USER PREFER THIS TO A SIMPLE DOUBLE-CLICK INSTALLATION?

You have to remember that scheduling algorithms available now are far in advance of what was available back in the 90's... as Karlos correctly pointed out, the amount of metadata the algorithm can call upon in Linux/WinNT/OSX is huge, these OSs use very complex dynamic system to ensure a fair spread of CPU time (across multiple cores!)... If you could add such a system to the Amiga Exec (you can't since much of this metadata relies on memory protection etc) then you could compare...

-Edit- What I'm trying to say is that swapping out the schedular on a modern system doesn't make much sense... You are basically complaining that the new Ford Mondeo doesn't have anywhere to stick the crank handle...

[EvilGuy]

but they haven't, and at least some of them want a different scheduler to the standard one Linux gives them, but the the closest they have is to make you use a different kernel.

Executive for AmigaOS simply tried to bring over some of the UNIX scheduling abilities; UNIX already has fairly fine grained control over processes and prioritys ranging from userspace (ie, nice, renice ..) through to the POSIX system calls.

But really this is irrelevant; when I ran Executive on my Amiga, I left it at the defaults that the application recommended and forgot about it. The same applies pretty much with the stock kernel that Linux distros ship with. Somebody else has picked some decent settings and for 99% of the users they'll leave it as is.

It's only relevant to people when try to prove that a system that has had no development on it for the past 15 years is suddenly better then the latest tech.

[ElPolloDiabl]

I feel cheated the floppy has been left behind... Oh wait you can have adf files.

2GB USB flash drive ~$15. Pack of ten floppy disks ~$5. PC floppy drive ~$15

I think that is the definition of obsolete.


Notice: To be taken as directed. Please read the label and consult a Doctor if symptoms persist.

[Hammer]

That's the chaotic scenario now because they are BASING STANDARD on APIs.  Preivously, all manufacturers were complying with hardware standards-- look at PS/2 keyboards and ports, look at parallel ports, look at VGA/EGA/CGA cards, look at serial ports, look at floppy drive interfaces at 3F0..3f7h, etc.  By the way, even now there are devices that are based on hardware standards based on ACPI specification.  So whoever thinks it's not doable nowadays is just speculating.

Ahem, you did forget firmware’s role?

An ACPI system consists of a series of ten tables. These ten tables define which devices are present on the system and what their capabilities are as they relate to configuration and power management. These tables are built by the system BIOS at boot. When the system boots, it looks for specific entries contained in two of these tables (the Fixed ACPI Description table [FACP] and the Root System Description table [RSDT]) to determine if the system is ACPI compliant. This information is extracted from these tables in the form of an OEM ID, OEM TABLE ID, OEM REVISION, and CREATOR REVISION. If these tables are not present or the information contained in the descriptors above is invalid, the system is assumed to be non-ACPI and the legacy hardware abstraction layer (HAL) is installed.

For Windows, google "ACPI HAL"(hardware abstraction layer).

>this is true however as these new features come into existance the api is updated with functions that allow you to use the features that programmers need and want implemented. as such those games are still possible you just need to be creative with what you have.

You are more restricted with APIs;

It fosters rapid GPU hardware development.

 APIs are slower and inefficient.  APIs are more inexact.

Depends on APIs.

[bloodline]

It fosters rapid GPU hardware development.

This is true, having a standard API allows designs to improve rapidly, The Amiga hardware went basically unchanged for 8 years... the C64 even longer... but your average nVidia GFX chip has a product life cycle of 6months!!!

Can you imagine how much work it would take to ensure that 30 generations (assuming a new product every 6 months since 1994) of hardware compatibility was included in the latest chip?

[Hammer]

It depends on what instructions you try to do in parallel.  If you do an IN AL,DX then TEST AL,128 obviously, you processor has to finish the IN instruction however long it takes.  I was giving case where using AMIGA direct access outdoes PC going through API since API is more restricted than going directly to PC hardware.

One could develop a better mouse driver. There's nothing stopping you developing a better mouse driver.

Logitech's SetPoint software allows a user to set polling rates as high as 1000Hz.
Another 1000Hz poll enabled gaming mouse is Razer's DeathAdder/Mamba.

One the reasons in purchasing a gaming PC mouse is it's poll rates.

USB Mouserate Switcher 1.1. enable poll rates of +3000hz.

[Roondar]

It depends on what instructions you try to do in parallel.  If you do an IN AL,DX then TEST AL,128 obviously, you processor has to finish the IN instruction however long it takes.  I was giving case where using AMIGA direct access outdoes PC going through API since API is more restricted than going directly to PC hardware.  So, you can't draw the conclusion that API access will be still faster than Amiga going direct to hardware.  If API call was just doing the exact thing you would have done with the hardware, then you can say the overhead is minimal given processor speed of PC.  Also for input like USB input of joystick or gameport input of joystick, you will be doing multiple I/O instructions whereas Amiga does one.

Unless it's interupted during the IN AL,DX by say, the task scheduler and gets to do something else. IO is almost always done in an synchronous way on PC's. And I'm pretty sure that waiting on the joyport/parrallel port/serial port/whatever port doesn't actually stop me (and therefore the processor) from doing other things.

I don't know what you mean by parallel port controller is primary cause of slower ports.  It's not.  Parallel ports are usually PCI in the latest machines that have them; however, there are other I/O ports like 60h..64h (keyboard) that are much slower.

I misread which port you where talking about.

[Hammer]

Once you accept that Amiga can swap palette indices faster than API-based modern system, we can looks at other examples where Amiga wins.  I am not contesting you have more graphics horsepower overall in modern graphics cards but in some cases Amiga still wins when you look at time spent by CPU especially if you are going through APIs.

The APIs doesn’t hinder the compute performance. Modern desktop host CPUs are sufficiently fast enough to feed the GPU. Remember, modern GPUs are superscalar, pipelined, higly paralleled and highly threaded architecture.

With current CUDA processor, you can have 768 active stream threads per 8 SP cluster i.e. the front-end is larger than the available stream units. My Geforce 9500M GS GPU (32 SPs) can have 3072 active threads.  

 Frame per second race is also as easy as setting video memory pointers on Amiga.  I believe we had some of this discussion before-- regarding playing .anim files and decompressing them on-the-fly using a double-buffered approach.  Time to switch between frames is just for flipping pointers.

CUDA processor has multiple texture address units. You did not address "frame per second" rate. Comparing Amiga's play back capabilities against ATI's UVD and NVIDIA's PureVideo is laughable.

[Roondar]

CUDA processor has multiple texture address units. You did not address "frame per second" rate. Comparing Amiga's play back capabilities against ATI's UVD and NVIDIA's PureVideo is laughable.

I'm beginning to think that amigaksi is actually not debating the actual time needed in some of his examples, but purely how many processor cycles it takes to achieve them. I could be wrong here, but if he does it would explain some of his objections.

Needless to say, this is not a very good way to look at things. Almost everything in modern computers (and that includes setting up the GPU) is IO limited and not processor limited. Severly so. Even onboard RAM is considered 'very slow' by the processors of these days. And that doesn't even go into the effects caches, multicore, pipelining, branch prediction, etc have on just how many cycles something takes to do.

In essence the IO overhead limits or even outright negates any API overhead you might incur.

[Hammer]

I'm beginning to think that amigaksi is actually not debating the actual time needed in some of his examples, but purely how many processor cycles it takes to achieve them. I could be wrong here, but if he does it would explain some of his objections.

He basically implies, that today’s engineers are dumb and stupid. He didn't factor in the overall performance of the system. Refer to my posted PS3 RSX shader example in relation to instruction pairing.

Needless to say, this is not a very good way to look at things. Almost everything in modern computers (and that includes setting up the GPU) is IO limited and not processor limited.
 

In terms of computation intensity, Geforce 9400 IGP kills Core 2 Quad using the same memory bus.

[Roondar]

He basically implies, that today’s engineers are dumb and stupid. He didn't factor in the overall performance of the system. Refer to my posted PS3 RSX shader example in relation to instruction pairing.

And all of that is only considering the hardware side. The whole argument breaks down on the software level anyway - software these days is so much more complicated that you don't want to think about the hardware while writing it (to such an extent as is possible). You don't want to think about the endianness of your processor, the type of harddisk controller you are interfacing with, etc, etc.

You only want that level of control when absolutely needed and not as a basic requirement to write software. You don't want all that added headache when you are writing your enterprise-class ERP product or multi-gigabyte multimedia program (something like, say, World of Warcraft). This is the real reason API's are such a good thing and it's one that is being completely glossed over.

In terms of computation intensity, Geforce 9400 IGP kills Core 2 Quad using the same memory bus.

Indeed, though I will add that the average GPU is not in all situations a good CPU (even though you can run code on them). The reverse is, however, never true. Even a really fast CPU is still not going to beat a GPU at its tasks.

And it doesn't change anything about my statement, really (except maybe the bit about GPU access). If main RAM is too slow for your CPU that means your CPU is not going to be computation limited but IO limited instead. Let alone how many wait states you'd introduce by getting data of a stupendously slow thing like a harddisk or even worse, a USB mouse.

Lucky us programming evolved beyond polling until it's done in most cases and, wisely, this is only done these days when it can't be helped (or you have a bad programmer ).

[ElPolloDiabl]

He basically implies, that today’s engineers are dumb and stupid.

Speaking of Engineers does anyone know if the original 3DFX creators are still at the helm of NVidia?

I'm asking because the attempts I've seen to emulate reflections and shadows in 3D games is pretty dodgy.