mpf_get_str() is slow for big numbers?
Torbjorn Granlund
tg at swox.com
Mon Dec 1 17:45:37 CET 2003
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
More information about the gmp-discuss
mailing list