为什么我可以从MacPorts中使用XCode的llvm和clang ++获得更快的二进制文件？

问题描述

| 我已经编写了一个基准测试方法来测试我的C ++程序（它将搜索游戏树），并且我注意到在XCode 4.0.2中使用“ LLVM编译器2.0 \”选项进行编译可以比编译时提供更快的二进制速度使用MacPorts的最新版本的clang ++。 如果我正确理解，则在两种情况下都使用clang前端和llvm后端。苹果是否已对其clang / llvm发行版进行了改进，以为Mac OS生成更快的二进制文件？我找不到有关该项目的太多信息。 这是我的程序为各种编译器生成的基准，全部使用-O3优化（越高越好）：

(Xcode) \"gcc 4.2\": 38.7
(Xcode) \"llvm gcc 4.2\": 51.2
(Xcode) \"llvm compiler 2.0\": 50.6
g++-mp-4.6: 43.4
clang++: 40.6

另外，如何使用从终端使用的clang / llvm XCode进行编译？我找不到命令。 编辑：我输出的分数是“每秒数千个游戏”，是在程序运行足够长时间后得出的。在多次运行中得分非常一致，例如，最近的主要算法改进使我的速度提高了1％-5％。 25％的速度从40加快到50对我的程序来说意义重大。 更新：我不是使用-flto从命令行调用clang ++。现在，当我从命令行将clang ++ -O3 -flto与/ Developer / usr / bin / clang ++ -O3 -flto进行比较时，结果更接近，但Apple仍然快6.5％。 现在如何为gcc启用链接时间优化？当我尝试g ++ -flto时，出现以下错误：

cc1plus: error: LTO support has not been enabled in this configuration

    

解决方法

        Apple LLVM编译器应该在/ Developer / usr / bin / clang下可用。 我想不出MacPorts clang ++生成较慢代码的任何特殊原因...我将检查您是否传递了类似的命令行选项。一件事会带来很大的不同，如果您使用一个编译器生成32位代码，而使用另一个编译器生成64位代码。     ,        如果GCC没有LTO，则需要自己构建： http://solarianprogrammer.com/2012/07/21/compiling-gcc-4-7-1-mac-osx-lion/ 对于LTO，您需要在说明中添加\'libelf \'。 http://sourceforge.net/apps/trac/mingw-w64/wiki/LTO%20and%20GCC     ,        算法的确切速度可能取决于各种事情，而这完全超出了您和编译器的能力。您可能会遇到一个循环，其中执行时间精确地取决于指令在内存中的对齐方式，这是编译器无法预测的。我已经看到了这样的情况：一个循环可以在每次迭代中以不同的执行时间进入不同的“状态”（因此，在上下文切换之后，它可以进入一种状态，该状态需要花费12或13个周期，而不是随机的）。这全都是巧合。 而且您可能使用了不同的库，这很可能是原因。例如，在MacOS X中，他们使用的是std :: string和std :: vector的新的且可能更快的实现。