GMP 4.3 multiplication performance

Torbjorn Granlund tg at gmplib.org
Wed Jun 3 16:16:44 CEST 2009


nisse at lysator.liu.se (Niels Möller) writes:

  Actually, in this case it should be trivial to add a new assembler
  entrypoint to submul_1, which converts a input shift count to a
  multiplier for submul_1, and then jumps to submul_1. But why do that
  in machine-spepcific assembler, if you can just as well do it as a cpp
  macro, and make it work generally and automatically based on
  parameters from tuneup?
  
Sure, a macro is portable and avoids doing a constant shift at runtime.
I think it makes sense to default sublsh_n to submul_1 iff we add tuneup
measurement for this and it is determined to be a good thing.  (Actally,
one may choose to do this statically in relevant gmp-mparam.h files,
tuneup does not necessarily need to measure this sort of simple things.)

  But sure, it could be done locally in each file that uses sub_lshift.
  
  Talking about code cleanup, I think there's a lot of duplication in
  the toom evaluation code. Would the overhead be aceptable if one
  writes a function for, e.g., evaluating a degree four polynomial in
  the points +1 and -1? Or would it make sense with macros (say,
  collected into toom-macros.h, if we want to put it all into
  gmp-impl.h)? This particular helper function would be used by toom43
  (once), toom44 (twice), toom54 (once), assuming all these variants use
  this point pair.
  
In what way would that help?

Alright, the text size of GMP could be reduced somewhat.  But would the
complexity go down?  Would GMP be easier to maintain?  I am not sure.

I like exposing what is going on, since then when I regularly return to
existing code to look for improvements, I see what is really going on.

Macros/function like the ones you suggest for evaluation tend to obscure
common subexpressions that could be manually combined.  I'd like to
avoid that.

But if we're sure things cannot be improved, and the overhead of
function calls are no problem in this case, and the saved object code
size is not insignificant, then this is a good idea.

-- 
Torbjörn


More information about the gmp-devel mailing list