[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: memxor

From: Bruno Haible
Subject: Re: memxor
Date: Tue, 12 Apr 2011 11:21:26 +0200
User-agent: KMail/1.9.9

Hello Nikos,

> > Can you tell me
> > one program which spends more than 20% of its runtime in memxor?
> I had 10% speed-ups in a web server that used gnutls with the optimized
> version of memxor. That is because CBC encryption mode uses XOR heavily.
> 10% is enormous speed-up considering that this is a very small part of
> the encryption process.

OK, that is sufficient rationale for having this faster memxor function in

The next question, also to Simon, is whether you want to have the faster
memxor only in gnutls and leave the slower but simpler one in gnulib
(used by the modules crypto/*hmac-* only). Or whether you want to have the
faster one in gnulib.

In the latter case, we need an implementation:

>  I meant the linked memxor implementation[0]. It is plain C code, and
> XOR was being done per CPU word, not per byte.
> [0].
> http://cvs.lysator.liu.se/viewcvs/viewcvs.cgi/lsh/nettle/memxor.c?rev=1.4&root=lsh&view=auto

If you can convince Niels Möller to assign the copyright of this code to
the FSF, you can use this. Otherwise you can also take gnulib/lib/memcmp.c
as starting point, eliminate the memory of Niels' code from your brain, and
do the necessary modifications yourself (and we would like you to assign the
copyright for this gnulib contribution, likewise).

Additionally, such highly optimized requires a unit test. Here you are lucky
and can take the union of gnulib/tests/test-memcmp.c and
gnulib/tests/test-memchr.c as starting point.

If you also want to have a memxor3 in gnulib, make it a separate module.
It can share the lib/memxor.h file with the memxor module, though; no need to
have two separate .h files for so tightly related functions.

In memoriam Matthias Domaschk <http://de.wikipedia.org/wiki/Matthias_Domaschk>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]