Study of clock function in Linux

When there are coding in Linux and winows, there are some problems when porting code.
1. Are you allowed to do this? About clock () timing functions
The first is a simple test code that reads the data from a text file and assigns a value to the run time of the last printout of the vector.

int main (int argc, char **argv)
{
clock_t T1=clock ();
Ifstream in ("Data.txt");
Vector<int> v;
for (int a;in>>a;v.push_back (a));
Cout<<v.size () <<endl;
for (int i=0;i<v.size (); i++)
cout<<v[i]<< "";
cout<<endl;
clock_t T2=clock ();
cout<< "TotalTime:" <<t2-t1<< "MS" <<endl;
}

This code uses two clock_t-type clock () functions to calculate the program run time.

Run under Windows compilation,
Totaltime:465ms

Compile and run under Linux,
Totaltime:420000ms

OK, the problem comes, in addition to normal code farmers can understand the cause of system errors, is obviously due to the clock () function in different platforms, the return value of different reasons, the check clock function definition has the following description:

Clock returns the processor time used by program since the beginning of the execution, or-1 if unavailable.

The clock () function returns the process time consumed during the program's operation, which is CPU time.
You think it's returning a standard time unit, you're wrong, because there's the next sentence:
Clock ()/clocks_per_sec is a time in seconds.
Clocks_per_sec, which is used to indicate how many clock units, the number of hardware ticks, will be in a second.
Regardless of what is called the hardware tick number, you need to know that the clock () is counted based on this object of the clocking unit (tick). A clock tick is not a cycle of the CPU, but rather a basic unit of time in C + +, and is therefore only relevant to the compiler. In TC2.0 hardware every 18.2 ticks is one second, in the VC every 1000 ticks is one second, in standard POSIX defined as 1 million ticks for one second.

OK, knowing so much, to let the program run the output correctly, and to ensure the compatibility of multiple platforms, the code for the following processing:
cout<< "TotalTime:" << (Double) (T2-T1)/clocks_per_sec<< "s" <<endl;

Very simple, after the correct output of the program, you can not wait to run the test many times, and found that your program is a precise to 10 milliseconds of an integer, really because every time so coincidence? Search found that the standard POSIX platform clock () can only be accurate to 10ms, as to why I am not yet known.

2. Be a rational paranoid about the system timing error
If you're a paranoid, when you're upset about missing milliseconds using the clock () function, I'm going to go home and hang out with your wife. Because it is impossible to accurately measure exactly how long a program is running, at least for now. I have been so bothered to find something like this from other articles that I hope will help you understand why there is an error.
The article mentions that "the method of measuring running time we usually use is not so precise, in other words, it is not so easy to get the program running time accurately." Perhaps you will think, the program is not a command, each instruction sequence has a fixed execution time, why not calculate? In real case, our computer is not only running a program, process switching, various interrupts, shared multiuser, network traffic, cache access, transfer forecasts, etc., will have an impact on timing.
For process scheduling, the time spent is divided into two parts, the first is the timer interrupt processing time, that is, when and only when the time interval, the operating system will choose whether to continue the execution of the current process or switch to another process. The second is the process switching time, when the system is going to switch from process A to process B, it must first enter kernel mode to save the state of process A, and then restore the state of process B. Therefore, this switching process is a kernel activity that consumes time. Specific to the execution time of the process, this time also includes the kernel mode and user mode two parts, the switch between modes will also need to consume time, but is counted in the process execution time ".

OK, after reading the above paragraph, you should know very well that a program does not always take the same amount of time, even if it executes the same command each time, because it spends time related to the system. The reason is that whether it's Windows or Linux, it's a multitasking operating system. To make it clearer to you, now the time taken to execute a program is categorized from another angle, as follows:

(1) Actual runtime (real time): The elapsed time from the command line execution to the end of the run;

(2) User CPU time: The sum of the execution time of the command in the user state;

(3) System CPU time: The sum of the execution time of the command in the system kernel mentality.

Now there is no such doubt, the actual running time (1) is not equal to (2) + (3)? Is there someone else besides the user and the system for a process?

The answer is yes. Look up the above mentioned process scheduling, think back to your sophomore operating system courses in the time slice rotation, process five states, understand, at this time the program surface in the code for you to execute, the CPU early run others home.

OK, now look back at the beginning of the code to run the results, clock () to calculate the time it belongs to the above? For this we designed the following experiment:
This code is the time it takes for the test to execute 100 million empty loops

int main (void)
{
clock_t start, finish;
Double duration;
Long i,j;
start = Clock ();
for (i=0;i<100;i++) {
for (j=0;j<1000000;j++);
}
finish = Clock ();
Duration = (double) (finish-start)/clocks_per_sec;
printf ("Time to does%ld empty loops is", i*j);
printf ("%f seconds\n", duration);
return 0;
}

