From 02be18e71873bc4d65f9570c5e0553d05081d004 Mon Sep 17 00:00:00 2001 From: vlefevre Date: Mon, 7 Sep 2015 08:59:49 +0000 Subject: [TODO] Added: check whether mpz_t caching is necessary (this was committed in r8911). In short, timings should be done with -static (this wasn't clear), they may depend on the malloc implementation, and after a look at the source, the difference in the timings with mpz_t caching is surprising and should be explained. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@9673 280ebfd0-de03-0410-8827-d642c229c3f4 --- TODO | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/TODO b/TODO index e97bf0f92..e77330319 100644 --- a/TODO +++ b/TODO @@ -502,6 +502,33 @@ Table of contents: - use symbol versioning. +- check whether mpz_t caching is necessary. Timings with -static with + details about the C / C library implementation should be put somewhere + as a comment in the source or in the doc. Using -static is important + because otherwise the cache saves the dynamic call to mpz_init and + mpz_clear; so, what we're measuring is not clear. See thread: + https://gmplib.org/list-archives/gmp-devel/2015-September/004147.html + Summary: It will not be integrated in GMP because 1) This yields + problems with threading (in MPFR, we have TLS variables, but this is + not the case of GMP). 2) The gain (if confirmed with -static) would + be due to a poor malloc implementation (timings would depend on the + platform). 3) Applications would use more RAM. + Additional notes [VL]: the major differences in the timings given + by Patrick in 2014-01 were: + Before: + arccos(x) took 0.054689 ms (32767 eval in 1792 ms) + arctan(x) took 0.042116 ms (32767 eval in 1380 ms) + After: + arccos(x) took 0.043580 ms (32767 eval in 1428 ms) + arctan(x) took 0.035401 ms (32767 eval in 1160 ms) + mpfr_acos doesn't use mpz, but calls mpfr_atan, so that the issue comes + from mpfr_atan, which uses mpz a lot. But there are very few mpz_init + and mpz_clear (just at the end). So, the differences in the timings are + very surprising, even with a bad malloc implementation. Or is the reason + due to that due to mpz_t caching, the mpz_t's are preallocated with a + size that is large enough, thus avoiding internal reallocations in GMP? + (In such a case, mpz_t caching would not be the solution.) + ############################################################################## 7. Portability -- cgit v1.2.1