mpf_get_str() is slow for big numbers?

[Torbjorn Granlund]

Brian Hurt <bhurt at spnz.org> writes:

  On 1 Dec 2003, Torbjorn Granlund wrote:
  
  >   In some bases though, like base 2, 4, 16, the process can be accelerated by 
  >   dropping the divisions.  Only masks are needed.  No need to even use 
  >   extensive shifts operations.  Just run through each limbs and do a AND mask.
  > 
  >   I wonder if GMP is built with such optimizations.  The speed difference may 
  >   come from that.  With the optimization, for base 16 for example, the runtime 
  >   become linear to the number of digits (O = ln(n))
  > 
  > No need to wonder.  A great feature of GMP is that it comes with
  > source code.  It is Free Software, remember.  :-)
  > 
  > In GMP 4.1.2, mpz radix conversion is O(n) for bases 2^t, and
  > O(n^2) for other bases.  mpf radix conversion is O(n^2) for all
  > bases.
  > 
  > (In the next major GMP release, both mpz and mpf will be O(n) for
  > bases 2^t and O(n*log(n)) for other bases.  They will be based on
  > common mpn_get_str and mpn_set_str with that property.)
  > 
  
  My apologies if I'm preaching to the choir.
  
  The bases 2, 8, 10, and 16 should get special attention, even to the point
  of being special-cased.

As I wrote in the message to which you're responding, bases 2^t
WILL GET SPECIAL ATTENTION IN THE NEXT RELEASE (code implemented
last February).  No need to further urge your volunteer GMP
developers!

  Base 10 can be accelerated like this:

  [snip]

The base-10 code in the development source is much faster than
what you get with your suggested algorithm.  And while we
actually have optimizations for base 10, the main speed gains
come from a novel subquadratic radix comversion algorithm.
  
Below is a large comment from the current code, explaining the
algorithm.  mpn_sb_get_str is the basecase for the subquadratic
stuff.  It is also used directly for conversion up to about 20
limbs.  It has a special case for 10, converting individual limbs
with just multiplication (no limb divisions).

(And no, I cannot make the new code available, as it will not
work standalone.)

/* Conversion of U {up,un} to a string in base b.  Internally, we convert to
     base B = b^m, the largest power of b that fits a limb.  Basic algorithms:

  A) Divide U repeatedly by B, generating a quotient and remainder, until the
     quotient becomes zero.  The remainders hold the converted digits.  Digits
     come out from right to left.  (Used in mpn_sb_get_str.)

  B) Divide U by b^g, for g such that 1/b <= U/b^g < 1, generating a fraction.
     Then develop digits by multiplying the fraction repeatedly by b.  Digits
     come out from left to right.  (Currently not used herein, except for in
     code for converting single limbs to individual digits.)

  C) Compute B^1, B^2, B^4, ..., B^(2^s), for s such that B^(2^s) > sqrt(U).
     Then divide U by B^(2^k), generating an integer quotient and remainder.
     Recursively convert the quotient, then the remainder, using the
     precomputed powers.  Digits come out from left to right.  (Used in
     mpn_dc_get_str.)

  When using algorithm C, algorithm B might be suitable for basecase code,
  since the required b^g power will be readily accessible.

  Optimization ideas:
  1. The recursive function of (C) could use less temporary memory.  The powtab
     allocation could be trimmed with some computation, and the tmp area could
     be reduced, or perhaps eliminated if up is reused for both quotient and
     remainder (it is currently used just for remainder).
  2. Store the powers of (C) in normalized form, with the normalization count.
     Quotients will usually need to be left-shifted before each divide, and
     remainders will either need to be left-shifted of right-shifted.
  3. When b is even, the powers will end up with lots of low zero limbs.  Could
     save significant time in the mpn_tdiv_qr call by stripping these zeros.
  4. In the code for developing digits from a single limb, we could avoid using
     a full umul_ppmm except for the first (or first few) digits, provided base
     is even.  Subsequent digits can be developed using plain multiplication.
     (This saves on register-starved machines (read x86) and on all machines
     that generate the upper product half using a separate instruction (alpha,
     powerpc, IA-64) or lacks such support altogether (sparc64, hppa64).
  5. Separate mpn_dc_get_str basecase code from code for small conversions. The
     former code will have the exact right power readily available in the
     powtab parameter for dividing the current number into a fraction.  Convert
     that using algorithm B.
  6. Completely avoid division.  Compute the inverses of the powers now in
     powtab instead of the actual powers.

  Basic structure of (C):
    mpn_get_str:
      if POW2_P (n)
	...
      else
	if (un < GET_STR_PRECOMPUTE_THRESHOLD)
	  mpn_sb_get_str (str, base, up, un);
	else
	  precompute_power_tables
	  mpn_dc_get_str

    mpn_dc_get_str:
	mpn_tdiv_qr
	if (qn < GET_STR_DC_THRESHOLD)
	  mpn_sb_get_str
	else
	  mpn_dc_get_str
	if (rn < GET_STR_DC_THRESHOLD)
	  mpn_sb_get_str
	else
	  mpn_dc_get_str


  The reason for the two threshold values is the cost of
  precompute_power_tables.  GET_STR_PRECOMPUTE_THRESHOLD will be considerably
  larger than GET_STR_PRECOMPUTE_THRESHOLD.  */
  
-- 
Torbjörn