gcc可能不太可能使用宏

leo*_*on 12 memory performance gcc likely-unlikely

我正在用大致以下逻辑编写一段关键代码

if(expression is true){
   //do something with extremely low latency before the nuke blows up. This branch is entered rarely, but it is the most important case
}else{
   //do unimportant thing that doesnt really matter
}
Run Code Online (Sandbox Code Playgroud)

我想在表达式周围使用possible()宏,所以当它到达重要分支时,我得到最小延迟.我的问题是,使用方法与宏名称的建议完全相反,因为我选择"不太可能"的分支进行预取.在性能方面这样做有明显的缺点吗?

aba*_*ert 9

是.您通过标记不太可能但必须快速的分支来欺骗编译器,就好像它是可能的分支一样,希望编译器能够使它更快.

这样做有一个明显的缺点 - 如果你没有写出一个好的评论来解释你正在做什么以及为什么,一些维护者(可能是你自己)在六个月内几乎可以肯定地说,"嘿,看起来像他把可能放在错误的分支上"并"修复"它.

你现在或将来使用的某些版本的编译器会有一些不太可能但仍然可能存在的缺点,你会使用可能的宏做一些不同的事情,而那些不同的东西将不是你想要的欺骗编译器进行操作,你最终会得到一些代码,每次循环都花费10万美元,在撤消之前,通过反应堆关闭会花费90%的时间.

  • 宏观名称的更好选择可能是"关键的",特别是如果它实际上涉及核反应.或者也许'must_be_performed_fast'.由于您使用的是宏,因此宏名称可以表明您需要它的原因; 实现隐藏在宏名称后面. (5认同)