0

I was just trying to get the cpu time and real time elapsed by running a code using time command on a Linux console. However, every time I run this command, I get different values. So, the repeatability in results is not there. The cpu time estimates were varying in the range of 12-31 ms. Then, which result should I consider as the most accurate one or simply I run it 10 times and take the average one?

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
beginner
  • 411
  • 4
  • 14
  • Try looking into 'high resolution timers' for c. – Daniel Jul 10 '15 at 03:39
  • Your code may not execute in the same time on repeated runs (consider caching, interrupts). – chux - Reinstate Monica Jul 10 '15 at 04:52
  • Welcome to benchmarking. It's hard. Times in the millisecond range are unreliable. Try to make sure what you're testing will take multiple seconds. All else apart, what else is running at the same time dramatically affects how fast your program seems to be. Also, you need to repeat multiple times, probably ignoring the first couple of runs so that caching effects are consistent between runs. If the disk is busy, it may take time to respond to your request to run your program — unless the program is already in memory. – Jonathan Leffler Jul 10 '15 at 06:20

3 Answers3

0

Your have to get the Processor time stamp records as it number of clock cycles since the last reset. How to get the rdtsc it depends of the processor and instruction sets of processors. First check your Processor Name and then go to vendor website and search for instruction sets of processor.

Vineet1982
  • 7,730
  • 4
  • 32
  • 67
  • Hi Vineet, Thanks for your response. Yeah the processor is Intel and X86 architecture. So, the code for rdtsc goes like this I guess, long long readTSC(void) { /* read the time stamp counter on Intel x86 chips union { long long complete; unsigned int part[2]; } ticks; __asm__ ("rdtsc; mov %%eax,%0;mov %%edx,%1" : "=mr" (ticks.part[0]), "=mr" (ticks.part[1]) : /* no inputs : "eax", "edx"); return ticks.complete; } But, my question was using getting accurate result using Time command as different runs give diff. reading. – beginner Jul 10 '15 at 05:45
  • How does that help if the code is multithreaded and ran in parallel? Or, how do you time separate threads if they are run in parallel on a multi-core machine? Is there a single value for rdtsc for all cores, or does each core have its own rdtsc value? – Jonathan Leffler Jul 10 '15 at 06:26
0

The time that you get is obvious because when you just start execute the code, it does not start executing. For this you have to now that what is the response time and what is the starvation time both of this factor governs another factor which is turn around time and the time command in the unix/linux environment gives you the turn around time & moreover if it is less than 5ms then it shows 0.

Take a look at the man page of time where it says 

DESCRIPTION
 The time utility executes and times utility.
 After the utility finishes, time writes the total time elapsed, 
 the time consumed by system overhead, and the
 time used to execute utility to the standard error stream.  
 Times are reported in seconds.

it clearly mentioned the total elapsed time, which in turn means total turn around time which further depends on few factors & those are

  1. Scheduling policy of OS
  2. How Process manager manages the process
  3. Clock frequency of the processor
  4. Databus time delay
  5. PCB load time

and some others..Hence calculation of the time exactly is virtually not possible. Now if you look at the asm file execution in a x86 emulator, you will see that immediately the instructions are not served from the RAM to the processor. Moreover the instructions set Architecture(ISA) affects it a lot. The time utility is just a wrapper implementation & hence it is incapable of getting the execution time accurately but I think even in real life example also you don't need that accuracy (I am guessing here )

Mayukh Sarkar
  • 2,289
  • 1
  • 14
  • 38
0

I think what is really important is to make sure that you are taking measurements in the same environment. Make sure your machine is a 'quiet' machine i.e no other processes are running when you are taking measurements. If other processes are running, your time measurements can vary because of CPU cycles getting consumed elsewhere.

It also important to understand what your code is actually doing when you run it. Does it involve a considerable amount of IO operations? In that case you can consider using Ramdisk for IO to decrease the variance in your timings. Ramdisk for IO

Is your code running in multiple threads? Or is it single threaded? You can try 'binding' your application to a certain processor core on Linux using the taskset utility. I have seen consistent numbers using taskset.

Because of memory and cache, if you running it multiple times, you will have part of your code in the cache which would affect your timings. To eliminate this effect you can run your code multiple times for 10 minutes before you start measuring your times. Or you can have your machine in the same memory and cache state by rebooting it each time before your run.

faadi
  • 176
  • 1
  • 8