[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

1 files changed, 27 insertions, 0 deletions

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