PC still playing Amiga catchup

[EvilGuy]

People have problems in this thread sticking to the example.  I can also switch entire frames by changing a video memory ptr on Amiga.  But that isn't the point.

Modern hardware is so powerful that swapping an entire scene out using the GPU can be done so much faster compared to an Amiga swapping two colours around. Legacy Amiga hardware is old and slow.

PC still playing catchup? Sure, if digital, 9pin joysticks are your thing. But the rest of the world has moved on to big and better things.

[ElPolloDiabl]

amigaksi,

The Olympics are over buddy. Let's put out the flame :madashell: and move on to other things.

[amigaksi]

amigaksi,

The Olympics are over buddy. Let's put out the flame :madashell: and move on to other things.

Stop the bullcrap; you're just serving as a biased sidekick like some others.  Be objective and perhaps  you will see such a clear cut point.

[amigaksi]

Still limited to Amiga's memory design and graphic's processor speed. You want to start a frame per second race? Let's see HAM8 vs ....

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.

Should I bring in ATI Xenos?

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.  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.

[amigaksi]

At the end of the day, stick your average PC user in front of:  Amiga OS, Linux, Windows, Mac.

Chances are they will figure out how to get on the Internet on the latter three, but stand no chance at all on the Amiga.  Mainly because they would be lucky if they even had a TCP/IP stack on it.
...

That's a biased comparison.  Internet browsers and websites mainly developed after Amigas stopped manufacturing.  They revised Windows many times to integrate internet and it's bloated websites into it.  I bet if internet was a big thing during Amiga's development, people would have had optimized browsers running on it within its RAM/processor limits.  People develop and optimize for what the target machine is.  

>Come on, lets be realistic.  The point here is, that for the vast majority of user a PC does exactly what they need it to do.  This might mean it can't do a few things the Amiga could do, mainly because they are things your average user does not need to do.  

It's a speculation to say Amiga only does those things PC cannot do that average user does not need to do so.  Many people use PCs today for painting, gaming, etc. can do the same on Amiga.

>The PC is a mainstream "do it all" machine, it makes no sense wasting time and money including backwards compatibility, except wheres its absolutely essential.  

It's absolutely necessary to maintain backward compatibility-- they do it on APi level and I was proposing they do it at hardware level so a programmer can have the best of both worlds.

>That is why they removed 16bit support from Windows some time back, it was no longer useful and just added bloat, bugs and more importantly a LOT of time wasted for the development team making sure it was still compatible with all the new stuff.

16-bit support is NOT bloated.  The entire Windows 3.1 OS fits in 1Megabyte.  Compare this with some application on XP where one of the hundreds of DLLs it uses is 1 Megabyte each.  By the way, the processors still support backward compatibility of 8-bit and 16-bit; it's stupidity not to include it within the latest OS.  

>As we said before, why bother including support for the PC to be able to do stuff that 99.9% of the userbase do not need, and can easily be done on custom hardware more efficiently?  If the Amiga is better at this than a modern PC then excellent, but it also proves the point that it would make no sense using a PC to do it.  Why would you want to use a Ghz CPU eating around 150W of juice, to do something that a custom board could probably do in 10W?

Custom board would have to be put into a PC as well right so the wattage would add up. Someone can make the same argument Amiga can do everything and just needs a custom board for dealing with bloated internet websites/applications.

[the_leander]

Once you accept that Amiga can swap palette indices faster than API-based modern system

You have not provided one shred of evidence to back that assertion up.

It's been bugging me for days as to why I've had this sense of deja vu...

I know where I've read this sort of crap before. Back in the bygone days of Usenet there was a spacker there who was claiming his A4000's 233Mhz PPC cpu was *faster* then a then top end AthlonXP on the basis that the 604 took something like 3 cycles to execute an instruction compared to the XP's 5, whilst ignoring the fact that the Athlon in question ran at over 2.5Ghz.

How are you doing SG?

[amigaksi]

That's a dishonest question.

But I'll bite.

