PC still playing Amiga catchup

[ElPolloDiabl]

Look here:

http://www.youtube.com/watch?v=HiIr2oJZ0l4

amigaksi vs PC users

[Karlos]

CUDA GPUs have extremely large instruction issue per cycle rate, extremely large registers (e.g. can go up to 512 KByte), super-scalar (dual issue per SP) pipelines, extremely large SMT, caches (both hardware and software managed), high speed memory (and designed specifically for graphics i.e. GDDRx types), Ghz range stream processors(SP), multiple ROPS,Triple digit (e.g. 400Mhz) Mhz dual RAMDACs and 'etc'.

The amount of “Instructions in flight” (both in parallel and sequential(in pipeline)) in CUDA GPU kills any classic Amiga IGP chipset.

You only have to look at the functionality available for CUDA devices:

For Compute 1.0

• The maximum number of threads per block is 512
• The maximum sizes of the x-, y-, and z-dimension of a thread block are 512, 512 and 64, respectively
• The maximum size of each dimension of a grid of thread blocks is 65535
• The warp size is 32 threads
• The number of registers per multiprocessor is 8192;
• The amount of shared memory available per multiprocessor is 16 KB organized into 16 banks
• The total amount of constant memory is 64 KB
• The cache working set for constant memory is 8 KB per multiprocessor
• The cache working set for texture memory varies between 6 and 8 KB per multiprocessor
• The maximum number of active blocks per multiprocessor is 8
• The maximum number of active warps per multiprocessor is 24
• The maximum number of active threads per multiprocessor is 768
• For a texture reference bound to a one-dimensional CUDA array, the maximum width is 213
• For a texture reference bound to a two-dimensional CUDA array, the maximum width is 216 and the maximum height is 215
• For a texture reference bound to a three-dimensional CUDA array, the maximum width is 211, the maximum height is 211, and the maximum depth is 211
• For a texture reference bound to linear memory, the maximum width is 227
• The limit on kernel size is 2 million PTX instructions
• Each multiprocessor is composed of eight processors, so that a multiprocessor is able to process the 32 threads of a warp in four clock cycles

For Compute 1.1

• Support for atomic functions operating on 32-bit words in global memory

For Compute 1.2

• Support for atomic functions operating in shared memory and atomic functions operating on 64-bit words in global memory
• Support for warp vote functions
• The number of registers per multiprocessor is 16384
• The maximum number of active warps per multiprocessor is 32
• The maximum number of active threads per multiprocessor is 1024

For Compute 1.3

• Support for double-precision floating-point numbers

Compare the above with the capability of the copper and blitter combined. I'm not knocking the native amiga hardware, it is capable of all kinds of strange and wonderful things when coded directly but any CUDA Compute 1.0 capable GPU utterly surpasses it potential. It isn't really a fair comparison however.

[jkirk]

The fact that they recently dropped the Gameport and decided to use USB joysticks (which are still slower to read) should tell you that someone is giving a hoot.

perhaps you misinterpret this. there is this movement in the pc world where legacy ports are getting replaced by a single port(to make them cheaper). perhaps that is where the reason lies.

keyboard
at>ps2>usb

mouse
serial>ps2>usb

joystick
joyport>usb

Printer
Parallel>usb

External Modem
serial>usb

see a trend?

[jkirk]

Not if hardware is backward compatible.  You can have well-behaved applications that go directly to hardware.  There's many on PCs as well as Amiga.  It's just that now PCs are more API-centered which is worse for them.

actually you just told us why an api is important.

You can have well-behaved applications that go directly to hardware.

now while that is true just because you can don't always mean you WILL have well behaved programs. as such the api offers an easy way to write a program and Forces you to make the program compliant.

another thing a good api has contingencies in case a function does not work. it is not just about speed but also reliability. operating directly on the hardware could cause an exception which could freeze not only the active program but also lock up the os as well. even if that program was written properly.

[jkirk]

Not everything needs to be retargetted.  It's better to have both API and hardware level compatibility so if you want to retarget go through the API.  Why force people to accept retargetability even if they don't need it and force them to use less efficient means.

simply because there is no one entity that can force all hardware manufacturers to abide in any one standard. as such there has to be a buffer this buffer is the api.

There's not just sacrifice in speed though.  You also have restrictions on what API allows you to do with the hardware.  Many Amiga games wouldn't be possible if they only relied on API calls.

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.

[Roondar]

It's given someone knows high level language and assembly, he can produce more efficient and faster code in assembly since he can better deal with misalignment, registerizing variables, use the flags optimally, etc.

This is simply not true.

