Jan*_*Jan 6 .net c# jit ngen ryujit
在.NET 4.6下,Ngen和RyuJIT是两个完全不相关的东西(特别是使用不同的优化技术和算法)？
如果我们不关心自身抖动和/或冷/热启动时间的成本,那么什么产生最快(更好的优化)x64本机代码？
我们正在运行一个长期运行的服务器应用 连续运行阶段在性能方面非常重要.(预)启动阶段对我们来说并不重要.到目前为止,我们已经使用.NET 4.5并且始终由Ngen生成本机映像.我们现在正在升级到.NET 4.6,我们希望确保这不会降低我们持续运行阶段的性能.我已经阅读了一些信息,RyuJIT是改善JITing时间的绝佳选择,但是与Ngen相比,jited代码可能没有那么优化 - 参见例如关于其中一个RyuJIT错误的github评论.
Han*_*ant 11
NGen和RyuJIT之间没有足够的区别让你开心.他们做了非常不同的工作,提前NGen jits和RyuJIT在流程运行时及时进行.但NGen没有自己的抖动,它要求RyuJIT完成工作.生成的机器代码没有根本不同.有一些优化无法预先完成,NGen-ed代码稍慢.
从技术上讲,NGen可以做得更好,因为优化器可以花更多的时间分析代码并尝试找到最佳的优化.但微软没有利用这一点.它不完全是水晶,为什么他们不会,但肯定与他们的1-800支持电话号码有关.代码优化始终是代码生成器中最危险的部分,现有抖动中的错误始终是优化错误.这有可能在某一天发生变化并非不可想象.
当你可以利用.NET Native时,你会领先.它使用C++编译器的后端提前生成代码.但是目前,肯定会在相当长的一段时间内,它只支持打包的应用程序.通过Windows应用商店提供的类型,您必须以Store,Phone或Universal为目标,并使用Store作为部署工具.该软件包对于使.NET Native工作非常重要,只有它才能看到需要翻译的代码.而且它通常仍然需要帮助来实现正确,反射是一个难以解决的问题,也就是你在机器上拥有它的原因.请注意,NGen不存在相同的问题,它仍然依赖于抖动来及时获取一些代码.像反射目标代码和泛型.这有可能在某一天发生变化并非不可想象.
如上所述,NGen代码略慢.因此,如果您不关心热启动延迟,那么您不想使用NGen.
最后但并非最不重要的,RyuJIT并不会产生比其前身快代码.这已经做了非常好的优化工作.太体面了.RyuJIT项目开始修复传统x64抖动中的问题,这种问题在代码库中非常基础,只能通过大幅重写才能解决.优化就是其中之一,它在花费的时间上没有上限.在大型方法上给予非常不合理的jitting时间.因此,如果你想挤压最后一盎司,那么故意禁用RyuJIT,以便它回归到传统的x64抖动是你应该尝试的.
| 归档时间： |
|
| 查看次数： |
1653 次 |
| 最近记录： |