Compile connection
g++ Test.cpp-o Test
Run the program
./test
Show results
Time to does 100000000 empty loops is 0.290000 seconds
That's the only result, of course, that's not going to prove anything, okay, let's add a sentence

Sleep (5); Need to include header files <unistd.h>

The Sleep function suspends the program temporarily, which is the blocking state, where the CPU spends no time on the process within 5s. If the last display time is more than 5s, it can be proved that the clock function calculates the actual running time of the program, if it is still close to 290ms, it is the CPU running time.

Run the program./test

Show results
Time to does 100000000 empty loops is 0.290000 seconds

The same! Now that the clock function is calculated CPU time, smart and memory good you will find that I have a suspicion of cheating the public IQ, in the definition of clock

The clear point is processor time, not the CPU, OK, I even design an experiment to prove that this is true, but the clock function calculates which CPU time, temporarily is powerless to prove.

Paranoid you are not satisfied with the beginning, there is no way to separate statistics of the three times a program? The answer is yes.

There is a very simple and easy-to-use command under Linux that can be used to count the three time--time commands that the program runs. The purpose of this command is to measure the execution of specific instructions

The time required to consume the data, and information such as system resources. This is good news for you if you are just optimizing a small piece of streamlined code.

Use the time command below to run the above test code:

Run the shell command

Time./test

Show results

Time to does 100000000 empty loops is 0.290000 seconds

Real 0m0.915s
User 0m0.031s
SYS 0m0.266s

Now the simple analysis results, finally the truth. The time calculated using the clock () function in the above program is the total CPU time. In other words, the clock function does not differentiate between user space and kernel space.
The time command described above can measure how long a particular process is executing, and how does it do that? The method is called the interval count. If you are interested in him,

You can continue to read the following introduction, you will find the principle is actually very simple.

The operating system uses timers to record the cumulative time used by each process, and when a timer interrupt occurs, the operating system looks in the current list of processes for which process is active, one

Once you discover that process A is running, increase the timer interval for the count value of process a (which is also the cause of the large error). Of course not unified increase, but also to determine whether the process is in user space activities or kernel space activities, if it is User mode, increase user time, if it is kernel mode, increase the system time. The principle of this method is simple but imprecise. If the running time of a process is short, and the system's timer interval is an order of magnitude, the results measured by this method are not accurate enough, and there are errors in the end and tail. However, if the program time is long enough, this error can sometimes compensate each other, some are overvalued some undervalued, on average just right. It is theoretically difficult to analyze the value of this error, so it is generally only meaningful to test the program time with this method when the program reaches the order of magnitude of seconds. The biggest advantage of this approach is that its accuracy is not very dependent on the system load.

3. Is that true? About the "more than three" topic

With the development of multi-core multi-process multithreading technology, the efficiency of operation is improved, and the code farmers are also brought new troubles.

3.1 Multi-Core computing
It is already known that the clock function is implemented based on the clocking unit. The problem is on the CPU's clock-timing unit. When a multi-core CPU is used, the process or thread

With clock, the current nuclear clock is recorded. However, CPU scheduling is likely to occur before the next call to clock, and the process or thread is scheduled to run on another CPU. This leads to two times of acquisition

The timing unit is not the same CPU and produces a timing error. However, this error is much to be proved.

3.2 Multi-process computing

The above is verified by the time function, and the clock function calculates that it is equal to the user CPU time + system CPU time. Is that so? We re-test the code

Make changes, reduce the number of cycles to 1000 times, and add a sentence in the empty loop

System ("CD");

This sentence is used to simulate the operation of a sub-process, which makes it easy to select a system process as a child process.

Run the shell command

Time./test

Show results

Time to do the empty loops is 0.010000 seconds

Real 0m3.492s
User 0m0.512s
SYS 0m2.972s

This experiment shows that the clock function does not take into account the time consumed by the CPU quilt process.

3.3 Multi-Threading computing

There are three times real time, both User and Sys, mentioned above. Real time > User Time + sys time is this relationship always true?

The answer is in the negative. The reason is parallel computing. Now recall the concept of these three kinds of time again:

Real refers to the actual elapsed time, and user and Sys refer to the CPU time used by the process.
1. Real is the time on the wall (wall clock), which is the actual time that the process takes from start to finish. This time includes the time slices used by other processes and the time that the process is blocked (for example, waiting for I/O completion).
2. User refers to the time used by the process to execute the user-state code (outside the core). This is the actual CPU time consumed by the execution of this process, which is not included in other processes and when the process is blocked.
3. SYS refers to the CPU time that the process consumes in the kernel state, that is, the CPU time used by the kernel to perform system calls.
So, under what circumstances will the process start to end take less time than the user time and system time consumed by the process?
User+sys The actual CPU time used by the process. On multiprocessor systems, it is easy to understand that a process with multiple threads or multiple sub-processes can cause real time to be smaller than the CPU time (User + Sys time).

Study of clock function in Linux