On 5 Dec 2006, at 3:22 PM, Brian Gladman wrote:
>
> For AES the round function and key scheduling cost per
round are
> basically the same for both AES-128 and AES-256. In
consequence I
> would
> expect the speed ratio to be close to the ratio of the
number of
> rounds,
> which is 14 / 10 or 40%.
>
> My own figures on AMD64 are 1.35 for encryption and
1.39 for
> decryption.
> And on a P4 they are 1.36 and 1.38 respectively. These
are hence close
> to the expected 40% figure.
>
> This suggests to me that a figure around 20% would
apply in
> applications
> in which about half the time is spent in encryption and
half in other
> higher level activities.
>
> Can I hence assume that your benchmark is being run at
application
> level
> rather than algorithm level? If not why is the ratio
only 22% on the
> PPC-32?
That was using pgp --speed-test. It's an algorithm-level
test, but
it's calling the SDK so there's some API-level overhead
involved. I
got the number from a 3.0GHz x86, and it was 1.36 for
encryption and
1.37 for decryption. But I also got the numbers from a 2GHz
Core Duo
laptop and it was 1.12 for encryption and decryption. On the
other
hand, the fast machine was encrypting AES-128 at 66389.45
KB/s and
the slow one at 22217.39 KB/s, which means that the 3GHz
machine is
running at just shy of 3x the speed of the 2GHz machine!
Obviously, there are other factors, such as cache, memory,
and so on
that are huge differences. I'd take a "slowdown"
of 12% to 40% if I
was getting a 300% base speedup.
Jon
------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomo metzdowd.com
|