AES performance

[Bert Belder]

Hey all,

Within aes-x86_64.pl, I found this code:

mov OPENSSL_ia32cap_P(%rip),%r10d
cmp \$$speed_limit,%rdx
jb .Lcbc_slow_prologue
test \$15,%rdx
jnz .Lcbc_slow_prologue
bt \$28,%r10d
jc .Lcbc_slow_prologue

The last two lines make sure that x86_64_AES_encrypt_compact is used on
processors that support hyperthreading. I found that on my machine (a retina
macbook with an Intel i7-3720QM processor) this makes AES encryption much
slower (by about 35%).

Can anyone enlighten me on why openssl wants to use the "slow" version on
machines that support hyperthreading?

Thanks in advance,
Bert

______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List opens...@openssl.org
Automated List Manager majo...@openssl.org

[Yann Droneaud]

Le mercredi 19 septembre 2012 à 23:49 +0200, Bert Belder a écrit :
> Hey all,
>
> Within aes-x86_64.pl, I found this code:
>
> mov OPENSSL_ia32cap_P(%rip),%r10d
> cmp \$$speed_limit,%rdx
> jb .Lcbc_slow_prologue
> test \$15,%rdx
> jnz .Lcbc_slow_prologue
> bt \$28,%r10d
> jc .Lcbc_slow_prologue
>
> The last two lines make sure that x86_64_AES_encrypt_compact is used on
> processors that support hyperthreading. I found that on my machine (a retina
> macbook with an Intel i7-3720QM processor) this makes AES encryption much
> slower (by about 35%).
>
> Can anyone enlighten me on why openssl wants to use the "slow" version on
> machines that support hyperthreading?
>

Here is a probable explaination:
(from http://thread.gmane.org/gmane.comp.encryption.openssl.devel/19942
)

> From OpenSSL-0.9.8 to OpenSSL-1.0.0, when using ASM version, AES
> encryption speed goes down. It's not a regression: the ASM version
> was tweaked to handle some shared cache attack vector:

>From Andy Polyakov <ap...@openssl.org>:
> Assembler appears slower, because it's taking code path resistant to
> cache-timing attacks [on multi-core CPUs with shared cache].

http://thread.gmane.org/gmane.comp.encryption.openssl.devel/19836


Regards.

--
Yann Droneaud