Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 5 May 2011 23:50:56 +0400
From: Solar Designer <>
Subject: Re: AVX in Intel Sandy Bridge

On Sat, Apr 30, 2011 at 02:24:13PM +0400, Solar Designer wrote:
> Apparently, it might be possible to achieve some speedup by mixing
> 128-bit and 256-bit AVX ops.  I tried many different combinations, but
> not this one.  I will likely give it a try.

I gave it a try yesterday, on a Core i7-2600K, non-overclocked (3.4 GHz
standard, up to 3.8 GHz Turbo Boost), Ubuntu 11.04, x86_64, Ubuntu's gcc
4.5.2.  No luck.

1.7.7 as-is (128-bit AVX):

Benchmarking: Traditional DES [128/256 BS AVX]... DONE
Many salts:     5004K c/s real, 5054K c/s virtual
Only one salt:  4184K c/s real, 4184K c/s virtual

384-bit virtual vectors (256+128):

Benchmarking: Traditional DES [256/256 BS AVX + 128/128 BS AVX]... DONE
Many salts:     3661K c/s real, 3698K c/s virtual
Only one salt:  3188K c/s real, 3188K c/s virtual

Yet I am going to commit the code (disabled by default) - for testing on
future CPUs, etc.

I also experimented with 32-bit builds (after "aptitude install
libc6-dev-i386" and having added "-m32" into the proper make targets).
I am pleased that I had correctly predicted that 256-bit AVX would be
faster than 128-bit for 32-bit builds (with only 8 vector registers
available).  (I did not actually test this before.)

Here are the numbers for 32-bit builds.

256-bit AVX (default in 1.7.7 for 32-bit builds):

Benchmarking: Traditional DES [256/256 BS AVX]... DONE
Many salts:     4238K c/s real, 4281K c/s virtual
Only one salt:  3456K c/s real, 3456K c/s virtual

128-bit AVX (a trivial change to x86-sse.h):

Benchmarking: Traditional DES [128/256 BS AVX]... DONE
Many salts:     3490K c/s real, 3525K c/s virtual
Only one salt:  2938K c/s real, 2938K c/s virtual

BTW, I think that my use of 128/256 in the algorithm name was wrong -
we're actually telling the CPU that we're using 128-bit vectors, so it
is not entirely correct to say that we're only using 128 out of 256
bits, which is what the notation was meant to be used for (e.g., it is
used like that when it says 48/64 for non-bitslice DES).  Thus, I am
going to change these to say 128/128 for the next version.


Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