What's new

Performance measuring program

!REVENGE!

New member
Does anyone know a program that will tell me how many cycles a running application is using? I know the Windows task manager tells you the % but I'm trying to compare several programs that may be under 1%, so I need something that will tell me, e.g. for a NES emulator running Ninja Gaiden is taking 13 Mhz out of your 3000. Starcraft is taking 100 etc.
 

xtra krazzy

Dolphin Developer
AFAIK, there is no reliable source to the cycle count/Hz the CPU has been running a given program. Even the CPU percentage you see in windows' task manager is robustly based on the quanta the kernel gave the specific process.

I would recommend you to keep using the percentage counters, and if you want cycles for a specific program you developed, use RDTSC (the assembly function for ReaD Time Stamp Counter). I think windows wraps it with QueryPerformanceCounter or something.
 
OP
R

!REVENGE!

New member
Thanks for the fast reply, where can I download RDTSC? You said its an Assembly function, unfortunately I'm not a programmer so I doubt I'll be able to do it without step-by-step instructions. If I have a code of assembly text then I need a compiler to turn it into an EXE right?
 
H

h4tred

Guest
You can't download RDTSC.

Its a CPU instruction. Only way you can access it directly is using x86 assembly in a program.

Which means of course, you need a compiler or assembler (if you want to do the program entirely in ASM, instead of via inlined ASM),
 

Toasty

