CPU需要花费太多时间在Linux中执行嵌套for循环与Windows平台相比

Question

我要在我的Linux平台上运行一个嵌套for循环，耗时约55毫秒，并且可以在窗口上运行相同的程序，耗时约25毫秒。

Linux和Windows平台的CPU配置与CPU时钟和RAM相比几乎相同。

我也附上了这个问题的代码。

SO，没有任何人有什么是怎么回事或者如何优化这个嵌套的循环，我很喜欢去这个Linux的PC上运行的想法？

for (i = 0; i < 1944; i += 2) 
     for (j = 0; j < 2592; j += 2) 
      { 
      Here some arithmetic operation is going on 
      } 

Answer 1

在这种情况下，Linux与Windows几乎毫无关系。你是

• 在两个平台上使用相同的编译器吗？
• 在两个平台上使用相同版本的编译器？
• 在两个平台上使用相同的优化设置？

所有这些都将导致的结果是不同的。此外，如果CPU是相同的，甚至没有规定。通过对我的音频采样率转换库进行基准测试，我计算出了1.7 GHz Core i5和1.6 GHz Atom之间吞吐量的6-7倍差异。

• 您是否在使用相同硬件这两个基准？

有许多的混淆其基准等因素的影响，

• 你在后台运行的其他进程？
• 您是否使用相同的技术来衡量这两种情况下的性能？
• 您是否收集了足够的样本（并且您是否通过数学来证明它）？

Answer 2

您是否在循环中执行任何函数调用（例如，在“math.h”中定义的函数）？

如果是，该问题可能是一个低效率的实现相比于Windows库的GNU库（在Linux中使用）这些功能。

您是否正在生成32位或64位可执行文件？比较一个系统上的64位可执行文件和另一个系统上的32位可执行文件是没有意义的！

如果您安装32位运行时库或静态编译，您（通常）可以在64位Linux下运行32位可执行文件。您始终可以在64位Windows下运行32位可执行文件。

如果你不使用函数调用和32/64位也不是你可以检查，如果这是通过执行下列编译器性能问题一个问题：

• 首先隔离圈成一个C文件。这意味着：将循环移动到函数“test_loop（）”并将此函数移动到单独的C文件中。
• 特别是当生成64位可执行文件时，函数不应该有任何参数，但所有数据输入和输出都应该通过全局变量完成。
• 获取GCC for Windows并使用“-s”选项编译文件（gcc -o loop.s -S loop.c）。结果将是一个汇编文件。
• 确保在Windows上编译64位，如果您将检查64位Linux并在Windows上编译32位，如果您将检查32位Linux
• 使用GCC for Windows编译整个程序（gcc -o test.exe test.c loop.s）并进行运行时测量。
• 注意：在Windows 32位下，C编译器向所有函数名称添加下划线。因此，在Linux下使用汇编文件时，该函数将被命名为“_test_loop（）”。全局变量名称（由汇编程序文件使用）也是如此。您必须修改其余的C文件以在Linux下进行编译。 编译64位时，情况并非如此。
• 编译Linux下的程序。不要再次编译包含循环的C文件，而是使用在Windows下生成的汇编程序文件。比较Linux上的运行时和Windows上的运行时间
• 使用同一台计算机进行运行时间测量;不是两台具有“类似硬件”的计算机

如果两个操作系统的运行时间现在都相同，那么您会发现它是一个编译器问题。如果需要Linux下的性能，可以使用Microsoft编译器在Windows下编译该文件并在Linux下使用该目标文件。不幸的是Windows使用另一种目标文件格式而不是Linux，所以目标文件必须被转换（从COFF到ELF）。

如果在Windows下运行时间仍然较快，那么问题可能是是时间测量的准确性问题。时间测量小于100ms通常非常不准确。为了检查这个，你应该创建一个从0到999的外部循环，以便现在嵌套三个循环。时间现在应该是55秒，而25秒。