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 [EMAIL PROTECTED]
