Re: ftbench: last updates

[Hin-Tak Leung]

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-timegettime

So 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 relative

I 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,

Goksu

goksu.in

On 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.