I am trying to time my code performance.
I used clock() to time. However, it does not product precise timing. So, are there any function that I can use to get precise timing on code performance?
I am trying to time my code performance.
I used clock() to time. However, it does not product precise timing. So, are there any function that I can use to get precise timing on code performance?
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
I found a timer in the following post.Originally Posted by Dave_Sinkula
http://cboard.cprogramming.com/showt...ighlight=rdtsc
However, I cannot use the function RDTSC, even if I copied the following:
Code:#define RDTSC(llptr) { \ __asm__ __volatile__ ( \ "rdtsc" \ : "=A" (llptr) \ ); }
Why do you think that clock() is imprecise? Maybe it is, but I'm wondering what evidence you have.
I am timing code of short runtime, for example
Thus, clock() is not enough to do so and I got time = 0Code:for(i = 0 to 10) data[i] = i;
> However, I cannot use the function RDTSC, even if I copied the following:
Well perhaps if you actually mentioned your OS/compiler (or even the error messages), then perhaps we could suggest something more suited for you.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Visual Studio C++ is used in my program. The OS is window XP.
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
With Windows, the operating system does not update the time_t structure every single millisecond. It gets updated every 30-50 milliseconds. I always forget the exact update-rate... And it might depend on what other processes are running.Why do you think that clock() is imprecise? Maybe it is, but I'm wondering what evidence you have.
Evidence??? I don't have the reference handy, but if you write a little experimental loop that displays the time in milliseconds you will find that the same number is shown over-and-over, and then it will jump by several milliseconds, hold that value for awhile, jump again, etc.
With Windows there are better functions (maybe GetTickCount() ) but timing is never 100% accurate on a cooperative multitasking OS like windows. (I believe you can do precise timing by writing a kernel-mode driver which can completely "take-over" the CPU.) In general, you have to use a Real Time Operating System (RTOS) for accurate short-time timing.
In a PC, there is a dedicated hardware clock (oscillator) for all of the timing-critical stuff like audio, video, serial I/O, etc. (If you look at a soundcard or video card, you will usually see a crystal.) And, there is a buffer between the data bus and the critical-time hardware to keep the data moving smoothly when the data bus is interrupted.
EDIT -------------------
...That's going to take much less than 1ms.
Last edited by DougDbug; 05-31-2007 at 02:51 PM.
I think it might be every 18.2 milliseconds, but that's just a wild guess.With Windows, the operating system does not update the time_t structure every single millisecond. It gets updated every 30-50 milliseconds. I always forget the exact update-rate...
Personally, if I want to time something, I often use a profiler. (A profiler counts the number of times each function in your program is called, and shows how long was taken in each function, so you know which area of code is makig your program slow.) I use gprof with GCC. I have no idea what one could use with MSVC, but I'm sure there's something out there. *googles it* Actually, it looks like a profiler comes with MSVC. http://www.google.ca/search?hl=en&q=...ler+msvc&meta= Have you tried it?
And of course, a profiler is only useful when you're debugging a program. A final program can't use a profiler, unless you want it to run very slowly.
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
You could be right. That works-out to about 55 updates per second, which might be the number I was trying to pull out of the fog in the back of my brain...I think it might be every 18.2 milliseconds...
Mmm, yes, it looks like it's certainly possible: http://www.delorie.com/djgpp/v2faq/faq22_27.html
That's for DJGPP, of course, but I imagine other compilers might be similar.A: Most time-related facilities in DJGPP have the same 55msec granularity of the time intervals they measure. This is because the timer tick interrupt that updates the time has the frequency of 18.2Hz. This is why calling usleep with arguments less than 55000 produces strange effects: the resolution of the argument is 1usec (for compatibility with other compilers), but the granularity is still 55msec.
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
