These are the results I got: *Version 5.5.2* Algorithm MiB/Second Microseconds to Setup Key and IV AES/CFB (128-bit key) 82 0.451 AES/CFB (256-bit key) 66 0.528
*Version 5.6.0* Algorithm MiB/Second Microseconds to Setup Key and IV AES/CFB (128-bit key) 73 0.667 AES/CFB (256-bit key) 61 0.760 *Version 5.6.0 without dynamic_cast checking (lib modified)* Algorithm MiB/Second Microseconds to Setup Key and IV AES/CFB (128-bit key) 73 0.661 AES/CFB (256-bit key) 61 0.716 *My setup:* Windows XP Professional Version 2002 SP 3 AMD Athlon II X2 240 2.81GHZ 3.25 GB of RAM (used by the OS) MS VC6 SP 6 All tests were run under similar conditions. These results match the ones I got using my test app; version 5.5.2 still seems to perform better than 5.6.0. Removing the dynamic_cast checking doesn't seem to make a difference. Any other ideas ? Thanks, Walt. On Tue, Jan 26, 2010 at 7:55 AM, Chris Morgan <[email protected]> wrote: > The benchmarks page says they are a part of the source code package. > You should run these and see how your numbers compare so there is a > equivalence baseline. If the numbers match then looking at the > particulars of your test vs the one in the benchmark seems the next > logical thing to do. If they don't match then we should look at > comparing CPU specs, compiler versions, OSes etc. > > Chris > > > On Tuesday, January 26, 2010, Walter Villalba <[email protected]> wrote: > > I'm not sure how the official benchmarks were generated, but Wei Dai sent > them to me a while ago. Full benchmarks for version 5.6.0: > http://www.cryptopp.com/benchmarks.html > > > > <http://www.cryptopp.com/benchmarks.html>The results I got using my > little test app were run under similar OS conditions. The app basically > encrypts and decrypts 1.5mb of text ( actually it was 2016 bytes by the time > I got these results, but then I changed it to 1.5mb ), 200000 times, and > measures the time it takes to do that ( this time does _not_ include set up > time ). I compiled it against both versions, 5.5.2 and 5.6.0, and then > ran it on my system. > > > > I just removed the dynamic_cast check, compiled against the library and > then my test app, and got better results, but still not as good as the ones > I get with version 5.5.2. > > > > v5.6.0 without dynamic_cast (lib modified)128-bit key: 11, 12, 11, 11, 11 > secs256-bit key: 13, 13, 13, 12, 13 secs > > v5.5.2128-bit key: 11, 10, 10, 11, 10 secs > > 256-bit key: 12, 12, 12, 12, 12 secs > > As you can see, version 5.5.2 still performs better. > > Walt. > > > > On Tue, Jan 26, 2010 at 7:25 AM, Chris Morgan <[email protected]> > wrote: > > Ahh, it wasn't obvious that your results differed, I thought you > generated the chart. > > > > How were the original numbers generated? If they come from an app inside > of cryptopp then are the input parameters close to the same? Same input > buffer sizes etc? What happens if you run on your system the app that > generated the claimed results? > > > > > > You would have to look to see if that dynamic cast could be removed. > Adding a print message there, or a breakpoint under a debugger, would let > you see if that code path was taken. I don't know if rtti is necessary for > other c++ operations other than the dynamic cast. > > > > > > Chris > > > > > > > > On Jan 26, 2010, at 10:11 AM, Walter Villalba <[email protected]> > wrote: > > > > > > Hi Chris, > > Thanks a lot for your response. Whether or not RTTI can be disabled is > one of the questions. There's only one usage of dynamic_cast in version > 5.6.0 of the library. I am not able to run my little test app if I don't > enable RTTI for it ( regardless of enabling RTTI or not when I compile the > library. Weird. ) > > > > > > > > The results don't look good at all, that's why I'm concerned. The image > I sent are the official benchmarks, and they show AES performance was > improved in version 5.6.0, but the results I'm getting do _not_ show this. > Quote from my previous email: > > > > > > > > > > > > 128-bit key > > Release-v5.5.2-PPro-NoRTTI > > 16 / 16 / 16 / 16 / 16 > > Release-v5.5.2-PPro-RTTI > > 16 / 16 / 16 / 16 / 15 > > Release-v5.6.0-PPro-NoRTTI > > "Access violation - no RTTI data!" error > > Release-v5.6.0-PPro-RTTI > > 18 / 18 / 18 / 18 / 19 > > > > 256-bit key > > Release-v5.5.2-PPro-NoRTTI > > 17 / 18 / 17 / 17 / 18 secs > > Release-v5.5.2-PPro-RTTI > > 18 / 18 / 18 / 18 / 17 secs > > Release-v5.6.0-PPro-NoRTTI > > "Access violation - no RTTI data!" error > > Release-v5.6.0-PPro-RTTI > > 21 / 21 / 20 / 21 / 21 secsFor instance, AES 128-bit using version 5.5.2 > takes 16 secs, and the same app compiled using version 5.6.0 takes 18. The > source code was included in my first email. > > > > > > > > So AES seems to perform better in version 5.5.2 than in version 5.6.0, > exactly the opposite as expected. > > Any ideas ? Again, thanks a lot. > > Walt. > > > > > > > > > > On Tue, Jan 26, 2010 at 6:56 AM, Chris Morgan <[email protected]> > wrote: > > > > Is the question whether or not Rtti can be disabled? If there are any > dynamic casts then probably not. You could always try to disable it and see > if things run :-) > > > > Otherwise the results look good, significant improvement between 5.5.2 > and 5.6. > > Chris > > > > > > > > On Jan 26, 2010, at 9:35 AM, Walter Villalba <[email protected]> > wrote: > > > > Anyone ? > > > > On Wed, Jan 20, 2010 at 1:22 PM, Walter Villalba <[email protected]> > wrote: > > > > > > Acc > > > -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com.