Optimizing code is already quite hard to do in higher level languages*. Going to lower levels does not make it easier, it makes it harder because you now have to both choose the best algorithm (where 95-99% of your performance will come from - even the best assembly coded Bubble Sort ever won't beat even the lousiest Visual Basic Heap Sort ever for anything above say a thousand entries to be sorted), the best way to implement the algorithm you chose considering your application requirements and you also have to do that in the best, most optimal way possible in assembly.

Chances are you can do one or two well enough and fail at the other(s).

Not to mention that modern compilers are actually quite good at doing all the things you suggest as they use the same tricks you describe. Or the fact that todays programs tend to be a 'tad' more complicated than something as trivial as sending some bits over a parralel port. When your sourcecode is measured in megabytes you should be damn happy you didn't need to think about how to access the screen to write a few pixels on it but could just call a library to do so and be done with it.

*) This is one of the reasons that optimizing compilers these days optimize your code and their own assembly output instead of just optimizing their assembly output. And contrary to what you might think, the step where they optimize your handwritten code is by far the biggest gain, optimizing the assembly (better/optimal register use, unrolling loops, alignment, etc) gains less in almost all cases.

[Trev]

It's useful until it becomes corrupt and renders the entire system unbootable. And of course, you have to deal with applications that write stuff to it and never remove it (bloating it) and spyware/viruses screwing with it. Continuously reading/writing same file means higher probability of failure of system than reading/writing different files.  I have seen several systems that wouldn't go into Windows because of registry corruptions.  I suppose you can get "lucky" if the back-up didn't get corrupted as well.  However, it would still affect start-up/shut-down times since you could corrupt the registry if you just turn off the machine and restoring it would increase start-up time.

None of those points are specific to Windows or the registry. They affect all systems. I've seen several systems with corrupt registry files as well--several out of tens of thousands. In all cases, the corruption was caused by a disk fault, and all could have been prevented if the end user had been paying attention to the diagnostic warnings generated by the disks.

I've had more issues with corrupt files on OFS/FFS file systems over the last few months than I've had with NTFS file systems over the entire history of Windows NT.

[Karlos]

Man, Karlos I cut you deep with that "Frankenstein" thing back there.  I really am sorry.  Ok. Look you have an "expanded" Amiga.  Better?

*sigh* I guess you have to punctuate all satirical remarks with smilies these days

Actually I did read the guide for executive about a decade ago. From memeory, Executive offers more than one unix-like scheduler.  It offers several, some that have nothing to do with Unix. Which you can select and turn off without rebooting.  Can any other PC OS do this?

The registered version offered several scheduling models based on established models already used by different Unix based operating systems of the day. The non-registered version only has the one basic model.

Now, as for disabling the dynamic task scheduler, the only reason you can do this under AmigaOS is because it doesn't use one by default anyway. Most Unix based OSes don't have a model similar to exec's fixed priority one (by which I mean tasks are assigned priorities that the OS doesn't adjust) simply because it isn't a good model for a many process multi-user system.

As for switching algorithms, the reason you shouldn't have to do this is because the OS should know better than you what every process is up to and what model best fits.

What's better about the new schedulers?

Many things. For instance, modern schedulers have access to far more meta data about processes than Executive did, such as how much memory, IO, swap etc is in use, the load average history, type of load (compute or transpute bound) and so on for every process in the system. These data give them far more to go on when deciding what processes to service immediately and what can wait. They also understand how to distribute load across multiple CPU's and multiple cores on multiple CPU's, which really is not a simple thing to do well.

We had a server go slightly mental after somebody had written some really bad code that essentially fork bombed the machine. It's load average was over 1000 at this point (I think on that revision of the kernel, load averages might even wrap at 1024, so it could have been even higher) and it was over 20GiB into swap. In short, the system was being brought to it's absolute knees with thousands of amok processes constantly trying to spawn further ones and every one of them trying to grab memory. It is a testament to the scheduler that the problem could be fixed through a normal ssh login. Most other OSes would have simply locked up and died long before this.

[alexatkin]

Incidentally, when I say "custom hardware" I was not referring to a PC addon card.  I was referring to embedded designs such as Minimig, that would be a completely dedicated, custom board, designed to do something far more efficiently than a PC can.

Programmable micro-controllers are so cheap these days, people are using them for everything.

I mean, does it really make sense to boot our PCs just to do a sum?  No, we still have pocket calculators (though mostly likely probably use our mobile phones).

[Trev]

however my A1200 multitasks smoothly, and always prioritises my input over anything else that might be needing CPU time.

I'm just randomly jumping in, but that statement is simply not true. Exec's scheduler provides absolutely no guarantees regarding input. I'll grant you this, though: If every Amiga developer wrote solely to published APIs (not directly to hardware) and used priority levels recommended for user-level applications, then Exec's scheduler would give the appearance of prioritizing input over other system activity.

A more advanced scheduler could in fact provide such a guarantee. Exec didn't do anything that any decent workstation OS didn't already do better. What it did do--and we all know this--was provide workstation-like mutlitasking to consumers at a very affordable price. If Exec had done everything BSD, System V, VMS, NonStop, and other contemporary systems did at the time, it would have been outside the budget of all but the wealthiest consumers. (EDIT: And having been cross-developed on SunOS systems, I can't help but wonder if Carl and the rest of the gang weren't tempted to "borrow" features.)

[warpdesign]

however my A1200 multitasks smoothly, and always prioritises my input over anything else that might be needing CPU time.

Really ? Now do this simple test:

