【C/C++_非_值班室】归来哟,故乡的云:Inline再讨论 (翻译)星星兄们,进来帮个忙。外加放分引人看~

dot99 2004-07-13 09:03:22
下面的文章翻译自GotW.
由于最近工作+学校的原因,暂时不会上网了,要等把所有事情都搞定了再说~
后面两段没翻译完,留在硬盘里面又觉得心里面痒,大家帮忙翻译一个~

用句常用的话拜托一下:“冰天雪地裸女960度回旋飞跪,泪如雨下,声嘶力竭,xxxx, ...., ****, @@@@, 拜托了~~~~”(这女的好累...)

====================

归来哟,故乡的云:Inline再讨论

作者: Herb Sutter
翻译: hardcoreX.雪糕.dot99.计算机她姑爹 (其实都是我)

快!选择一个。

什么时候内联表现出来?

A.写代码的时候
B.编译的时候
C.连接的时候
D.程序装入的时候
E.运行期
F.其他某个时候

另外:什么函数能够保证永远不会被内联?

打住!想想,然后再往下看。

你选啥呢?如果你选了A或者B,呵呵,你有伴了。这两个是常见的答案,去看看[1]的第十二款,我对C++中inline关键字的详细讨论。如果那解释就够了的话,我们就停在这里了,放编辑们一个假,然后再把剩下的栏目做了。但是现在不能,因为还有好多要讨论,很多很多。

我写这篇文章是想说明:第一个问题的最准确的答案是“全部正确或者没有一个正确。”第二个问题的答案是“没有。”为什么呢?继续往下看。

如果一已经阅读了[1]的第十二款,下面的部分就是一个复习,如果你没有思考过C答案的话,你也可以轻轻掠过。

简单的说,“内联行为(inlining)”就是将函数在调用的地方原地展开函数体。看看下面的代码:

// Example 1
//
double Square( double x ) { return x * x; }

int main() {
double d = Square(3.14159 * 2.71828 );
}

内联后,这个函数调用就好像以如下代码替代了(概念上):

int main() {
const double __temp = 3.14159 * 2.71828;
double d = __temp * __temp;
}

这个内联动作消除了调用函数的开销,即是参数压栈和代码转移的开销,因而也省去了临时引用(losing some locality of reference)。这个内联行为不等同于宏,因为一个内联函数调用一样的是一个函数调用,它的参数只被评估[译注:平时都叫“计算”,但是我觉得这里用“评估”比较好]一次。但是,一个宏则要将它评估多次,即宏#define SquareMacro(x) ((x)*(x))在调用的时候,如SquareMacro(3.14159*2.71828),要被展开为3.14159 * 2.71828 * 3.14159 * 2.71828(计算PI*e两次,而不是一次)。

顺便提一下,你注意到例1出现内联行为(inlining)没有?我们没有使用关键字inline。这是故意的。等下我们还要来讨论这个有趣的问题。

答案A:写代码的时候
当开发者们写程序的时候,念出inline的咒语。那不是真正的就内联(没有发生内联行为),只是一个想要内联试图而已,所以,我们可以将A看做是最早的决定内联动做(inlining)的一个机会。

当你试图在你的代码里面写上inline关键字的时候,你必须要记得三件重要的事情。

首先,不要那么做。过早的优化会带来麻烦,你不应该在没有证明需要加入inline才能提高效率的情况下试图加入这个关键字。翻翻[1]的第十二款和[3],里面夸张地指责和严重警告这种程序过早优化和过早决定内联的行为。

它(inline)仅仅是“请,一定要”的意思。这个在[1]的第十二款说过,inline关键字只不过是对编译器的暗示,让你巴结(sweet talk)编译器,让他给你这样做。(关于”巴结”的卑劣行径,下面讨论。)这就是全部:inline关键字并没被要求在C++程序中拥有任何语义上的效果。它并没有影响到标准语言的其他部分,用了inline关键字并没有要你改变函数的用法(例如,你仍然可以获得这个函数的地址),也不可能要标准C++编译器去检测一个函数究竟被声明为内联没有。

