|
From: | Ahmet Göksu |
Subject: | Re: ftbench: last updates |
Date: | Sun, 17 Sep 2023 14:18:34 +0300 |
I just remember something - the windows' implementation of ANSI / POSIX timing routines are especially poor - e.g.https://stackoverflow.com/questions/18346879/timer-accuracy-c-clock-vs-winapis-qpc-or-timegettimeSo unfortunately if you are trying to measure time on Windows accurately, you might have to do something differently from ANSI C . If you search for "poor timer on Windows" or just "highres timer os" on most search engines, there are various discussions about it.On Saturday, 16 September 2023 at 17:21:49 BST, Ahmet Göksu <ahmet@goksu.in> wrote:Hello,
-I have changed the * and the sentence
-changed the links to relativeI already changed the working way of the timing. I only start the
benchmark at beginning and stop at the end.i mean, it times chunks, not single iteration.timer starts at the beginning of the chunk and stop at the end (then divide the results size of a chunk). because of it does not time single iteration, it is already a bulk test.BTW, I suggest that you add another sentence, explaining *why* there
are two values at all.actually, i didnt get the reason well but it may differ even with same flags. i need help in this case.
as i said before, i run the benchmark in mac. it uses this if clause.
return 1E6 * (double)clock() / (double)CLOCKS_PER_SEC;
the code seems producing more accurate results after splitting the results into chunks. are results seem satisfactory in your machine?
Best,Goksugoksu.inOn 12 Sep 2023 18:17 +0300, Werner LEMBERG <wl@gnu.org>, wrote:
If a value in the 'Iterations' column is given as '*x* | *y*',
values *x* and *y* give the number of iterations in the baseline and
the benchmark test, respectively.
[Prev in Thread] | Current Thread | [Next in Thread] |