two possible coding porjects

Torbjorn Granlund
05 Aug 2003 02:15:11 +0200 writes:

  True.  Doesn't mean you have to squander resources.  Of course,
  single-limb quantities don't arise often as results of arbitrary
  integer computations but I'm on a 64-bit machine so anything
  with a FP result would fit, as would numerator and/or denominator
  of many rational numbers.  (actually, one and zero come up
  fairly often.  EG, GCD(rand,rand)=1 most of the time.)

We sometimes check for small operands, when we think that will
help, and as our time permits.  If you think there is room for
improvements, and have time to write good patches, then jump in.

  Even if you don't have a direct mapped cache, any unused (or
  unneceaary) bytes adjacent to a value in the cache wastes space
  in that cache line that could have something valuable in it.

If you are concerned by this sort of things, you need to write
your application to use mpn functions only.  More user-friendly
function levels are just not fit for you.

  I know you know all this, but I get the feeling you guys focus more
  on the processor pipelines than on the memory hierarchy.

What makes you assume that?

We focus more on processor pipelines than things that are of less
relevance to GMP's performance.  We certainly worry about caches
in GMP.

  For many applications this is appropriate, since you're working
  with a handful of variables that all fit in L2 if not L1.  I've
  filling all available temporary and swap space with numbers,
  all of which get visited as it runs.  I have to think about
  scheduling the page faults and the cache fills.

If you have zillions of variables, and even get your system to
thrash, surely you're not suggesting that we should change GMP to
handle such things for you automatically?

  Sorry if any of the above reads harshly, [snip]

If you want GMP to be improved, you need to suggest concrete
improvements, or point at specific shortcomings and hope for the
GMP authors to address them.  I am not sure your present GMP
critique is leading us forwards.

[Please move this discussion to gmp-discuss.  I will reject
further messages to gmp-devel, unless they contain substantial
technical contents.]