C99 and GMP tuning

[sav_ix at ukr.net]

(moved from gcc-devel)


Hello, everyone,


--- Оригінальне повідомлення ---
Від кого: "Torbjörn Granlund" <tg at gmplib.org>
Дата: 4 квітня 2018, 02:14:01


I'd like to move to C99 soon.

Presumably this should lead to dropping support of old systems, which compilers do not provide C99 support. On the other side, more recent OSes provide better 'clock()' implementation, which accuracy (depending of used OS) in times or magnitudes better, compared to 'getrusage()'.

After moving to C99, can GMP Developers consider to drop use of non portable 'getrusage()', 'rusage' etc. in favor of 'clock()'? The advantage in addition to portability could be that the running time of the tuning be shortened (need be verified).


Something similar was discussed on MPFR bugtracker:
================================================================
GMP should use clock(), which should be at least as accurate as getrusage() if the system is not too bad.
================================================================
https://sympa.inria.fr/sympa/arc/mpfr/2016-01/msg00003.html

================================================================
> The main problem of 'mpfrbench' is that it couldn't run without 'getrusage()' implementation: [...]

the new version in the development version uses now clock() and should work
================================================================
https://sympa.inria.fr/sympa/arc/mpfr/2016-01/msg00011.html

================================================================
On my machine, clock() has a 1µs resolution while getrusage() only has a 4ms resolution, i.e. 4000 times more
================================================================
https://sympa.inria.fr/sympa/arc/mpfr/2016-01/msg00012.html

================================================================
> Does it mean, that "it be better to use clock() even if getrusage() is supported" for 'MPFR/tune' utilities too?

Yes, everywhere.
================================================================
https://sympa.inria.fr/sympa/arc/mpfr/2016-01/msg00014.html

but for obvious reasons there were no consequences.


Best,

Alexander