行为(inlining)真正表现出来,是在调用的时候。这个差别非常重要,因为这个函数能(应该经常能)在被调用的地方被内联而不是其它的地方;写下inline没有给你任何方式去表达这个事实。因为我们能做的只有在函数前面写inline关键字,我们这样做了,是给编译器含蓄的说,这个函数适合在调用的地方内联。这个预见[译注:内联一个函数]很少准确。我们经常说“内联这个函数”, 准确的说,你最好增加一下你的词汇量,应该是“内联这个函数的调用”("inlining a function call")

答案B:编译的时候
在编译的时候,编译器会像例1那样例行公事。

编译器会做什么?当我们勾对她(sweet-talk it, 哈哈哈),给她说,这个函数要内联的时候。这个要看是谁了。并不是所有女人[译注:原文是编译器]对甜言蜜语有反应,甚至在巧克力和鲜花的轰炸下。有时,你的编译器(或者其他工具)会不甩你而我行我素:

l 拒绝内联你要求内联的函数调用。
l 内联你并没有声明的函数的调用。
l 内联一些函数调用而不管声明要内联没有,或者一些地方内联,另外一些地方则不。

再注意例1,我们并没有在任何地方写下“inline”。这是故意的,我是想说明,那个样子一样会发生内联行为。确实是,不需要对你现在使用的编译器所做的一切大惊小怪。因为,你也不能再写出一个其他的程序来找茬,这是一个合理的优化,编译器能(而且经常能)为了你的利益着想。

现在的编译器能比程序员在决定那个函数调用需要内联上要出色,包括是否要展开同一个函数在某个调用的地方,而不在另外的地方。为什么?最简单的答案是,编译器比你知道得要多,它知道调用的“真实”的结构——函数调用被优化后的机器码,包括解开循环和去除无效分枝(“if-else”, “switch-case”),所有的这些工作,编译器都做了。例如,编译器也许会检测到这个被内联的函数如果放进一个循环里面,会使这个循环过大,而代码cache不能容纳,导致整体性能下降。编译器会选择在这个循环里面不内联这个函数调用,而也许会在其他地方内联它。


...全文
293 21 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
21 条回复
切换为时间正序
请发表友善的回复…
发表回复
languagec 2004-07-17
  • 打赏
  • 举报
回复
sanyou98 2004-07-17
  • 打赏
  • 举报
回复
up
SBNOone 2004-07-17
  • 打赏
  • 举报
回复
mark
dot99 2004-07-17
  • 打赏
  • 举报
回复
兄弟伙帮忙翻译一下嘛~~
要不等我明天飞回来再说.....--;;
peter9606 2004-07-14
  • 打赏
  • 举报
回复
up
riitso 2004-07-14
  • 打赏
  • 举报
回复
好长
wasoxi 2004-07-14
  • 打赏
  • 举报
回复
UP
expert2000 2004-07-14
  • 打赏
  • 举报
回复
家庭办公一直是我的梦想,可惜现在还没有这个实力。只好躲到csdn上苦练。天天把这6页帖子灌一遍水,希望能早日家庭办公。^!^
eboywy 2004-07-14
  • 打赏
  • 举报
回复
坐下来慢慢看。
langzi8818 2004-07-14
  • 打赏
  • 举报
回复
顶下先
autoegg 2004-07-14
  • 打赏
  • 举报
回复
搬个凳子先,:)
xjp6688 2004-07-14
  • 打赏
  • 举报
回复
好贴!!!
dot99 2004-07-13
  • 打赏
  • 举报
回复
。。。。。一个人哦。。。。
名字换了换而已。。。
bm1408 2004-07-13
  • 打赏
  • 举报
回复
study and save!
happyasen 2004-07-13
  • 打赏
  • 举报
回复
UP
hcj2002 2004-07-13
  • 打赏
  • 举报
回复
楼主好多马甲呀!
BluntBlade 2004-07-13
  • 打赏
  • 举报
回复
我E文学差了……帮顶。
dot99 2004-07-13
  • 打赏
  • 举报
回复
还好你占个位置,要不然我说不了话了~~~

我现在是 学校不放人,老板不放人, 最后看我~我当然是要留学校啊~
结果老板让我做家庭办公(不敢用英文^_^),还说公司电脑留给我~我怎么办哦~~~~以后跑不出这个老板的手心了。。。。。。明天开始办最难办的事情了~~上不了网了,大家帮忙帮忙翻译完这篇~
leonchew 2004-07-13
  • 打赏
  • 举报