Sony battery
Seems like the Task Manager in Windows 2000 kept track of how much CPU time had been used by a process. (So, for example, if, in five minutes, your process has used only 0.7 seconds of CPU time, it's using an average of 0.23% of your CPU.) Linux monitors like top report this information as well. I don't know if something like that would be adequate for you though, or if something like that is available for the OS you're using.
 
OP
R

!REVENGE!

New member
You can't download RDTSC.

Its a CPU instruction. Only way you can access it directly is using x86 assembly in a program.

Which means of course, you need a compiler or assembler (if you want to do the program entirely in ASM, instead of via inlined ASM),

Which compiler/assembler should I use? Preferably it would be easy to install, as i dont have much space on my drive right now.
 

xtra krazzy

Dolphin Developer
Seems like the Task Manager in Windows 2000 kept track of how much CPU time had been used by a process. (So, for example, if, in five minutes, your process has used only 0.7 seconds of CPU time, it's using an average of 0.23% of your CPU.) Linux monitors like top report this information as well. I don't know if something like that would be adequate for you though, or if something like that is available for the OS you're using.

CPU time is in seconds, and I'm not sure whether converting it to nanoseconds and multiplying it by the processor frequency would help obtain a trustworthy value...
 
OP
R

!REVENGE!

New member
Awesome, thanks Toasty! I installed the program, I select utorrent and I see this:

Priority: 8
Kernel Time: 0:38:15.890
User Time: 0:26:59.671
Total Time 1:05:15.562

What's the difference between kernel and user time? Does this program report the real (not CPU) amount of time the application has been running? utorrent has been running for about a week (I think) which is 168 hours but only took up about an hour of CPU time, so this means that utorrent takes 18/3000 MHz to run on my system, right?

Thanks again for the help!
 

Toasty

Sony battery
I would read Understanding User and Kernel Mode. Don't quote me on this, since I probably knew about as much about this as you before I Googled it, but the conclusion I draw is that kernel time is spent executing in kernel mode, while user time is time spent executing in user mode.
utorrent has been running for about a week (I think) which is 168 hours but only took up about an hour of CPU time, so this means that utorrent takes 18/3000 MHz to run on my system, right?
Roughly, but bare in mind that's just the average usage over a one-week period. It spikes above that from time-to-time, while it idles below it at others. Really, at any given instant, a process is either using your CPU (100%) or not using it (0%). So, the "percentage" of CPU that a process uses can only really be defined when you examine a given time frame and look at how much time the process has spent using the CPU as opposed to not using it.
 
OP
R

!REVENGE!

New member
Roughly, but bare in mind that's just the average usage over a one-week period. It spikes above that from time-to-time, while it idles below it at others. Really, at any given instant, a process is either using your CPU (100%) or not using it (0%). So, the "percentage" of CPU that a process uses can only really be defined when you examine a given time frame and look at how much time the process has spent using the CPU as opposed to not using it.

Whaat? You're saying that doing 1+1 on windows calculator would take 100% of CPU for a moment?

I played with this application for the last couple hours and I compared different codecs (playing an Xvid movie took 200 MHz while playing H264 720p took up 10x more cycles.) I did come across some inconsistencies though: Playing Ninja gaiden 2 on FCEU took 200 MHz and Zelda OOT and Super Smash bros took 950 and 1400 respectively. How can a N64 rom take only a number of times more resources to emulate than a NES rom? I thought the NES was clocked at like 2 Mhz?

Also, Starcraft took 98% of CPU the whole half an hour I played it (was controlling 1000 zerglings at the same time) but I could play the same map with minimal lag on my old P4 with 256 of RAM... WTF????
 

Toasty

Sony battery
Whaat? You're saying that doing 1+1 on windows calculator would take 100% of CPU for a moment?
For an instant (probably best measured in nanoseconds), yes.

How can a N64 rom take only a number of times more resources to emulate than a NES rom? I thought the NES was clocked at like 2 Mhz?
1.79 MHz, actually. :) (1.66 MHz for PAL consoles.) Because the NES is so slow by today's standards, NES emulators need not be heavily optimized to run on most hardware. Most are interpreters, which is a slow, but accurate and easier-to-debug emulation method. The N64 is significantly faster than a NES, and hence N64 emulators need to be better optimized for speed. Most N64 emulators use binary translation (dynamic recompilers), which typically yield much faster execution than interpreters, but are more difficult to debug and get working accurately.

Also, Starcraft took 98% of CPU the whole half an hour I played it (was controlling 1000 zerglings at the same time) but I could play the same map with minimal lag on my old P4 with 256 of RAM... WTF????
Some games are just designed to use all the CPU time they get. (IMHO, this is poor design on modern systems that are capable of so much, but that's just the way some programs are written.)
 
Last edited:
OP
R

!REVENGE!

New member
1.79 MHz, actually. :) (1.66 MHz for PAL consoles.) Because the NES is so slow by today's standards, NES emulators need not be heavily optimized to run on most hardware. Most are interpreters, which is a slow, but accurate and easier-to-debug emulation method. The N64 is significantly faster than a NES, and hence N64 emulators need to be better optimized for speed. Most N64 emulators use binary translation (dynamic recompilers), which typically yield much faster execution than interpreters, but are more difficult to debug and get working accurately.

But what about in the mid 1990s when emulating the NES was a significant hog on most systems? I remember Nesticle and one speedrunner who said there was periodic lag when making his Zelda movie on his 586 system so he had to use his school's/hacker friend's computer.

Some games are just designed to use all the CPU time they get. (IMHO, this is poor design on modern systems that are capable of so much, but that's just the way some programs are written.)

Dude, LAME!
 

Toasty

Sony battery
But what about in the mid 1990s when emulating the NES was a significant hog on most systems? I remember Nesticle and one speedrunner who said there was periodic lag when making his Zelda movie on his 586 system so he had to use his school's/hacker friend's computer.
I guess by the time the emulation scene really took off, processors of that class were already obsolete. If CPUs like that were still top-of-the-line today, I'd venture a guess that we'd see more heavily optimized NES emulators (and no chance of PSX or N64 emulators).
 
OP
R

!REVENGE!

New member
What I mean is, wouldn't they wanna optimize it as much as possible and preserve that trend. Unless it is easier to program interpreter-based systems as you said, then I understand.
 

Exophase

Emulator Developer
One of the problems with your comparison is that you're only looking at CPU clock speed. An emulator emulates much more than a CPU. In the case of NES, the PPU takes a lot more resources to emulate than the CPU because it's more specialized hardware that runs at a much higher clock than the CPU. N64 emulators, on the other hand, offload a lot of the video emulation to a 3D accelerator.

Another problem is that it often takes a lot more cycles to emulate something more accurately. A lot of NES games require much finer tuned accuracy than N64 games do. With that in mind, the best NES emulators are much more compatible than the best N64 emulators. N64 emulators employ major tricks that reduce emulation requirements significantly at the cost of being incapable of emulating some things correctly or some games at all. An N64 emulator that emulates everything at a low level is much much slower than the ones you've used, and even then won't have nearly the timing accuracy that the best NES emulators do (or even most of the not as good ones).

Finally, most emulator authors are only going to emphasize performance if typical hardware requires it. Instead of optimizing their code they'd prefer to spend their time finding/fixing bugs, which is very time consuming in an emulator, and adding features. Optimizing code is not only time consuming, but takes special talents that I don't think every programmer is really good at. Even then, it can make it much harder to ensure correctness of the program, especially while adding new things. Some optimizations, especially those popular in older emulators, are also inherently unportable, preventing the program for being easy to compile for other platforms.
 
OP
R

!REVENGE!

New member
Thanks for all the information, Exophase. I swear, I get better tech support on Emutalk than most tech support forums full of nerd-wannabes who think they know shit but only wanna boost their post count (never understood the point of that?)

Anyway, I never heard of a PPU, but I guess it predates the GPU, and since modern comps got good video cards then why would EVERY aspect of the rom have to burden the CPU? Doesnt the GPU take care of it?
 
H

h4tred

Guest
and since modern comps got good video cards then why would EVERY aspect of the rom have to burden the CPU? Doesnt the GPU take care of it?

The GPU when used by SNES/GBA/NES/C64 emulators just outputs the pixels that are spewed from the emulated PPU. That action in itself (outputting pixels on a screen), does not take much (if any) GPU power at all these days.

But for PS2/GameCube/Wii/N64 emulators these days, the GPU takes much more work. Like as part of the emulation, the GPU will process shaders, do some geometry, process offscreen render buffers, plus other things.
 

Top