time_t now (milliseconds ?)

[franse]

I have a question about this code. I want to to know how long time this for loop takes by doing as below.
But I will only have second accuracy for start and end.
Is it possible to have milliseconds accuracy instead.

double start;
double end;


	time_t now = time(0);
	struct tm* tm = localtime(&now);

	start = tm->tm_sec;

	for( int i = 0; i < 5000000; i++)
	{
		//
	}

		time_t now2 = time(0);
		struct tm* tm2 = localtime(&now2);

		end = tm2->tm_sec;

[matsp]

it is possible (in most systems) to get better precision time, but the way you do that depends on the OS.

Although in this case, perhaps using clock(), which has higher precision would be possible. To get seconds, you need to divide the result by CLOCKS_PER_SEC.

Just beware that empty loops can be optimized away completely by the compiler, so you may still get "zero". And even if it's not optimized away, it is about 5 million loop iterations, which is probably about 10 million instructions, which may well be about 5 milliseconds on a modern processor. Even clock() may not be precise enough to measure such a short time.

--
Mats

[franse]

Many thanks matsp for your info!. I use XP and I think I managed to do this method like this as a test.

std::string str;
double clo2 = 0;
double clo1 = clock();

	for( int i = 0; i < 5000000; i++)
	{
		str = "hello";
	}
	clo2 = clock();

			
                clo1 = clo1/CLOCKS_PER_SEC; //start 3.546 s
                clo2 = clo2/CLOCKS_PER_SEC; //end  4.718 s

[brewbuck]

Just beware that empty loops can be optimized away completely by the compiler, so you may still get "zero". And even if it's not optimized away, it is about 5 million loop iterations, which is probably about 10 million instructions, which may well be about 5 milliseconds on a modern processor. Even clock() may not be precise enough to measure such a short time.

Even non-empty loops can be optimized away if the compiler can determine that the results of the loop are unused. One trick is to pass some loop-computed value to a function in another module after the loop finishes, which forces the compiler to actually generate the loop (since it has no idea what that other function will do with that value)

[matsp]

Even non-empty loops can be optimized away if the compiler can determine that the results of the loop are unused. One trick is to pass some loop-computed value to a function in another module after the loop finishes, which forces the compiler to actually generate the loop (since it has no idea what that other function will do with that value)

Indeed - I once had a Whetstone benchmark give me something like 10x the THEORETICAL performance of the FPU on the machine. After looking at the code, it turned out that the result of some functions where never used, so the function was never called - only about 3 of 8 steps were actually calculated, and in each case, the actual calculation was only done once, rather than X times, because the result in each loop iteration would be the same - so no point in doing the same computation over and over. On the other hand, the overhead of calling the "use the result" function every time in the loop was significant (but needed to get the correct results), something like 10% of the overall performance.

--
Mats

[franse]

Nice to read what you write. Though I have to step in with a wondering.


With the test that I did with clock() where I got a result like:

clo1 = clo1/CLOCKS_PER_SEC; //start 3.546 s

I did a new test, actually what I will use the timing for and start and end in that case was the same, because it went very fast.
(It is not an emty loop that I use. There is actual code inside.)

So my question is if it is possible to have even better accuracy (decimals) than 3. (3.546 s) ?
I wonder this because I will do perheps 3000 of these calculations and I will see if this will take less than 1 second.

[brewbuck]

So my question is if it is possible to have even better accuracy (decimals) than 3. (3.546 s) ?

You're at the mercy of the system clock. The only real way to get more significant digits is to make the test last longer (more iterations). I've even timed stuff with a (physical) stopwatch in the past.

[matsp]

Running more iterations is the obvious answer. I have several times written code that "auto-adjusts" so that it doubles the number of iterations until it goes over 1 second (or something like this).

If you have some special reason NOT to run multiple times (e.g. your code works differently the first time and the second time, so running 100 times doesn't show well what happens the first time, which is what you wanted to measure), then using a higher precision timer is the only solution. For that, we need to either use the OS to get a more precise clock, or use something like time-stamp counter in the processor (assuming of course the processor has one - PC processors produced in the last 5-10 years do, but other processors may not).

http://en.wikipedia.org/wiki/Time_Stamp_Counter

--
Mats

[franse]

I understand, then I know. I will try to check will longer iterations.
I think this will be possible. I will also check out the timestamp. I use an AMD processor about 1 years old.
Great thanks for all information.