Annotation of OpenXM/src/kan96xx/gmp-2.0.2/PROJECTS, Revision 1.1
1.1 ! maekawa 1: IDEAS ABOUT THINGS TO WORK ON
! 2:
! 3: * mpq_cmp: Maybe the most sensible thing to do would be to multiply the, say,
! 4: 4 most significant limbs of each operand and compare them. If that is not
! 5: sufficient, do the same for 8 limbs, etc.
! 6:
! 7: * Write mpi, the Multiple Precision Interval Arithmetic layer.
! 8:
! 9: * Write `mpX_eval' that take lambda-like expressions and a list of operands.
! 10:
! 11: * As a general rule, recognize special operand values in mpz and mpf, and
! 12: use shortcuts for speed. Examples: Recognize (small or all) 2^n in
! 13: multiplication and division. Recognize small bases in mpz_pow_ui.
! 14:
! 15: * Implement lazy allocation? mpz->d == 0 would mean no allocation made yet.
! 16:
! 17: * Maybe store one-limb numbers according to Per Bothner's idea:
! 18: struct {
! 19: mp_ptr d;
! 20: union {
! 21: mp_limb val; /* if (d == NULL). */
! 22: mp_size size; /* Length of data array, if (d != NULL). */
! 23: } u;
! 24: };
! 25: Problem: We can't normalize to that format unless we free the space
! 26: pointed to by d, and therefore small values will not be stored in a
! 27: canonical way.
! 28:
! 29: * Document complexity of all functions.
! 30:
! 31: * Add predicate functions mpz_fits_signedlong_p, mpz_fits_unsignedlong_p,
! 32: mpz_fits_signedint_p, etc.
! 33:
! 34: mpz_floor (mpz, mpq), mpz_trunc (mpz, mpq), mpz_round (mpz, mpq).
! 35:
! 36: * Better random number generators. There should be fast (like mpz_random),
! 37: very good (mpz_veryrandom), and special purpose (like mpz_random2). Sizes
! 38: in *bits*, not in limbs.
! 39:
! 40: * It'd be possible to have an interface "s = add(a,b)" with automatic GC.
! 41: If the mpz_xinit routine remembers the address of the variable we could
! 42: walk-and-mark the list of remembered variables, and free the space
! 43: occupied by the remembered variables that didn't get marked. Fairly
! 44: standard.
! 45:
! 46: * Improve speed for non-gcc compilers by defining umul_ppmm, udiv_qrnnd,
! 47: etc, to call __umul_ppmm, __udiv_qrnnd. A typical definition for
! 48: umul_ppmm would be
! 49: #define umul_ppmm(ph,pl,m0,m1) \
! 50: {unsigned long __ph; (pl) = __umul_ppmm (&__ph, (m0), (m1)); (ph) = __ph;}
! 51: In order to maintain just one version of longlong.h (gmp and gcc), this
! 52: has to be done outside of longlong.h.
! 53:
! 54: Bennet Yee at CMU proposes:
! 55: * mpz_{put,get}_raw for memory oriented I/O like other *_raw functions.
! 56: * A function mpfatal that is called for exceptions. Let the user override
! 57: a default definition.
! 58:
! 59: * Make all computation mpz_* functions return a signed int indicating if the
! 60: result was zero, positive, or negative?
! 61:
! 62: * Implement mpz_cmpabs, mpz_xor, mpz_to_double, mpz_to_si, mpz_lcm, mpz_dpb,
! 63: mpz_ldb, various bit string operations. Also mpz_@_si for most @??
! 64:
! 65: * Add macros for looping efficiently over a number's limbs:
! 66: MPZ_LOOP_OVER_LIMBS_INCREASING(num,limb)
! 67: { user code manipulating limb}
! 68: MPZ_LOOP_OVER_LIMBS_DECREASING(num,limb)
! 69: { user code manipulating limb}
! 70:
! 71: Brian Beuning proposes:
! 72: 1. An array of small primes
! 73: 3. A function to factor a mpz_t. [How do we return the factors? Maybe
! 74: we just return one arbitrary factor? In the latter case, we have to
! 75: use a data structure that records the state of the factoring routine.]
! 76: 4. A routine to look for "small" divisors of an mpz_t
! 77: 5. A 'multiply mod n' routine based on Montgomery's algorithm.
! 78:
! 79: Dough Lea proposes:
! 80: 1. A way to find out if an integer fits into a signed int, and if so, a
! 81: way to convert it out.
! 82: 2. Similarly for double precision float conversion.
! 83: 3. A function to convert the ratio of two integers to a double. This
! 84: can be useful for mixed mode operations with integers, rationals, and
! 85: doubles.
! 86:
! 87: Elliptic curve method description in the Chapter `Algorithms in Number
! 88: Theory' in the Handbook of Theoretical Computer Science, Elsevier,
! 89: Amsterdam, 1990. Also in Carl Pomerance's lecture notes on Cryptology and
! 90: Computational Number Theory, 1990.
! 91:
! 92: * Harald Kirsh suggests:
! 93: mpq_set_str (MP_RAT *r, char *numerator, char *denominator).
! 94:
! 95: * New function: mpq_get_ifstr (int_str, frac_str, base,
! 96: precision_in_som_way, rational_number). Convert RATIONAL_NUMBER to a
! 97: string in BASE and put the integer part in INT_STR and the fraction part
! 98: in FRAC_STR. (This function would do a division of the numerator and the
! 99: denominator.)
! 100:
! 101: * Should mpz_powm* handle negative exponents?
! 102:
! 103: * udiv_qrnnd: If the denominator is normalized, the n0 argument has very
! 104: little effect on the quotient. Maybe we can assume it is 0, and
! 105: compensate at a later stage?
! 106:
! 107: * Better sqrt: First calculate the reciprocal square root, then multiply by
! 108: the operand to get the square root. The reciprocal square root can be
! 109: obtained through Newton-Raphson without division. To compute sqrt(A), the
! 110: iteration is,
! 111:
! 112: 2
! 113: x = x (3 - A x )/2.
! 114: i+1 i i
! 115:
! 116: The final result can be computed without division using,
! 117:
! 118: sqrt(A) = A x .
! 119: n
! 120:
! 121: * Newton-Raphson using multiplication: We get twice as many correct digits
! 122: in each iteration. So if we square x(k) as part of the iteration, the
! 123: result will have the leading digits in common with the entire result from
! 124: iteration k-1. A _mpn_mul_lowpart could help us take advantage of this.
! 125:
! 126: * Peter Montgomery: If 0 <= a, b < p < 2^31 and I want a modular product
! 127: a*b modulo p and the long long type is unavailable, then I can write
! 128:
! 129: typedef signed long slong;
! 130: typedef unsigned long ulong;
! 131: slong a, b, p, quot, rem;
! 132:
! 133: quot = (slong) (0.5 + (double)a * (double)b / (double)p);
! 134: rem = (slong)((ulong)a * (ulong)b - (ulong)p * (ulong)quot);
! 135: if (rem < 0} {rem += p; quot--;}
! 136:
! 137: * Speed modulo arithmetic, using Montgomery's method or my pre-inversion
! 138: method. In either case, special arithmetic calls would be needed,
! 139: mpz_mmmul, mpz_mmadd, mpz_mmsub, plus some kind of initialization
! 140: functions. Better yet: Write a new mpr layer.
! 141:
! 142: * mpz_powm* should not use division to reduce the result in the loop, but
! 143: instead pre-compute the reciprocal of the MOD argument and do reduced_val
! 144: = val-val*reciprocal(MOD)*MOD, or use Montgomery's method.
! 145:
! 146: * mpz_mod_2expplussi -- to reduce a bignum modulo (2**n)+s
! 147:
! 148: * It would be a quite important feature never to allocate more memory than
! 149: really necessary for a result. Sometimes we can achieve this cheaply, by
! 150: deferring reallocation until the result size is known.
! 151:
! 152: * New macro in longlong.h: shift_rhl that extracts a word by shifting two
! 153: words as a unit. (Supported by i386, i860, HP-PA, POWER, 29k.) Useful
! 154: for shifting multiple precision numbers.
! 155:
! 156: * The installation procedure should make a test run of multiplication to
! 157: decide the threshold values for algorithm switching between the available
! 158: methods.
! 159:
! 160: * Fast output conversion of x to base B:
! 161: 1. Find n, such that (B^n > x).
! 162: 2. Set y to (x*2^m)/(B^n), where m large enough to make 2^n ~~ B^n
! 163: 3. Multiply the low half of y by B^(n/2), and recursively convert the
! 164: result. Truncate the low half of y and convert that recursively.
! 165: Complexity: O(M(n)log(n))+O(D(n))!
! 166:
! 167: * Improve division using Newton-Raphson. Check out "Newton Iteration and
! 168: Integer Division" by Stephen Tate in "Synthesis of Parallel Algorithms",
! 169: Morgan Kaufmann, 1993 ("beware of some errors"...)
! 170:
! 171: * Improve implementation of Karatsuba's algorithm. For most operand sizes,
! 172: we can reduce the number of operations by splitting differently.
! 173:
! 174: * Faster multiplication: The best approach is to first implement Toom-Cook.
! 175: People report that it beats Karatsuba's algorithm already at about 100
! 176: limbs. FFT would probably never beat a well-written Toom-Cook (not even for
! 177: millions of bits).
! 178:
! 179: FFT:
! 180: {
! 181: * Multiplication could be done with Montgomery's method combined with
! 182: the "three primes" method described in Lipson. Maybe this would be
! 183: faster than to Nussbaumer's method with 3 (simple) moduli?
! 184:
! 185: * Maybe the modular tricks below are not needed: We are using very
! 186: special numbers, Fermat numbers with a small base and a large exponent,
! 187: and maybe it's possible to just subtract and add?
! 188:
! 189: * Modify Nussbaumer's convolution algorithm, to use 3 words for each
! 190: coefficient, calculating in 3 relatively prime moduli (e.g.
! 191: 0xffffffff, 0x100000000, and 0x7fff on a 32-bit computer). Both all
! 192: operations and CRR would be very fast with such numbers.
! 193:
! 194: * Optimize the Schoenhage-Stassen multiplication algorithm. Take advantage
! 195: of the real valued input to save half of the operations and half of the
! 196: memory. Use recursive FFT with large base cases, since recursive FFT has
! 197: better memory locality. A normal FFT get 100% cache misses for large
! 198: enough operands.
! 199:
! 200: * In the 3-prime convolution method, it might sometimes be a win to use 2,
! 201: 3, or 5 primes. Imagine that using 3 primes would require a transform
! 202: length of 2^n. But 2 primes might still sometimes give us correct
! 203: results with that same transform length, or 5 primes might allow us to
! 204: decrease the transform size to 2^(n-1).
! 205:
! 206: To optimize floating-point based complex FFT we have to think of:
! 207:
! 208: 1. The normal implementation accesses all input exactly once for each of
! 209: the log(n) passes. This means that we will get 0% cache hit when n >
! 210: our cache. Remedy: Reorganize computation to compute partial passes,
! 211: maybe similar to a standard recursive FFT implementation. Use a large
! 212: `base case' to make any extra overhead of this organization negligible.
! 213:
! 214: 2. Use base-4, base-8 and base-16 FFT instead of just radix-2. This can
! 215: reduce the number of operations by 2x.
! 216:
! 217: 3. Inputs are real-valued. According to Knuth's "Seminumerical
! 218: Algorithms", exercise 4.6.4-14, we can save half the memory and half
! 219: the operations if we take advantage of that.
! 220:
! 221: 4. Maybe make it possible to write the innermost loop in assembly, since
! 222: that could win us another 2x speedup. (If we write our FFT to avoid
! 223: cache-miss (see #1 above) it might be logical to write the `base case'
! 224: in assembly.)
! 225:
! 226: 5. Avoid multiplication by 1, i, -1, -i. Similarly, optimize
! 227: multiplication by (+-\/2 +- i\/2).
! 228:
! 229: 6. Put as many bits as possible in each double (but don't waste time if
! 230: that doesn't make the transform size become smaller).
! 231:
! 232: 7. For n > some large number, we will get accuracy problems because of the
! 233: limited precision of our floating point arithmetic. This can easily be
! 234: solved by using the Karatsuba trick a few times until our operands
! 235: become small enough.
! 236:
! 237: 8. Precompute the roots-of-unity and store them in a vector.
! 238: }
! 239:
! 240: * When a division result is going to be just one limb, (i.e. nsize-dsize is
! 241: small) normalization could be done in the division loop.
! 242:
! 243: * Never allocate temporary space for a source param that overlaps with a
! 244: destination param needing reallocation. Instead malloc a new block for
! 245: the destination (and free the source before returning to the caller).
! 246:
! 247: * Parallel addition. Since each processors have to tell it is ready to the
! 248: next processor, we can use simplified synchronization, and actually write
! 249: it in C: For each processor (apart from the least significant):
! 250:
! 251: while (*svar != my_number)
! 252: ;
! 253: *svar = my_number + 1;
! 254:
! 255: The least significant processor does this:
! 256:
! 257: *svar = my_number + 1; /* i.e., *svar = 1 */
! 258:
! 259: Before starting the addition, one processor has to store 0 in *svar.
! 260:
! 261: Other things to think about for parallel addition: To avoid false
! 262: (cache-line) sharing, allocate blocks on cache-line boundaries.
! 263:
! 264:
! 265: Local Variables:
! 266: mode: text
! 267: fill-column: 77
! 268: fill-prefix: " "
! 269: version-control: never
! 270: End:
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to PROJECTS CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [local] / OpenXM / src / kan96xx / gmp-2.0.2