c - 为什么这个 NodeJS 比原生 C 快 2 倍？

Question

为了工作演示，我想比较 NodeJS 和 C 的性能。这是我写的:

Node.js(for.js):

var d = 0.0,
    start = new Date().getTime();

for (var i = 0; i < 100000000; i++)
{
  d += i >> 1;
}

var end = new Date().getTime();

console.log(d);
console.log(end - start);

C (for.c)

#include <stdio.h>
#include <time.h>

int main () {
  clock_t start = clock();

  long d = 0.0;

  for (long i = 0; i < 100000000; i++)
  {
    d += i >> 1;    
  }

  clock_t end = clock();
  clock_t elapsed = (end - start) / (CLOCKS_PER_SEC / 1000); 

  printf("%ld\n", d);
  printf("%lu\n", elapsed);
}

我使用 GCC 编译了我的 for.c 并运行它:

gcc for.c
./a.out

结果:

2499999950000000
198

然后我在 NodeJS 中试了一下:

node for.js

结果:

2499999950000000
116

运行了无数次之后，我发现无论如何都是如此。如果我将 for.c 切换为在循环中使用 double 而不是 long，C 花费的时间甚至更长!

不是想挑起一场口水战，但为什么 Node.JS(116 毫秒)在执行同样的操作时比原生 C(198 毫秒)快得多？ Node.JS 是否应用了 GCC 没有开箱即用的优化？

编辑:

根据评论中的建议，我运行了 gcc -Wall -O2 for.c。结果改进到 C 需要 29 毫秒。这就引出了一个问题，为什么原生 C 设置没有像 Javascript 编译器那样优化？另外，-Wall 和 -02 在做什么。我真的很好奇这里发生的事情的细节。

Answer 1

这引出了一个问题，为什么原生 C 设置没有像 Javascript 编译器那样优化？

由于 C 是静态编译和链接的，因此需要对整个代码库进行一个可能很长的构建步骤(我曾经在一个完全优化的构建中花费了将近一个小时，但其他情况下只需要 10 分钟)，而且非常危险, 硬件级语言，如果你不小心对待它，会冒很多未定义行为的风险，编译器的默认设置通常不会优化到碎片，因为这是一个开发人员/调试版本，旨在帮助更快地进行调试和提高生产力周转。

因此，在 C 中，您可以明显区分未优化但构建速度更快、更易于调试的开发人员/调试构建和非常优化、构建速度较慢、更难的构建to-debug production/release 运行速度非常快的构建，编译器的默认设置通常有利于前者。

使用诸如 v8/NodeJS 之类的东西，您正在处理一个即时编译器(动态编译)，该编译器在运行时仅动态构建和优化必要的代码。最重要的是，JS 是一种更安全的语言，通常也是为安全而设计的，它不允许您处理硬件的原始位和字节。

因此，它不需要像 C/C++ 这样的本地静态编译语言的那种强大的发布/调试构建区别。但它也不允许您像在 C 中那样将踏板踩到金属上，如果您真的想要的话。

许多试图对来自其他语言的 C/C++ 进行基准测试的人往往无法理解这种构建区别以及编译器/链接器优化设置的重要性，并感到困惑。如您所见，通过适当的设置，很难击败这些允许您编写真正低级代码的本地编译器和语言的性能。