用C而不是C++编写部分代码作为微优化值得吗？

Question

我想知道，对于现代编译器和他们的优化来说，用C而不是C++编写一些关键代码以使其更快是否仍然值得。

我知道，如果类可以通过引用传递时被复制，或者当类由编译器自动创建时(通常使用重载操作符和许多其他类似的情况)，C++可能会导致糟糕的性能；但是对于知道如何避免所有这些的优秀C++开发人员来说，仍然值得用C编写代码来提高性能吗？

Answer 1

我会同意很多评论。在C++中，故意支持C语法(仅在C99中有差异)。因此，所有的C++编译器都必须支持它。事实上，我认为很难再找到专门的C编译器了。例如，在GCC中，不管代码是C还是C++，你实际上都会使用相同的优化/编译引擎。

那么，真正的问题是，编写纯C代码和在C++中编译是否会遭受性能损失。答案是，无论出于何种目的，答案都是否定的。关于异常和RTTI有一些棘手的问题，但这些主要是大小的变化，而不是速度的变化。你很难找到一个实际会影响性能的例子，以至于似乎不值得写一个专门的模块。

关于你所使用的功能的说法很重要。在C++中，很容易在复制语义上草率行事，并因复制内存而蒙受巨大的开销。根据我的经验，这是最大的开销--在C语言中，你也可以承受这样的开销，但我想说并不是那么容易。

虚函数调用比普通函数要稍微昂贵一些。同时，强制内联函数比普通函数调用更便宜。在这两种情况下，从堆栈推送/弹出参数的成本可能更高。但是，担心函数调用开销在优化过程中应该出现得很晚--因为它很少是一个重要的问题。

异常在抛出时代价很高(至少在GCC中是如此)。但是，设置catch语句和使用RAII并不会带来很大的成本。这是在GCC编译器(和其他编译器)中设计的，所以实际上只有在特殊情况下才是代价高昂的。

但总而言之:一个好的C++程序员不能仅仅通过用C语言编写代码就能让代码运行得更快。

Answer 2

度量！考虑优化之前的度量，应用优化之前的度量，应用优化后的度量，度量！

如果你必须将你的代码运行快1纳秒(因为它将被1000人使用，在接下来的1000天内使用1000次，，秒是非常重要的)，任何事情都可以。

是的！这是值得..。

• 更改语言(从C++到C；从Python到COBOL；从Mathlab到Fortran；从PHP到Lisp)
• 调整编译器(启用/禁用所有-f选项)
• 使用不同的库(甚至编写您的your

你不能忘记的是测量！。

Answer 3

pmg做到了这一点。只需测量而不是全局假设。也可以这样想，像gcc这样的编译器将前端、中间和后端分开。因此，前端fortran、c、c++、ada等最终使用相同的内部中间语言，如果你愿意的话，这是获得最大优化的语言。然后，将通用中间语言转换为特定目标的汇编语言，并进行特定于目标的优化。因此，当两种语言差异很大时，这种语言可能会也可能不会从前面到中间引入更多代码，但对于C/C++，我假设它是相同的或非常相似的。现在二进制文件的大小就是另一回事了，即使只有C语法，也可能会有不同的库，这些库可能会被吸进C语言的二进制文件，而不是C++。不一定影响执行性能，但如果程序作为一段时间加载到ram中，则会增大程序文件的成本、存储和传输差异以及内存要求。这里再来一次，测量一下。

我还在度量注释中添加了编译到汇编程序和/或反汇编输出，并比较了不同语言/编译器选择的结果。这可以/将补充您在测量时看到的时间差。