Thanks for clarifying. You are just using some souped up graphics card. Nothing to do with PC running 100s of processes. And you forgot to answer the rest of the message.
And you still violate the law of conservation even with quad core since there's still some overhead involved.
Wrong. There were > 100 CPU processes, not GPU processes. There was precisely one CPU process for that simulation. "ps aux wwwf | less" is hardly going to report on GPU processes, now is it? :roflmao:
Four of those CPU processes are capable of being in the run state concurrently provided they aren't making atomic operations on the same area of memory. Which is highly unlikely because this is a virtual memory system. Most of the processes have no idea the others exist, let alone have the opportunity to lock something they own.
Just for you, I've dumped the current process list. Too big to post here, so here it is:
process.txtI make that 171 processes at the moment. You should see it when it is actually busy.
-edit-
Oh, and as for the rest of your objection:
I doubt even more that you can have EUAE running on top with PCI bus busy as it is. Why only look at the processor speed-- there's other things Amiga can do besides compare processor speeds. Why don't you try reading the joystick at 1Khz while doing all those things? Why not time things to cycle accuracy while your running your PCI transfers? I can't even time a 500Khz event on the latest PC without synchronization going off if I have a WIFI card plugged in (not even surfing the web).
My god, you are living so far in the past it's hilarious. EUAE runs just fine, even on top of that CUDA simulation.
If you can't time a 500khz event properly on your PC without sync going off it's probably because you are either
1) Using a crap OS (which given the rest of your assertion I'm assuming is windows)
2) Using a crap PC. Harder to verify, but not impossible.
As for your claim the machine is somehow too maxed out with the simulation to run EUAE. try reading the specifications for PCI Express 2.0 16-lane and then come back when you've understood it. Total bandwidth for a single 16 lane device is ~8000MB/s. The simulation was only shifting around 400MB/s. Plenty of room left to shove EUAE's framebuffer into the primary X display.
I'm using a decent OS on good hardware. It may have escaped your attention back there in the 1980's, but present day POSIX compliant systems now require
nanosecond accuracy for timing. The Linux kernel uses a busy loop to calibrate the maximum execution speed of your CPU at boot time. With this, you can, if you need it, have a busy wait that is accurate to a few machine cycles, though it will cost you load.
Oh by the way, PCs do slow down to a crawl because so much viruses/spyware comes into the PC easily because no one knows exactly which file is meant for what and whether it's in its original state or tampered
Well, again, you are failing to differentiate the OS from the machine. For the nth time, Windows != PC. Use a decent OS, you don't get these problems.