BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

你可能错过的东西:.NET 3.5 SP1中的JIT增强

| 作者 Jonathan Allen 关注 530 他的粉丝 ,译者 朱永光 关注 0 他的粉丝 发布于 2008年10月7日. 估计阅读时间: 2 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

在.NET平台里,大部分编译器的优化并不是通过VB和C#编译器来完成的。它们宁可把优化的处理推后到CLR的即时(Just In Time,JIT)编译器读取IL,并转换为原生机器码的时候来完成。由于这个原因,对JIT的改变会极大地影响之前编译好的程序集。

一个主要的影响就是内联函数(Inlining Function)调用。之前,JIT对内联方法的处理非常保守,Vance Morrison解释了个中缘由

它对内联的处理并不是很好。内联总是减少指令执行的数量(这是由于最低限度的调用和返回指令没有被执行),但是它能(并经常)让结果代码变得很大。大部分人都能直觉地理解,内联大的方法(比如1Kb的)不是很有意义,而内联非常小的方法可以让调用的占用空间更小(由于调用指令才5字节),这样的选择总是正确的,但是介于两者之间的方法要如何处理呢?

有趣的是,当你让代码变大时,你也就让它执行缓慢,因为内存天生地缓慢;你的代码越大,它越不会放在最快的CPU缓存(称之为L1)里面执行,在那样的情况下,处理器需要执行3-10个周期直到它能从另外的缓存(称之为L2)中获取到执行代码,如果L2缓存中还不存在,那么就需要到主内存中获取(需要花费10+周期)。对于在紧密循环中执行的代码,这样的结果不会有什么问题,因为所有的代码都适合放入到最快缓存中(典型的是64K),不过对于“常规的”代码,它通过大量的方法来执行大量的代码,“越大就越慢”的效果就非常显著。更大的代码也就意味着在启动时从磁盘获取代码需要更大的磁盘I/O,这就意味着你的应用程序启动较慢。

在Service Pack 1中,微软引入了一个新的基于代码尺寸的启发式算法,来判断调用是否处于一个循环中。在常规情况下,函数只有当在调用空间中的结果机器码比原始版本要小时,才能被内联。这样做就保证了尽可能多的代码能适合CPU的缓存,当缓存不够用时,就能对性能产生巨大的影响。

当处在循环中时,分部异常也可以很好地工作。这是因为据推测函数通常会被多次调用,所以CLR允许内联函数可以增长至原始调用大小的5倍大。类似值类型优化这样的条件有可能更进一步地增加容许尺寸的大小。

查看英文原文:In Case You Missed It: JIT Enhancements in .NET 3.5 SP1

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT