我做了一个小测试基准,比较了.NET的System.Security.Cryptography
AES实现与BouncyCastle.Org的AES。
链接到GitHub代码:https://github.com/sidshetye/BouncyBench
我对AES-GCM特别感兴趣,因为它是一个'更好'的加密算法,.NET缺少它。我注意到虽然AES实现在.NET和BouncyCastle之间非常可比,但GCM性能非常差(请参阅下面的额外背景以获取更多信息)。我怀疑这是由于许多缓冲区副本或其他东西。为了更深入,我尝试分析代码(VS2012 => Analyze
菜单栏选项=> Launch performance wizard
)并注意到mscorlib.dll中有很多CPU烧录
问题:在这种情况下,我怎么能弄清楚大部分CPU吃了什么? 现在我所知道的是“在Init()中的一些行/调用在mscorlib.ni.dll中刻录了47%的CPU“ - 但不知道具体的哪些行,我不知道在哪里(尝试和)优化。有线索吗?
额外背景:
基于David A. McGrew撰写的“ The Galois / Counter Mode of Operation(GCM)”论文,我读到“二进制字段中的乘法可以使用各种时间 - 内存权衡。它可以在没有依赖于密钥的内存的情况下实现,在这种情况下,它通常比AES慢几倍。愿意牺牲适量内存的实现可以很容易地实现大于AES的速度< /强> “
如果你看结果,基本的AES-CBC发动机性能非常可比。 AES-GCM添加了GCM并在CTR模式下重用AES引擎(比CBC更快)。然而,除了CTR模式之外,GCM还在GF(2 ^ 128)字段中增加了乘法,因此可能存在其他减速区域。无论如何,这就是我尝试分析代码的原因。
对于感兴趣的人,我的快速测试性能基准在哪里。它位于Windows 8 VM和YMMV中。测试是可配置的,但目前是模拟加密数据库的许多单元格的加密开销(=>很多但是很小的明文输入)
Creating initial random bytes ...
Benchmark test is : Encrypt=>Decrypt 10 bytes 100 times
Name time (ms) plain(bytes) encypted(bytes) byte overhead
.NET ciphers
AES128 1.5969 10 32 220 %
AES256 1.4131 10 32 220 %
AES128-HMACSHA256 2.5834 10 64 540 %
AES256-HMACSHA256 2.6029 10 64 540 %
BouncyCastle Ciphers
AES128/CBC 1.3691 10 32 220 %
AES256/CBC 1.5798 10 32 220 %
AES128-GCM 26.5225 10 42 320 %
AES256-GCM 26.3741 10 42 320 %
R - Rerun tests
C - Change size(10) and iterations(100)
Q - Quit
答案 0 :(得分:1)
这是微软的一个相当蹩脚的举动,因为它们明显打破了在Windows 8之前运行良好的功能,但不再如this MSDN blog post中所述: :
在Windows 8上,探查器使用不同的基础技术 它在以前版本的Windows上做了什么,这就是为什么 在Windows 8上的行为是不同的。随着新技术的发展 profiler需要符号文件(PDB)才能知道函数是什么 目前正在NGEN的图像中执行。
(...)
然而,我们的待办事项是在Visual Studio的下一个版本中实现的。
帖子给出了自己生成PDB文件的说明(谢谢!)。