On 02/26/2016 06:00 PM, Ranjan Maitra wrote:
>>> Indeed, I wanted to measure the total execution time of
the
>>> algorithms (i.e. difference in CPU time after and before the
>>> function executing the algorithm is called) and independent of
>>> extraneous issues such as what other process is running at some
>>> time, etc. I wanted to see if, in some case, some of the available
>>> theoretical guarantees actually hold or not.
>>>
>>> Thanks again!
>>>
>>> Best wishes,
>>> Ranjan
>> Did you see my reply?
>> It shows you the basics of what you need to use
>> in order to get exactly what you want.
>>
> Note that the accuracy of this depends on several factors, such as how
> long the measured interval is compared to the basic unit of timekeeping
> (IOW if you want to measure the execution time of a short sequence of
> instructions, you need to loop a few million times and divide the
> result), and how much overhead is incurred in calling the timing
> routines.
Btw, this webpage
https://stackoverflow.com/questions/23847588/how-do-i-use-the-functions-s...
says that getitimer and setitimer are obsolete and I should be using
timer_gettime() and timer_settime() instead: however, is it possible
to handle a virtual clock with these new functions?
Best wishes,
Ranjan
the manp ages for the posix compliant interfaces for timer_settime and
timer_gettime
do not even mention the word virtual; at least not in my fedora 22 manpages.
Whereas the still valid setitimer and getitimer CAN get the per running
process virtual time,
which will exclude all system time and interrupt handling time.
There are plenty of examples online for using setitimer() and getitimer().