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.txt
I make that 171 processes at the moment. You should see it when it is actually busy.
...
So you maintain that running 1 process or 171 processes does not affect the response time at all? That's where your blunder was. It was a simple point not really that significant compared to the point of you not understanding I/O transfers of joystick ports.
>-edit-
I got lucky and I noticed this edit while looking for something else in the thread.
>Oh, and as for the rest of your objection:
>My god, you are living so far in the past it's hilarious. EUAE runs just fine, even on top of that CUDA simulation.
You keep missing the point. Your point is running all those processes DID NOT affect the user responsiveness at all. That is violation of law of conservation.
>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.
It's easier to do in Windows 98SE or older OSes where you can take over the system. And it's easier to do with older systems than newer ones since newer systems have problems installing Windows 98SE because they have too much nonstandard hardware requiring whole slew of new driver database that are more bloated than previous versions.
>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 ...
Never made that claim. Straw-man argument.
>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.
I was wondering when you would ever get around to replying to my point of timing accuracy. Demanding some nanosecond and people having it NOW in their PCs are two different things. Current timers (up to Windows XP era) relied on PIT (8253) using 1.19318Mhz which comes to 840ns. And even that is unuseable given other things happening in the system. And once again you fail to understand I/O bottlenecks interfering with your so-called nanosecond accuracy. Amiga does the 558ns accurate register modifications with little effect on anything else running in the system since it's done via the Copper. For Amiga it's a breeze; for PC, you need to get one of the latest PCs that has implemented the "nanosecond" accuracy which inexorably will have problems given the support for backward compatibility.
>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.
You replied to the same message twice; but anyway, my answer is the same as well-- you need to understand what a PC is. I am a low-level programmer; I hardly use the OS for anything. Whatever software I write is what is potentially possible with the PC.
