|
|
Hi All,
Is there a way to find out the time taken by a function to complete (in terms of nanoseconds) in my c++ code without using "Function Profiling" feature of the linker. I tried GetTickCount(), but it gives the time in milliseconds. It always returns 0 because my function completes its task less than in one millisecond.
Thanks in advance
|
|
|
|
|
You may use the QueryPerformanceFrequency [<a href="http://msdn.microsoft.com/en-us/library/ms644905.aspx" target="_blank" title="New Window">^</a>], QueryPerformanceCounter [^] pair.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
This can only be applied if there's thread switching: you are measuring the time before the function and then after the function and assume that the difference is the time spent in the function. While this might seem correct, it's not always the case: the scheduler can decide in the middle of your function to switch to another thread, which will 'pause' your function for a certain amount of time. Thus you will take that time into account also, which is wrong.
A better approach would be to measure the time really spent for this thread. But unfortunately, I don't know how to do this (but I guess it is possible).
|
|
|
|
|
I knew that. I provided only a way to measure time on a smaller scale.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: I knew that.
Yeah I guess so. I was mainly clarifying for the OP
|
|
|
|
|
Well, indeed your was a good point against profiling-do-it-yourself.
The OP should also be aware that between milli and nano there are micro seconds (i.e. pretending nano seconds accuracy it is at present, a bit Utopian!)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I agree with you. There can be several downsides to any and every method that can be suggested here, but there's no single fool proof way of doing it, or at least that I don't know of one. What if the method which is supposed to measure the time elapsed takes more time to execute than the actual set of instructions whose execution time is to be measured? 
It becomes more bizarre as we go down to get more precision.
|
|
|
|
|
Rajesh R Subramanian wrote: What if the method which is supposed to measure the time elapsed takes more time to execute than the actual set of instructions whose execution time is to be measured?
A philosophical approach to quantum mechanics?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I had to re-read my post to realise why did you make a comment like that. 
Sometimes, the philosopher in me wakes up. 
|
|
|
|
|
|
This blog post[^] may give you some insights.
I doubt if there's a ready made API that can give results at nano second precision. RDTSC[^] can be a good thing to bet upon, but don't take my word for it. 
|
|
|
|
|
Rajesh R Subramanian wrote: RDTSC[^] can be a good thing to bet upon, but don't take my word for it.
On old-fashioned-single-core-machines. 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
But does that apply only to RDTSC?
|
|
|
|
|
Yes, as far as this article [^] is correct, the QueryPerformanceFrequency,QueryPerformanceCounter pair is more robust (as Windows API is expected to be).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I accept, I had not taken into account the fact that more than one processor core can exist, but:
What QueryPerformanceCounter actually does is up to the HAL (with some help from ACPI). The performance folks tell me that, in the worst case, you might get it from the rollover interrupt on the programmable interrupt timer. This in turn may require a PCI transaction, which is not exactly the fastest thing in the world. It's better than GetTickCount, but it's not going to win any speed contests. In the best case, the HAL may conclude that the RDTSC counter runs at a constant frequency, so it uses that instead.[^]
|
|
|
|
|
Rajesh R Subramanian wrote: In the best case, the HAL may conclude that the RDTSC counter runs at a constant frequency, so it uses that instead.
That's API robustness. You should make the (in)famous QueryPerformanceFrequency/QueryPerformanceCounter pair make the best (while still reliable) choiche for you.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: You should make (in)famous QueryPerformanceFrequency/QueryPerformanceCounter pair make the best (while still reliable) choiche
Agreed.
Hijack attempt starts:
How are you doing with the Connoisseur's tea? Liking it?
|
|
|
|
|
Rajesh R Subramanian wrote: Hijack attempt starts:
Hijack attempts goes stright on:
Yes I like it. But I had few occasions to taste it again. It's quite hot these days here in Italy and I prefer lower temperatures to have cups of tea.
(of course I can't miss hot coffee, but, you know, I'm an addict...)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: I prefer lower temperatures to have cups of tea.
Urgent?
|
|
|
|
|
Yes, plz plz. Or gimme more drugz!
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
And finally hijacked!!
Regards,
Sandip.
|
|
|
|
|
|
SandipG wrote: And finally hijacked!!
Whom??
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You/xml>
|
|
|
|
|
cup of coffee also help 
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You/xml>
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
