[Gmp-commit] /var/hg/www: Updates for 5.1.0a.

[mercurial at gmplib.org]

details:   /var/hg/www/rev/f5368789ff82
changeset: 21:f5368789ff82
user:      Torbjorn Granlund <tege at gmplib.org>
date:      Thu Feb 07 12:25:19 2013 +0100
description:
Updates for 5.1.0a.

diffstat:

 devel/index.html |  31 ++++++++++++++++++++++++-------
 1 files changed, 24 insertions(+), 7 deletions(-)

diffs (55 lines):

diff -r f3eaaa487b02 -r f5368789ff82 devel/index.html
--- a/devel/index.html	Wed Feb 06 22:37:50 2013 +0100
+++ b/devel/index.html	Thu Feb 07 12:25:19 2013 +0100
@@ -56,12 +56,13 @@
 
 <h3> GMP release update </h3>
 
-<p> GMP 5.1.0 is out, but only from the gmplib servers.  A 5.1.0a might show up
-on the gnu.org servers at some point, but we cannot tell that yet.  There are
-several silly problems behind this; one a major overreaction to a minor
-automake issue which hyopthetically affects 5.1.0 (if users run the distcheck
-target, a malicous user might insert a file into a momentarily world-writable
-directory).
+<p> GMP 5.1.0 is out 2012-12-18.  An equivalent 5.1.0a is available from the
+gnu.org servers since 2013-02-02; these releases will generate the exact same
+binaries.  The difference between them is a minor automake issue which
+hyopthetically affects 5.1.0 (if users run the distcheck target, a malicous
+user might insert a file into a momentarily world-writable directory).  All
+previous GMP releases are also affected, as well as almost all other GNU
+software.
 </p>
 
 <p> Note that GMP newer than 5.0 on x86 or ARM cannot typically use valgrind.
@@ -96,6 +97,22 @@
 </table>
 </blockquote>
 
+<p> The qn > dn case is where the current code performs badly. For qn =
+100000 we have a slowdown of about 55% (compare nn=200000 with nn=174500). </p>
+
+<p> There, we now choose to compute an inverse of size in = ⌈dn/2⌉.
+Since qn > dn, we will have 2in < qn, which means that we will need to
+develop quotient limbs in more than 2 blocks; the code computes a most
+significant block of (qn - 2in) quotient limbs, and then two blocks of (in)
+quotient limbs each.  (The final block uses mpn_preinv_mu_divappr_q.) </p>
+
+<p> The inordinate cost we see emanates from the computation of the qn - 2in
+block. </p>
+
+<p> The fix is choosing the inverse size less stupidly, and organising the
+computation in more similarly sized quotient blocks.  It seems this will
+require more than just computing (in) differently, it will require some
+hacking. </p>
 
 <hr>
 
@@ -380,7 +397,7 @@
 </div>
 
 <div id="footer">
-<font size="-4">Last modified: 2013-02-04 </font>
+<font size="-4">Last modified: 2013-02-07 </font>
 <table cellpadding=0 width="100%" bgcolor="#e8e8e8">
   <tr>
     <td align="center">