Re: memxor

[Bruno Haible]

Nikos Mavrogiannopoulos wrote:
> As an unrelated suggestion for memxor.c I had a discussion with
> another project about that and we concluded on a gmp-based
> version that is orders of magnitude faster. It would
> be nice if gnulib included the optimized code by default.

If you mean gmp's mpn_xor function, written in assembly language:
It would be a bad idea to include assembly language code in gnulib,
because the maintenance cost of such code is very high. Assembly language
source code depends on
  - the cpu family,
  - the wordsize (32 vs. 64 bit),
  - the cpu instruction set (think of 486 vs. 586 vs. MMX etc.),
  - the assembler syntax (2 syntaxes for i386, 2 syntaxes for ARM etc.),
  - the format of unwind tables (for C++ exception support),
  - various alignments.

A more portable approach to optimizing tight loops might be to use a
Fortran compiler, knowing that Fortran has 'restrict' built-in for
decades whereas it's relatively new for C.

Additionally, memxor is not speed critical, AFAIK. Can you tell me one
program which spends more than 20% of its runtime in memxor?

memxor implements the addition in the GF(2^q) field, when using a vector
space representation of the elements. But with this representation, the
multiplication is much more costly and therefore in practice overshadows
the time spent in memxor. And with the other, logarithmic, representation
of elements of GF(2^q), the multiplication is fast - a simple addition -
and the addition is a table lookup. So, no memxor in this case at all.

In summary, I find it pointless to optimize memxor in isolation.
(Whereas it makes sense to optimize memxor if all the other arithmetic
operations are also optimized.)

Bruno
-- 
In memoriam Victims of the Katyn massacre 
<http://en.wikipedia.org/wiki/Katyn_massacre>
<http://www.solidarni.waw.pl/ssw/pdf/Katyn1940/Katyn-unresolved_genocide_in_Europe.pdf>