Benchmarking GMP gives poor results for small numbers

[Torbjorn Granlund]

"Richard Cavell" <richardcavell at mail.com> writes:

  These results were obtained factorizing a 256-bit number using a Mac G4,
  which has a 32*32bit = 64bit answer hardware multiply (though you need two
  instructions to access the full result).

  Number 1 : GMP - 66 seconds.  My code - 5 seconds.
  Number 2 : GMP - 694 seconds.  My code - 73 seconds.
  Number 3 : GMP - 555 seconds.  My code - less than 1 second.

You are experiencing more overhead than usually seen.  You might
still be using GMP's mpz layer inefficiently.

  So I don't want to knock GMP code so much as I want to tell people that for
  numbers less than about 1024 bits, I strongly recommend using your own code
  for performance.

I think this is a really poor piece of advice in general, for
several reasons.

Firstly, it is really hard to get such code correct.  (I suppose
you agree after your project here.  And have you made likely that
it is really correct, after having sorted the most obvious bugs,
using long test sequences from something like mpn_random2?)

Secondly, I would be really surprised if anybody can beat GMP
with a C program at 1024 bits for any of the many platforms GMP
supports.  GMP's assembly loops will outperform any C code, and
overhead is not that bad once you're at 1024 bits.

But as Karl Hasselström points out, the mpn layer is there for
critical applications.  It requires more work to use than mpz,
but a lot less work than writing and testing your own routines.

--
Torbjörn