1. At idle, open a WB window full of icons (let's say 50).

2. Now run something that eats quite a lot of CPU, let's say 80% (like a video player)

3. Close, and open the same window again

Notice the difference. And tell me again that your input is prioritised...

This is where modern OS perform a lot better. First of all they use cache for any sort of things. So this kind of window wouldn't cause all icons to be reloaded again... Then they scale a lot better with high CPU usage... Something Exec cannot do. Because it's, well, simple...

[stefcep2]

Simply put when the Amiga is running a CPU that is capable of decoding a 1080p Blu-Ray DVD and doing something else at the same time, then I'll believe that it's as fast as a pc or faster.

PC's that are 15 years newer than the last classic amiga that was built have trouble doing this.  What exactly is your point?

[Karlos]

PC's that are 15 years newer than the last classic amiga that was built have trouble doing this.  What exactly is your point?

If by that time scale you mean PC's currently on sale, then I'd only be able to agree with the caveat that the observation it applies to some systems. You can buy/build PCs in the 500 quid range that will manage 1080p playback perfectly well. You don't even need a high end graphics card, my work Radeon X300 with MPlayer under fedora manages it, the principal limitation there is the fact it's a single core P4 (which is pretty much yesterdays kit now).

[stefcep2]

You might want to work on that then, it came across as pure condescension.

Hmm I thought you took it to be an apology.

Varies depending on their system, many folks these days have vender supplied rescue disks they can lob in to restore in the event of a cataclysm, which not only restores the OS, but the applications. Others, perhaps those who bought their systems from smaller outlets might have an OEM disk and effectively have to reinstall their apps all over again. And then of course there are those that build their own.

i was more referring to the endless updates, some of which will result in a non-bootable system (Linux especially), some which will result in hardware not working as well as before (eg I installed the latest Nvidia drivers for my Windows XP PC, and then could only get VESA), most which just plug security holes, a few which add additional features, all of which seem to slow down your PC then what it was before.

Given the vast amount of options Windows supports, what would you propose as a replacement of the registry database? Remembering that both BeOS and Linux have similar systems built into them.

Here's one possibility:  I understand that having drivers for a lot of hardware allows things like plug and play to work.  But it also means you have information on your system about hardware that will never be used. So why not make hardware with built in flash that holds the drivers for that hardware only.  The software in flash identifies the hardware to the OS, the OS then installs the driver off the flash.  Information only relevant to actual hardware that is installed is then stored by the OS.

The stack that came with 3.5 and 3.9 didn't work with my ISP.

Strange.  Its also strange that you installed Idefix with OS 3.5 to get your IDE CDROM to work.  OS 3.5 has an updated scsi.device with atapi support.  If you install OS 3.5 over an existing Workbench 4.0/3.1 that has Idefix installed then the OS 3.5 will use the atapi.device from Idefix.  If you install Idefix after you install OS 3.5, you may get a conflict.  

Dopus 4 was too limited for me. Either way, functionality that I expected, nay, demanded had to be added into the base install.

fair enough.  Personally i find Dopus 4 fine, actually i even use it to manage my Win XP files running it under Winuae.  With the death of the parent company there was very little official OS support, so that fell on third parties like GPSoft.  

In many ways I feel things like the EeePC and Ebox are pretty much there in terms of concept. Macs possibly more so.

I also feel that those small cheep computers will likely pave the way for more appliance like devices that offer base office and web functionality.

actually office and web are pretty much the only thing that the PC will dominate in the future: console games outsell PC games, and despite Mediacentre/MythTV/Viiv the PC doesn't dominate digital TV/DVD/Bluray/PVR's in the lounge room, where consumer appliances rule.

[stefcep2]

Really ? Now do this simple test:

1. At idle, open a WB window full of icons (let's say 50).

2. Now run something that eats quite a lot of CPU, let's say 80% (like a video player)

3. Close, and open the same window again

Notice the difference. And tell me again that your input is prioritised...

This is where modern OS perform a lot better. First of all they use cache for any sort of things. So this kind of window wouldn't cause all icons to be reloaded again... Then they scale a lot better with high CPU usage... Something Exec cannot do. Because it's, well, simple...

Firstly a drawer with 50 icons is not common and indicates bad organisation of his data by the user.

Secondly, I had Cinema 4d do a render, i could instantaneously select the window, close it an re-open it, and the window was populated a little slower than before but I didn't notice the wait pointer, and yes, it executed MY COMMAND, rather then making me click on the close gadget half a dozen times, and then another half a dozen times to open the folder again.

As regards to caching, you can enable directory caching, thats a function of the file system, has been for a long time.  Works even better with SFS or PFS3.

[stefcep2]

If by that time scale you mean PC's currently on sale, then I'd only be able to agree with the caveat that the observation it applies to some systems. You can buy/build PCs in the 500 quid range that will manage 1080p playback perfectly well. You don't even need a high end graphics card, my work Radeon X300 with MPlayer under fedora manages it, the principal limitation there is the fact it's a single core P4 (which is pretty much yesterdays kit now).

i'm talking PC's that were on sale barely 2 years ago.  On my Win XP Athlon 4800+ using integrated graphics, 1080i Full HDTV occassionally skips a frame.  

What else can you do when you play 1080p on the pentium 4?