The PC implementation (using API's etc) will be faster doing it's poll than the Amiga's MOVE.W will be. Even if the serial protocol itself is slower, the vastly (and I do mean vastly) faster processor will need less time to execute the whole API based serial poll than the Amiga's MOVE.W will take.

Now, that the serial port on the PC is usually sucky and hence slower to be sampled is another matter, but the fact is that the code driving said sucky serial port is extremely likely to be faster than the MOVE.W.

If only because your 3Ghz machine can execute it's code -literally- thousands of times faster and the API overhead is not adding thousands of times more code.

I wasn't referring to the old serial port-- but USB HID being a serial protocol.  The I/O instructions aren't running at 3Ghz.  In fact, I have experimented a lot with I/O to parallel ports and other I/O instructions and some old machines running at 100Mhz...400Mhz have faster parallel ports than machines running at 1Ghz and above.  Take for example a Toshiba Tecra 8000 at 300Mhz-- it's parallel port gets 1 megabytes/second easily (going direct to hardware of course).  Now take a Thinkpad A31 (1.6Ghz) and it's parallel port gets only 700Kilobytes/second (going direct to hardware w/o bullcrap APis).

So a MOVE.W on Amiga OCS takes a few microseconds consistently.  Using a serial protocol involves a lot more I/O instructions which aren't that much faster as processor speeds are.

[amigaksi]

no if you access the hardware directly you are doing an end run around the os. this introduces the potential for failure on future(or even current) hardware.

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.

[amigaksi]

Modern hardware is so powerful that swapping an entire scene out using the GPU can be done so much faster compared to an Amiga swapping two colours around. Legacy Amiga hardware is old and slow.

PC still playing catchup? Sure, if digital, 9pin joysticks are your thing. But the rest of the world has moved on to big and better things.

As I just explained to someone above, the I/O on modern systems is NOT as fast as the processors (or even memory accesses).  Even if you use GPU, you still have to feed the parameters from host CPU to GPU using API calls.  There's many more things than just joysticks especially if you rely on APi calls on PCs.

[amigaksi]

Depends on the priority. Notice the CPU didn't keep up with the GPU market in pure math performance.

Compatibility is a MAJOR thing to have.  CPUs weren't trying to keep up with GPUs as their target wasn't just pure math performance.  But they did maintain backward compatibility on hardware level.  And I bet hardly anyone would upgrade to a new PC if it WASN'T backward compatible.  You could say why not make people use high level languages (like APIs) with some translation layer and allow processors to start anew everytime, but that's a suboptimal approach.

[amigaksi]

Hi,

@Amigaski,

How did you know I was on drugs, ...

Because of your experiments that you wanted me to repeat:

"Hook yourself up to a 1000V, then 3000V, then 9000V, they 27000V and then tell me at what voltage that your body has sensed a change in?"

>Using the Algorithm that the human body can sense, even if the PC was running at 500 hz the eyes would not see any change in the movement of the cursor even though the Amiga's joystick port was moving at a hz speed of 50% faster. In this case the human body (eyes) would sense a faster movement only if the difference in speed was 3 times faster. Which means that you are probably correct, the joystick does move faster but the human eyes would not see it until it was moving at least 3 times the speed of the PC joytick...  

Using same argument, I can play Amiga games perfectly fine on a 7.16Mhz OCS machine and since the frame rate doesn't miss a beat (as far as user experience goes) I'm better off than buying a 3Ghz machine to do something similar with no guarantees that it may not skip a frame every now and then (especially with a Wifi card plugged in).

[Hammer]

As I just explained to someone above, the I/O on modern systems is NOT as fast as the processors (or even memory accesses).

Still faster than all Amiga hardware.

 Even if you use GPU, you still have to feed the parameters from host CPU to GPU using API calls.  

Complied shader programs are programs. CPU is fast enough to feed the GpGPU e.g. Fold@Home GPU2 client.

[amigaksi]

Hi,

@Trev,

Are you going to surrender the ship, are you going to quit, even though he is totally wrong, ...


smerf

I see your mental attitude is just to try to "win" regardless of what the TRUTH is.  You are totally wrong and misguided.  Your example of using port 201h serially is inferior even to USB HIDs.

[the_leander]

Amigaski/SG as seen earlier in this thread:



Clearly, in need of a liberal application of

[jkirk]

So far no one has shown why API-based systems are superior to hardware level compatibility.  

then you are not reading too well.
the ability to retarget a command IS the advantage. there is no feasable way to have easy to program direct hardware programming that all chips support and still advance at a reasonable rate.

this is what happens in current systems today.

Hardware>driver(translator)>directX(or other standard api)>program

when new hardware comes out all that needs to be made is a driver to translate to the api. this is the strength of the system. yes there is some sacrifice in speed but even with this sacrifice you don't lose much.

you can't have your cake and eat it too.

[amigaksi]

No, I'm in the relevancy camp. No human can trigger a joystick input at 1 kHz, and no mainstream Amiga-compatible display has a refresh rate of 1 kHz. It's really a question of whether or not both an Amiga and a "PC" can sample, process, and respond to an input event in a timeframe that matters to both the application and the end user. In short, they both can.

Limiting the criteria under which either an Amiga or a "PC" can be said to be "still playing ... catchup" is a sad, sad way to win a debate in general terms. NTSC Amigas are faster than PAL Amigas, but that won't stop anyone from arguing over which is "better" in terms of end user experience. Change of subject: PAL Amiga still playing NTSC Amiga catchup?

My one thousandth post should have been more interesting.

It's still relevant though that joysticks are faster on Amiga since you use up less CPU time even if you read them 60Hz.  As for palette modes, I bet it's faster even on modern hardware to set up a paletted mode for editing cartoons, line-art, cad/cam, schematics, and other things that rely on exact coloring and do not want shading which would bloat the file size unnecessarily.  Paletted pictures would compress a lot more losslessly than saving them as 32-bit image files and would be far less data to deal with when editing them.  So in that case, swapping palette indices is a useful feature.  

If you want to argue PAL Amiga playing NTSC catchup-- you have to compare with timers.  Timers are suppose to work at exact rates.  And in that scenario, the Copper method of doing cycle-exact transactions w/ZERO latency is the ideal method of doing it.  Not only is it ZERO latency w/558ns accuracy, but there's not INTERRUPT overhead involved.  No stacks to save current processor conditions and return from interrupt.  Here Amiga wins as well.