为什么这个NodeJS 2x比本机C快？

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在循环中使用a而不是a ，则C花费的时间甚至更长！

不是试图发动火焰战争，但是为什么执行相同操作的Node.JS（116毫秒）比本机C（198毫秒）那么快？Node.JS是否正在应用GCC不能立即使用的优化？

编辑：

根据评论中的建议，我跑了gcc -Wall -O2 for.c。结果提高到C耗时29 ms。这就引出了一个问题，即本机C设置没有像Javascript编译器那样优化程度如何？另外，-Wall和-02在做什么。我真的很好奇这里发生的事情的细节。

Answer 1

这就引出了一个问题，即本机C设置没有像Javascript编译器那样优化程度如何？

由于C是静态编译和链接的，因此可能需要较长的整个代码库构建步骤（我曾经在一个完整的优化构建中花了将近一个小时的时间来工作，否则只花了10分钟的时间），以及一个非常危险的硬件-级别的语言，如果您不慎重对待，则会冒很多未定义行为的风险，编译器的默认设置通常不会针对smithereens进行优化，因为这是开发人员/调试版本，旨在通过更快的周转时间帮助调试和提高生产率。

因此，在C语言中，您可以将未优化但构建速度更快，更易于调试的开发人员/调试构建与真正运行的非常优化，构建速度较慢，较难调试的生产/发布构建区分开来快速，并且编译器的默认设置通常倾向于前者。

使用v8 / NodeJS之类的东西，您需要处理的是实时编译器（动态编译），该编译器仅在运行时动态地构建和优化必要的代码。最重要的是，JS是一种更加安全的语言，并且通常还为安全性而设计，不允许您在硬件的原始位和字节上工作。

结果，它不需要像C / C ++这样的本机静态编译语言的那种强大的发行/调试版本区别。但是，如果您真的想要的话，它也不允许您在C语言中踩踏板。

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