"Finishing in second place, simply means you are the first loser." - PouyaCat
How can I measure CPU cycles alotted for my process?
Author
The title pretty much says everything - how can I ignore OS-induced CPU overhead and the natural overhead caused by other simultaneously running processes and only measure the number of ticks used by my program. A simple CPU cycle counter tracker (profiler) gives the total number or cycles passed - something which I''m not interested in.
There may be no reasonable way. Even a simple dynamic allocation requires the kernel to find an appropriate place in memory for it. The OS overhead that you speak of isnt truly overhead. It is behind a lot more of your code than you probably imagine.
~Vendayan
~Vendayan
quote:Original post by Vendayan
There may be no reasonable way.
This will be OS specific. KDE on linux has some sort of CPU usage meter which will say how much is kernel mode... check MSDN for windows accessor functions, but note that you can take a look at the task manager under the newer versions of windows, under the processes tab, and it has a category for 'System', with it's own CPU % usage listing. It uses 32K of memory on my box...
. 16K for the System Idle Processes as well ;p.quote:Even a simple dynamic allocation requires the kernel to find an appropriate place in memory for it.
...assuming that the program in question has run out of room in the pages it has allready requested/gotten. Memory is only partially managed by the OS.
quote:The OS overhead that you speak of isnt truly overhead. It is behind a lot more of your code than you probably imagine.
And probably not quite as much as you think from what I gather from your second quote
. And overhead is overhead, but it necessary and unavoidable overhead, unless you optimize your use of OS functions and calls.-Mike
edit: also compare privilaged to usermod useage using PerfMon...
Start->Run: PerfMon
Main Graph area->Right Click->Properties->Data Tab->Add...
Use Local Computer coutners...
Performance Object: Processor
Ctrl+Click: % Privilaged Time & % User Time.
You could also check out Performance Object: Process/Thread for more details about specific programs or their threads.
Just some FYI data.
-Mike
[edited by - MaulingMonkey on February 27, 2004 2:51:26 AM]
If you are programming for an NT-based version of Windows, you might want to have a look at GetProcessTimes().
Author
Thenks guys - finally got some time to check out what you suggested.
Good news: GetProcessTimes() roughly does what I'm after.
Bad news: the unit of measuerement is too big - it only returns process creation, exit, user and kernel times with millisecond resolution. I'm after CPU clock counts for periods ranging from ~0.1 to ~6 ms...
edit: strike that - I'm an idiot for not reading the remarks section - the resolution is 100 ns - more than enough for me.
[edited by - crispy on February 27, 2004 4:58:14 PM]
Good news: GetProcessTimes() roughly does what I'm after.
Bad news: the unit of measuerement is too big - it only returns process creation, exit, user and kernel times with millisecond resolution. I'm after CPU clock counts for periods ranging from ~0.1 to ~6 ms...
edit: strike that - I'm an idiot for not reading the remarks section - the resolution is 100 ns - more than enough for me.
"Finishing in second place, simply means you are the first loser." - PouyaCat [edited by - crispy on February 27, 2004 4:58:14 PM]
As long as you''re sure you''re not accessing the kernel you could try disabling the CPU''s interrupts... as far as I at least some interrupts can''t be disabled at all.
Execute the assembler instructions "pushf" and "cli" in that order before the piece of code you want to measure, and use "popf" aftwerwards (pushf and cli in that order).
OpenGL and DirectX calls, as well as Win32 API calls, and file access mess things up. It can''t hurt to try this (I think) but I wouldn''t trust it. The OS manages paging and important hardware interrupts, disabling them can have undesirable effects on your program. Critical tasks such as burning CD''s while playing with the interrupts don''t look like a good idea to me.
[ Galactic Conquest | Bananas | My dead site | www.sgi.com | Goegel ]
Execute the assembler instructions "pushf" and "cli" in that order before the piece of code you want to measure, and use "popf" aftwerwards (pushf and cli in that order).
OpenGL and DirectX calls, as well as Win32 API calls, and file access mess things up. It can''t hurt to try this (I think) but I wouldn''t trust it. The OS manages paging and important hardware interrupts, disabling them can have undesirable effects on your program. Critical tasks such as burning CD''s while playing with the interrupts don''t look like a good idea to me.
[ Galactic Conquest | Bananas | My dead site | www.sgi.com | Goegel ]
Author
Thanks for the suggestion, Kurioes.
However, for the time being, the following code acts really strangely:
Basically, calling it several times with odd intervals yields the same reusult (even when adding a Sleep(1000) between the two calls. Is this GetProcessTimes()'' doing or is the fault in my own code? The debugger confirms the numbers - they don''t seem to change from call to call to this function.
However, for the time being, the following code acts really strangely:
FILETIME CreationTime, ExitTime, KernelTime, UserTime; HANDLE Handle = GetCurrentProcess(); if(!GetProcessTimes(Handle, &CreationTime, &ExitTime, &KernelTime, &UserTime)) WinError("exit stage left"); LARGE_INTEGER Kernel, User/*, Creation*/; //Creation.QuadPart = CreationTime.dwHighDateTime; //Creation.QuadPart = (Creation.QuadPart << 32) | CreationTime.dwLowDateTime; Kernel.QuadPart = KernelTime.dwHighDateTime; Kernel.QuadPart = (Kernel.QuadPart << 32) | KernelTime.dwLowDateTime; User.QuadPart = UserTime.dwHighDateTime; User.QuadPart = (User.QuadPart << 32) | UserTime.dwLowDateTime; LARGE_INTEGER Result; Result.QuadPart = Kernel.QuadPart + User.QuadPart; CloseHandle(Handle); return(Result);Basically, calling it several times with odd intervals yields the same reusult (even when adding a Sleep(1000) between the two calls. Is this GetProcessTimes()'' doing or is the fault in my own code? The debugger confirms the numbers - they don''t seem to change from call to call to this function.
"Finishing in second place, simply means you are the first loser." - PouyaCat
Author
Hmm - I think I know what the problem is, although I''m a bit unsure. The probable cause is the fact that no system messages are processed between calls to GetProcessTimes(), which means the respective structures aren''t updated (which sound about right). How can I force the OS to update the process'' time structures without generating too much overhead (one solution would be to send the window some message, and wait until it goes down the pipeline, but that would hardly be efficient)?
"Finishing in second place, simply means you are the first loser." - PouyaCatThis topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