回复
呵呵,dot99 ,还不少了!
占个一楼先,等星星们来!
dot99 2004-07-13
  • 打赏
  • 举报
回复
答案D:程序装入的时候
高高兴兴地把我们的软件编译,连接,压进安装包里面,自豪地刻在CD上卖给我们的第一个用户。现在该高兴地a)收钱;b)开个party;和c)大声的说,内联(inlining)不就是那么点点东西!对不对?

答案是:对,对,绝对不对。

自从1990年中期以后,面向集成运行环境的软件数量逐增长。就是说把程序编译为机器码以适应某种芯片或者用API函数为某种系统写作程序,替换为把程序编译为字节码(bytecode stream),然后通过用户机器上的运行环境,通常不依赖某种CPU或者操作系统,再翻译或者编译为可执行代码。常见的,但不只有这些,如JAVA虚拟机(JVM)还有.NET通用语言运行库(CLR)(包括它的兄弟姐妹,如Mono和Rotor,都是基于ISO Common Language Infrastructure(CLI)标准(一个CLR的子集)来实现。当面向这些运行环境编程时,编译器把原始C++代码翻译成字节码,将一个程序重写为运行环境所接受的指令码(opcode)。

另外:一些这样的运行环境带有一个丰富的指令集,这些指令集包含着高度的面向对象理论,包括类、继承和虚函数,作为直接的坚强后盾。一个面向此平台的编译器能(而且经常这样)把源程序,按照严格的类到类,函数到函数(class-for-class, function-for-function)基本规则,翻译成目标指令语言,这可能是在在编译期优化之后做的,比如一些函数调用得内联化。如果编译器这样做了,那么源程序中C++函数就会或多或少直接被运行环境中拥有相同函数签名(signature)的指令集再现出来。
当然,一个编译器不会将所有的事情搞得完全一样, 也没有必要完全一样.内联行为在加载程序的时候是怎么表现的呢?在托管环境下,最终CPU也不得不将这些指令反馈为本地机器码集。因此,托管环境只是负责把语言指令翻译为CPU能执行的机器指令。这一步通常在程序第一次装载的时候进行,并且在这个时候,正像其他许多compilation-like(不会翻译)进程,更进一步的优化也能(并且经常)被进行。特别地,.NET CLR在程序装载时进行了一些内联的行为。

这写托管环境下的行为并不是由语言特性所决定的,所以,这些在程序装入时进行的优化(包括内联)能被跨语言的执行。不要惊讶你的C#程序内联了一个C++的函数。

现在内联是不是太晚了一点?不要说不可能啊,因为inline的故事还没结束…

答案E: 运行时
够了够了,现在我们到了程序运行时候,我们应该告别代码级别的优化了,对吗?
看上去好像不能在程序运行时进行内联优化,但是实际上有很多方法能够做到。
It might seem impossible that inlining can still be performed at runtime, but in fact there are several ways it can be done. In particular, I want to mention profile-directed optimization and guarded inlining. Like a managed environment (see previous and next sections), this requires some tool support to exist on the user's machine at runtime.

The idea behind profile-directed optimization is that when the application is actually run, instrumentation hooks inserted into the executing program can gather data about how the program is actually being used, in particular what functions are being called heavily and under what conditions (e.g., the size of the working set compared to the total cache memory when the function is called). The data gathered from these instrumented hooks can be used to modify the executable image so that selected function calls can be inlined to tune the application to its target environment based on actual runtime performance measurements.

Guarded inlining is another example of how aggressive the runtime inline optimizations can be. In particular, [4] and [5] document the Jikes Research Virtual Machine (RVM), née the Jalapeño dynamic optimizing compiler, for JVM targets. Among other things, this compiler is able to inline virtual member functions by assuming that the receiver of the virtual call will be of a given declared type (in order to avoid the cost not only of the function call but of the extra expense of virtual dispatch). Now, compilers can already routinely nonvirtualize (and therefore also optionally inline) certain virtual function calls today, if the type of the target is statically known. What's new here is that the Jikes/Jalapeño environment can nonvirtualize and inline calls to virtual functions even if the static type of the target is not known. Because the guess might not be right, it inserts a guard that performs a runtime check that validates that the target object's type is what was expected; if it's not, it falls back to a normal virtual function call.

答案F: 其他某个时候
Finally, I'll add one "other time" example I can think of, which is similar to some of the others but distinct enough that I'll give it its own section.

Recall that in Answer D we considered inlining that happens when installing applications on certain managed runtime environments, such as a JVM or .NET CLR environment. Of course, Astute Readers will already have noticed that earlier I only mentioned translation from bytecode to native machine instructions at application installation time, but there's another and more common time when that translation takes place, namely at JIT time, where JIT refers to "just-in-time" compilation.

The idea behind JITting is to compile functions "just in time," just before they're about to be used. This has the advantage of amortizing the cost of compiling the program down to native code, because of instead of one big compilation step you get lots of little compilations for individual parts of the code, just as they're about to be used. It has the corresponding disadvantages of potentially making the first runs of a program somewhat slower, and of reducing the quality of optimization because the JIT has to be fast and can't afford to spend a lot of time analyzing inlining and other optimization opportunities. A JITter can still perform optimizations like inlining, but we can generally get better results by doing the same work earlier, say at application installation time (see Answer D above) when we're not so time-sensitive and the compiler can spend the cycles to do more analysis.

Summary
Like all optimizations, inlining is frequently better when performed by tools that are aware of the generated code and/or the execution environment rather than by the programmer. The later it is performed, the more specific and targeted it can be.

We talk about inlining functions, but it's more correct to say that we perform inlining on function calls. After all, the same function may be inlined in one place but not in others. And, because of the many opportunities that exist for inlining even well after initial compilation has finished, the same function can be inlined, not only in different places, but by different tools in each place.

There's more to inlining than the inline keyword alone.

References
[1] H. Sutter. More Exceptional C++ (Addison-Wesley, 2002).
[2] Arguably, another interpretation of "at coding time" is that some developers literally inline at coding time by physically moving blocks of source code around. That's not the usual meaning of "inlining" and so I'll ignore it.
[3] http://www.google.com/search?q=site:www%2Egotw%2Eca+premature (various references to premature optimization in articles that I've written).
[4] M. Arnold et al. "Adaptive Optimization in the Jalapeño JVM" (Proceedings of the conference on Object-oriented programming, systems, languages, and applications, ACM Press, 2000).
[5] Jikes RVM home page.
加载更多回复(1)
DirectX修复工具(DirectX Repair)是一款系统级工具软件,简便易用。本程序为绿色版,无需安装,可直接运行。 本程序的主要功能是检测当前系统的DirectX状态,如果发现异常则进行修复。程序主要针对0xc000007b问题设计,可以完美修复该问题。本程序中包含了最新版的DirectX redist(Jun2010),并且全部DX文件都有Microsoft的数字签名,安全放心。 本程序为了应对一般电脑用户的使用,采用了傻瓜式一键设计,只要点击主界面上的“检测并修复”按钮,程序就会自动完成校验、检测、下载、修复以及注册的全部功能,无需用户的介入,大大降低了使用难度。 本程序适用于多个操作系统,如Windows XP(需先安装.NET 2.0,详情请参阅“致Windows XP用户.txt”文件)、Windows Vista、Windows 7、Windows 8、Windows 8.1、Windows 8.1 Update、Windows 10,同时兼容32位操作系统和64位操作系统。本程序会根据系统的不同,自动调整任务模式,无需用户进行设置。 本程序的V3.3版分为标准版、增强版以及在线修复版。其中的标准版以及增强版都包含完整的DirectX组件。除此之外,增强版中还额外包含了c++ Redistributable Package,因此增强版不但能解决DirectX组件的问题,而且还能解决c++组件异常产生的问题。增强版适合无法自行解决c++相关问题的用户使用。在线修复版的功能与标准版相同,只是其所需的文件将通过Internet下载,因此大大减小了程序的体积。本程序的各个版本之间,主程序完全相同,只是配套使用的数据包不同。因此,当您使用标准版数据包时,程序将进行标准修复;当您使用增强版的数据包时,程序将进行增强修复;当数据包不全或没有数据包(即只有DirectX Repair.exe程序)时,程序将进行在线修复。在线修复、离线修复可自由灵活组合,充分满足不同用户的需要。 本程序自V2.0版起采用全新的底层程序架构,使用了异步多线程编程技术,使得检测、下载、修复单独进行,互不干扰,快速如飞。新程序更改了自我校验方式,因此使用新版本的程序时不会再出现自我校验失败的错误;但并取消自我校验,因此程序安全性与之前版本相同,并未降低。 程序有自动更新c++功能。由于绝大多数软件运行时需要c++的支持,并且c++的异常也会导致0xc000007b错误,因此程序在检测修复的同时,也会根据需要更新系统中的c++组件。自V3.2版本开始使用了全新的c++扩展包,可以大幅提高工业软件修复成功的概率。修复c++的功能仅限于增强版,标准版及在线修复版在系统c++异常时(丢失时)会提示用户使用增强版进行修复。 程序有两种窗口样式。正常模式即默认样式,适合绝大多数用户使用。另有一种简约模式,此时窗口将只显示最基本的内容,修复会自动进行,修复完成10秒钟后会自动退出。该窗口样式可以使修复工作变得更加简单快速,同时方便其他软件、游戏将本程序内嵌,即可进行无需人工参与的快速修复。开启简约模式的方法是:打开程序所在目录下的“Settings.ini”文件(如果没有可以自己创建),将其中的“FormStyle”一项的值改为“Simple”并保存即可。 程序有高级筛选功能,开启该功能后用户可以自主选择要修复的文件,避免了其他不必要的修复工作。同时,也支持通过文件进行辅助筛选,只要在程序目录下建立“Filter.dat”文件,其中的每一行写一个需要修复文件的序号即可。该功能仅针对高级用户使用,并且必须在正常窗口模式下才有效(简约模式时无效)。 本程序有自动记录日志功能,可以记录每一次检测修复结果,方便在出现问题时,及时分析和查找原因,以便找到解决办法。 程序的“选项”对话框中包含了4项高级功能。点击其中的“注册系统文件夹中所有dll文件”按钮可以自动注册系统文件夹下的所有dll文件。该项功能不仅能修复DirectX的问题,还可以修复系统中很多其他由于dll未注册而产生的问题,颇为实用。点击该按钮旁边的小箭头,还可以注册任意指定文件夹下的dll文件,方便用户对绿色版、硬盘版的程序组件进行注册。点击第二个按钮可以为dll文件的右键菜单添加“注册”和“卸载”项,方便对单独的dll文件进行注册。请注意,并不是所有的dll文件都可以通过这种方式注册。点击“DirectX版本”选项卡可以自行修改系统中DirectX的版本信息。点击“DirectX加速”选项卡可以控制系统中DirectX加速的开启与关闭。 新版程序集成了用户反馈程序,可以在用户允许的前提下发送检测修复结果。用户也可以在出现问题时通过反馈程序和软件作者进行交流,共同查找问题。反馈是完全自愿和匿名(如果不填写E-mail地址)的。 本程序的通用版基于Microsoft .NET Framework 2.0开发,对于Windows 2000、Windows XP、Windows 2003的用户需要首先安装.NET Framework 2.0或更高版本方可运行本程序。有关下载和安装的详细信息请参阅“致Windows XP用户.txt”文件。对于Windows Vista、Windows 7及后续用户,可以直接运行本程序。 同时鉴于Windows 8(Windows 8.1、Windows 8.1 Update)、Windows 10系统中默认未包含.NET Framework 2.0,因此新版的程序文件夹内将包含一个DirectX_Repair_win8的特别版程序,该程序功能与通用版相同,基于.NET Framework 4.0开发,可以在Windows8(Windows 8.1、Windows 8.1 Update)、Windows 10系统中直接运行(其他系统如果安装了.NET Framework 4.0也可以运行这个特别版的程序)。 本程序的官方博客地址为:http://blog.csdn.net/vbcom/article/details/6962388 所有的更新以及技术支持都可以到该博客上找到。

65,187

社区成员

发帖
与我相关
我的任务
社区描述
C++ 语言相关问题讨论,技术干货分享,前沿动态等
c++ 技术论坛(原bbs)
社区管理员
  • C++ 语言社区
  • encoderlee
  • paschen
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
  1. 请不要发布与C++技术无关的贴子
  2. 请不要发布与技术无关的招聘、广告的帖子
  3. 请尽可能的描述清楚你的问题,如果涉及到代码请尽可能的格式化一下

试试用AI创作助手写篇文章吧