<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/4.1.92">
</HEAD>
<BODY>
Mikael sent me some comments about the bignum code, and he said it would be OK if I replied to the list.<BR>
<BR>
On Thu, 2011-11-03 at 18:34 +0200, Mikael wrote:<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    I saw the bignum benchmarks at <A HREF="http://dynamo.iro.umontreal.ca/%7Egambit/wiki/index.php/Benchmarks">http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Benchmarks</A> .<BR>
    <BR>
    I'd suppose though that for small bignums (<2^512 or so), Gambit's bignum handling is even so highly performant also compared with using GMP, as Gambit has a deep bignum integration for instance with partial inlining of operations and fast object handling.<BR>
</BLOCKQUOTE>
<BR>
First, let me say that I am not anywhere near an expert on GMP, and that my impression of GMP's code, performance, etc.,  is based on fairly brief examinations.<BR>
<BR>
If you look at GMP's code, you'll find that it includes many very low-level optimizations, so that whatever algorithm they implement, their code will be very close to the optimal implementation of that algorithm.  They have assembly implementations of inner loops, they use condition codes for integer overflow (I don't know how to do this in C), etc.  I suspect that for small integers GMP's code is many times faster than Gambit's.  For larger bignums, GMP chooses from among a very wide variety of algorithms for, say, multiplication, based on the relative sizes of the arguments.<BR>
<BR>
Of course, as you say, Gambit's bignum code is integrated closely with the language, but it is in a separate module (_num.scm), so each bignum operation incurs a cost of two trampoline calls, which for small bignums (size a few times a fixnum) take many more operations than the time for the basic arithmetic calculations.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    Just out of general interest, is there any initiative currently to upgrade Gambit's bignum library to the same speed level as GMP?<BR>
</BLOCKQUOTE>
<BR>
I don't think this is possible except by using GMP itself at this point.<BR>
<BR>
I've asked on the Gambit list before whether fast bignums are important to people, and I've found no one who says they use bignums in their codes.<BR>
<BR>
I use bignums in some of my codes, and I've found that Knuth's algorithm for long division, at least in my implementation, takes about three or more times as long as it could with a bit of tweaking for problems with small quotient or divisor.  (I'm following Knuth to the letter, and he's a bit lazy at one point.  Or maybe my interpretation of what he says leads to laziness on my part.)<BR>
<BR>
My ideas for how to improve Gambit's bignum code are as follows.<BR>
<BR>
I plan to tweak the code for naive long division, which is used when the divisor or the quotient is small.<BR>
<BR>
Speeding up the division code for small quotients will also improve GCD times.  The times for large GCD are the only times I find a bit embarrassing right now.<BR>
<BR>
Independently, I intend to improve GCD for smaller bignums.  This is important for rational arithmetic and for a code I have that does what might be called verifiable computations/constructive analysis/the computable reals.<BR>
<BR>
I plan to investigate a slightly different algorithm for calculating the approximate inverse of a bignum, similar to what is in Knuth but with a slightly less stringent error bound that I think will require one to keep fewer bignum digits in intermediate results (and hence use computer multiplications with fewer bits).  This might increase the speed of division for large bignums.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    Gambit is shining with performance in other areas, so this would be a really worthy area to shine in as well :-)<BR>
    <BR>
    >=90% of GMP's performance should be achievable while having the bignum library written in Scheme, what do you think?<BR>
</BLOCKQUOTE>
<BR>
No.  Generally, Gambit's code takes twice as long as similar C code; and C code often takes twice as long as well-written assembly code.  So I suspect that from now on GMP will always be about four times as fast as Gambit in bignum code.  Also, GMP implements many different algorithms for the same problem, and which algorithm is used is based on problem size.<BR>
<BR>
I think that there were several design goals for Gambit's bignum code:<BR>
<BR>
1.  First, to implement in portable Scheme code the basic bignum algorithms as found in Knuth, volume II, say, by following the strategy explained by Jon L White many years ago in the included paper.  We started this in 1998.  This code worked out of the box for variations of machine characteristics: big-endian/little-endian and 32-bit words, 64-bit  long long; 64-bit words, 64 bit long long; and 32-bit words, no long long.<BR>
<BR>
2.  Later, I wanted to implement fast variants of very large bignum operations with algorithms that were relatively compact and understandable.  This led to using two somewhat novel algorithms, one for bignum multiplication that is much shorter than what GMP uses but which they rejected, and one for GCD, which I reconstructed from discussions with Schoenhage (there are a few comments in the code).  I also use a few known compact algorithms with high performance, for inverting a bignum and for integer square root.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    A secondary approach could possibly be to make GMP/MPFR/MPIR bindings for the bignum computations in Gambit, though GMP/etc.'s license is a bit narrow maybe.<BR>
</BLOCKQUOTE>
<BR>
It's LGPL, so that's not too restrictive for nearly all applications.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    Anyhow, what would the basic challenge be in this, are Gambit's current bignum structures in a form that would go perfectly together with GMP/etc.'s interface & handling, would GMP/etc. deliver the full numeric tower?<BR>
</BLOCKQUOTE>
<BR>
I don't know whether GMP's bignum format is the same as Gambit's, but I doubt that it would be so.<BR>
<BR>
GMP could certainly deliver the full numeric tower.<BR>
<BR>
Brad<BR>
<BR>
<BR>
<BR>
</BODY>
</HTML>