Re: [PATCH 4/4] Twofish cipher - x86_64 assembler

From: Joachim Fritschi
Date: Mon Jun 05 2006 - 15:45:59 EST


On Monday 05 June 2006 19:44, dean gaudet wrote:
> On Mon, 5 Jun 2006, Joachim Fritschi wrote:
> > Here are the outputs from the tcrypt speedtests. They haven't changed
> > much since the last patch:
> >
> > http://homepages.tu-darmstadt.de/~fritschi/twofish/tcrypt-speed-c-i586.tx
> >t
> > http://homepages.tu-darmstadt.de/~fritschi/twofish/tcrypt-speed-asm-i586.
> >txt
> > http://homepages.tu-darmstadt.de/~fritschi/twofish/tcrypt-speed-c-x86_64.
> >txt
> > http://homepages.tu-darmstadt.de/~fritschi/twofish/tcrypt-speed-asm-x86_6
> >4.txt
>
> when you quote anything related to cpu performance on an x86 processor
> it's absolutely essential to indicate which cpu it is... basically
> vendor_id, cpu family, and model from /proc/cpuinfo. (for example the
> entire p4 family has incredible model-to-model variation on things like
> shifts and extensions.)

x86_64 benchmarks where done on a:
vendor_id : AuthenticAMD
cpu family : 15
model : 35
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
stepping : 2
cpu MHz : 2200.000
cache size : 1024 KB
SMP was disabled

x86 benchmarks where done on a:
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Athlon(tm) XP 2400+
stepping : 1
cpu MHz : 1991.695
cache size : 256 KB

> > > > +/* Defining a few register aliases for better reading */
> > >
> > > Maybe you can read it now better, but for everybody else it is extremly
> > > confusing. It would be better if you just used the original register
> > > names.
>
> i'd change the comment to:
>
> /* define a few register aliases to simplify macro substitution */
>
> because as you mention, it's totally impossible to write the macros
> otherwise. (i've used the same trick myself a bunch of times.)

Sounds ok to me. It was the main reason to use these aliases. For me it also
improves readability but as author my view is probably a bit distorted ;)

Joachim

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/