是否有关于使用 C++ 进行 C 编译的结论性研究/实验? 编译器?
我见过很多关于用 C++ 编译器编译的 C 代码的一般性能的争论 - 我很好奇是否有任何可靠的实验研究埋藏在你所有的轶事争论之下在网络搜索中查找。 我对 GCC 套件特别感兴趣,但任何数据点都会很有趣。 (比较“Hello, World!”的程序集并不像我希望的那样强大。:-)
我通常假设您使用“嵌入样式”标志——没有例外或 RTTI。 我也不介意知道是否有关于编译时间本身的研究。 蒂亚!
I've seen a lot of arguments over the general performance of C code compiled with a C++ compiler -- I'm curious as to whether there are any solid experimental studies buried beneath all the anecdotal flame wars you find in web searches. I'm particularly interested in the GCC suite, but any data points would be interesting. (Comparing the assembly of "Hello, World!" is not as robust as I'd like. :-)
I'm generally assuming you use the "embedded style" flags -- no exceptions or RTTI. I also wouldn't mind knowing if there are studies on the compilation time itself. TIA!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(7)
添加一个数据点(或者至少是一个轶事):
我们最近正在为一个小型嵌入式目标编写一个数学库,并开始用 C 语言编写它。大约在项目进行到一半时,我们将一些文件切换到 C++,主要是在为了对某些函数使用模板,否则我们将编写许多几乎相同的代码段(或者在预处理器宏中嵌入 40 行函数)。
在我们开始切换时,我们非常仔细地查看了许多函数上生成的汇编代码(使用 GCC),并确认无论文件是编译为 C 还是 C++,它实际上本质上是相同的 - - “本质上相同”是指差异在于符号名称以及汇编文件开头和结尾的内容; 函数中间的实际指令完全相同。
抱歉,我没有更可靠的答案。
编辑添加,2013-03-24:最近我看到一篇文章,Rusty Russell 比较了用 C 编译器编译的 GCC 和用 C++ 编译器编译的性能,以响应最近转向编译的情况GCC 作为 C++:http://rusty.ozlabs.org/?p=330。 结论很有趣:用 C++ 编译器编译的版本稍微慢一些; 差异约为0.3%。 然而,这完全是由较大的调试信息引起的加载时间差异来解释的; 当他剥离二进制文件并删除调试信息时,差异小于 0.1%——即,与测量噪声基本上无法区分。
Adding a datapoint (or at least an anecdote):
We were recently writing a math library for a small embedded-like target, and started writing it in C. About halfway through the project, we switched some of the files to C++, largely in order to use templates for some of the functions where we'd otherwise be writing many nearly-identical pieces of code (or else embedding 40-line functions in preprocessor macros).
At the point where we started switching over, we had a very careful look at the generated assembly code (using GCC) on a number of the functions, and confirmed that it was in fact essentially identical whether the file was compiled as C or C++ -- where by "essentially identical" I mean the differences were in things like symbol names and the stuff at the beginning and end of the assembly file; the actual instructions in the middle of the functions were exactly identical.
Sorry that I don't have a more solid answer.
Edit to add, 2013-03-24: Recently I came across an article where Rusty Russell compared performance on GCC compiled with a C compiler and compiled with a C++ compiler, in response to the recent switch to compiling GCC as C++: http://rusty.ozlabs.org/?p=330. The conclusions are interesting: The version compiled with a C++ compiler was very slightly slower; the difference was about 0.3%. However, that was entirely explained by load time differences caused by larger debug info; when he stripped the binaries and removed the debug info, the differences were less than 0.1% -- i.e., essentially indistinguishable from measurement noise.
我不知道有任何研究,但考虑到 C++ 的哲学,即你不必为不使用的功能付出代价,我怀疑使用 C 编译器编译 C 代码之间是否有任何显着差异以及 C++ 编译器。
I don't know of any studies off-hand, but given the C++ philosophy that you don't pay the price for features you don't use, I doubt there'd be any significant difference between compiling C code with the C compiler and with the C++ compiler.
我不知道有什么研究,我怀疑有人会花时间做这些研究。 基本上,使用 C++ 编译器编译时,代码与使用 C 编译器编译时的语义相同,因此取决于优化和代码生成。 但在我看来,这些太多是特定于编译器的,以便允许任何关于 C 与 C++ 的一般性陈述。
当您使用 C++ 编译器编译 C 代码时,您主要获得的是更严格的检查(函数声明等)。 在我看来,这将使使用 C++ 编译器编译 C 代码变得非常有吸引力。 但请注意,如果您有一个从未通过 C++ 编译器运行的大型 C 代码库,那么您可能会面临一场非常艰难的战斗,直到代码编译得足够干净以能够看到任何有意义的警告。
I don't know of any studies and I doubt that anyone will spend the time to do them. Basically, when compiling with a C++ compiler, the code has the same semantic as when compiling with a C compiler, so it's down to optimization and code generation. But IMO these are much too much compiler-specifc in order to allow any general statements about C vs. C++.
What you mainly gain when you compile C code with a C++ compiler is a much stricter checking (function declarations etc.). IMO this would make compiling C code with a C++ compiler quite attractive. But note that, if you have a large C code base that's never run through a C++ compiler, you're likely facing a very steep up-hill battle until the code compiles clean enough to be able to see any meaningful warnings.
GCC项目目前正在从C到C++的过渡——也就是说,GCC将来可能会用C++实现,目前是用C编写的。GCC的下一个版本将用C的子集编写,这也是有效的C++。
一些性能测试是在
g++ 与
gcc
,在 GCC 的代码库上。 他们比较了“引导”时间,这意味着使用 sysmem 编译器编译 gcc,然后使用生成的编译器进行编译,然后重复并检查结果是否相同。摘要:使用 g++ 速度慢 20%。 编译器版本略有不同,但人们认为这不会导致 20% 的差异。
请注意,这测量了不同的程序,gcc 与 g++,尽管它们大多使用相同的代码,但具有不同的前端。
The GCC project is currently under a transition from C to C++ - that is, GCC may be implemented in C++ in the future, it is currently written in C. The next release of GCC will be written in the subset of C which is also valid C++.
Some performance tests were performed on
g++
vsgcc
, on GCC's codebase. They compared the "bootstrap" time, which means compiling gcc with the sysmem compiler, then compiling it with the resulting compiler, then repeating and checking the results are the same.Summary: Using g++ was 20% slower. The compiler versions were slightly different, but it was thought that this wouldn't cause there 20% difference.
Note that this measures different programs, gcc vs g++, which although they mostly use the same code, have different front-ends.
我没有从性能的角度尝试过它,但我认为使用 C++ 编译器编译 C 应用程序是一个好主意,因为它会阻止您做“顽皮”的事情,例如使用未声明的函数。
但是,输出不会相同 - 至少,您会得到不同的符号,这将使其(大部分)无法与 C 编译器的代码链接。
所以我认为你真正的意思是“从性能的角度来看,编写非常类似于 C 的 C++ 代码并使用 C++ 编译器进行编译是否可以”?
您还必须不使用一些 C99 的东西,例如 bool_t,C++ 不支持它,因为它有自己的东西。
I've not tried it from a performance standpoint, but I think compiling C applications with the C++ compiler is a good idea, as it will prevent you from doing "naughty" things such as using functions not declared.
However, the output won't be the same - at the very least, you'll get different symbols, which will render it (mostly) unlinkable with code from the C compiler.
So I think what you really mean is "Is it ok from a performance standpoint, to write C++ code which is very C-like and compile it with the C++ compiler" ?
You would also have to not be using some C99 things such as bool_t which C++ doesn't support on the grounds of having its own ones.
如果代码不是专门设计的,请不要这样做。 如果解释为 C 或 C++,相同的有效语言结构可能会导致不同的行为。 您可能会引入非常难以理解的错误。 问题较少,但仍是可维护性的噩梦; 某些 C 构造(尤其是 C99 中的构造)在 C++ 中无效。
Don't do it if the code has not been designed for. The same valid language constructs can lead to different behavior if interpreted as C or as C++. You would potentially introduce very difficult to understand bugs. Less problematic but still a maintainability nightmare; some C constructs (especially from C99) are not valid in C++.
过去我做过一些事情,比如查看二进制文件的大小,这对于 C++ 来说是巨大的,但这并不意味着它们只是链接在一堆未使用的库中。 最简单的可能是使用 gcc -S myprog.cpp 与 gcc -S myprog.c 并比较汇编器输出。
In the past I have done things like look at the size of the binary which for C++ was huge, that doesnt mean they simply linked in a bunch of unusued libraries. The easiest might be to use gcc -S myprog.cpp vs gcc -S myprog.c and diff the assembler output.