使用不同编译器生成的二进制文件速度差异太大(C ++)

时间:2011-06-06 15:13:52

标签: c++ visual-c++ gcc intel

我在上一个项目中主要使用gcc,今天我决定对不同编译器的结果进行基准测试。

我使用了与Visual Studio 2010和英特尔C ++相同的gcc 4.5,MSVC源代码。该程序从文本文件中获取输入,进行大量字符串操作并将输出写入另一个文本文件。

我只计算时间o

编辑:基准测试:
我只计算执行算法的时间,而不是文件io。基本上我放了

    clock_t clock0;
    double z;
    clock0 = clock();

 在开始和
    double clock1=(clock() - clock0) / (double) CLOCKS_PER_SEC;


 功能之后。

它从一个小文件(大约200行)开始,几乎没有差别(大约<0.15秒)。使用4K行文件,MSVC的输出工作时间为1.23秒,而gcc的输出为0.1。

最后我测试了60K行文件:

  (program compiled with ) Intel compiler ran for 6.7 sec and with  gcc : 1 sec.

现在我只是想知道为什么会有这样的差异(没有优化标志)以及可能是什么原因。(我使用c ++ 0x标准 - 但显然英特尔编译器支持它。)我不确定如果我的代码仅使用一个编译器编译为快速二进制的事实并不令人担忧

编辑2:

我没有在MSVC或Intel

的调试模式下编译它

4 个答案:

答案 0 :(得分:10)

我们再来一次......

Visual Studio中的STL实现在调试模式下执行 非常重的 迭代器检查。然后是堆栈和寄存器完整性的正常调试检查。当没有开启优化时,它也会执行此操作。如果没有(或几乎没有)调试检查,GCC只能如此快。另外,取自我的评论:

  

没有优化标志的基准测试有点无意义

或者你欺骗我们并使用gcc在发布模式下编译,并使用Visual Studio / Intel C ++在调试模式下编译...

答案 1 :(得分:9)

如果你没有使用优化标志,那么在更快的编译器中,糟糕的调试工具可以很容易地解释答案。像这样的微基准测试通常无效,如果你不发布代码,那么肯定无效。

通过使用算法优化,自定义内存分配器等等,您可能会提供比更改编译器更大的速度差异。

答案 2 :(得分:7)

请勿在禁用优化的情况下衡量效果。

不进行优化编译的原因通常是为了便于调试,因此编译器将在禁用优化时生成调试友好的代码。对于某些编译器(例如,MSVC),它涉及添加大量运行时检查以帮助您捕获更多错误。

如果您想比较性能,请将其视为性能重要:告诉编译器担心性能并优化代码。

答案 3 :(得分:2)

我不确定你是如何编译g ++的,也不知道g ++是如何编译的 库,但VC ++的clock()被破坏了;它测量挂钟 时间,而不是标准要求的CPU时间。听起来像是g ++ 正在使用clock()的正确版本,英特尔正在使用该版本 在VC ++库中。 (当读取大文件时,大部分时间都会 不是CPU时间。)