3 ms·

Node isn't interpreted, it runs on V8 which is a fairly advanced JIT compiling VM. The main reason Node is so slow is that, as you point out, it doesn't do thr

Node isn't interpreted, it runs on V8 which is a fairly advanced JIT compiling VM. The main reason Node is so slow is that, as you point out, it doesn't do threading at all, and JavaScript is just inherently difficult to optimise into machine code, even though V8 makes a good effort.

marcosdumay 10y ago
What do you think a VM is? It does not target your hardware architecture. Just because your code is in binary instead of text, it does not become less of an interpreter.
- Jtsummers 10y ago
  https://developers.google.com/v8/design https://developers.google.com/v8/design C-f for "Dynamic Machine Code Generation" V8 compiles it to native machine code for execution. It's not an interpreter or a VM with its own bytecode.
  - marcosdumay 10y ago
    Cool. There is no VM, just a runtime not much different from the ones from other compiled languages. It compiles your code piece by piece, and optimizes during that compilation. This is a very interesting solution for JavaScript, but I think it's constrained by the language and could become better if it were fully compiled.
    - Jtsummers 10y ago
      Perhaps for the use-case of node, being fully compiled could be a bit better. But I'm not convinced. Java has demonstrated (over two decades now) that initial compilation to machine code isn't essential for performant software (ok, less than two decades for hotspot JITs in Java). The cost for node is in startup time, but this is, like with Java, amortized over the life of the program. For a single-run executable, it's perhaps too costly (but we use truly interpreted languages for this as well, so depends on the task), but for a server, it's potentially pretty good.
      - marcosdumay 10y ago
        Yes, that was for the specific case of Node. For web use, full compilation is a clear loss. Java can make great use of JIT exactly because it's interpreted. When you make partial compilations, you lose a lot of JIT opportunities, and a lot of static optimization opportunities too. Yet, it looks like V8 attenuated this somehow, and got good performance anyway. Must have been a feat.
Yaggo 10y ago
The benchmark code uses multiple processes to utilize all CPU cores (standard way in Node.js land). I would blame the highly dynamic nature of the language for (relative) slowness – the price you pay for flexibility / quickly-writable code. That being said, it's still fast for dynamically typed language.

marcosdumay 10y ago

What do you think a VM is? It does not target your hardware architecture. Just because your code is in binary instead of text, it does not become less of an interpreter.

Jtsummers 10y ago
https://developers.google.com/v8/design https://developers.google.com/v8/design C-f for "Dynamic Machine Code Generation" V8 compiles it to native machine code for execution. It's not an interpreter or a VM with its own bytecode.
- marcosdumay 10y ago
  Cool. There is no VM, just a runtime not much different from the ones from other compiled languages. It compiles your code piece by piece, and optimizes during that compilation. This is a very interesting solution for JavaScript, but I think it's constrained by the language and could become better if it were fully compiled.
  - Jtsummers 10y ago
    Perhaps for the use-case of node, being fully compiled could be a bit better. But I'm not convinced. Java has demonstrated (over two decades now) that initial compilation to machine code isn't essential for performant software (ok, less than two decades for hotspot JITs in Java). The cost for node is in startup time, but this is, like with Java, amortized over the life of the program. For a single-run executable, it's perhaps too costly (but we use truly interpreted languages for this as well, so depends on the task), but for a server, it's potentially pretty good.
    - marcosdumay 10y ago
      Yes, that was for the specific case of Node. For web use, full compilation is a clear loss. Java can make great use of JIT exactly because it's interpreted. When you make partial compilations, you lose a lot of JIT opportunities, and a lot of static optimization opportunities too. Yet, it looks like V8 attenuated this somehow, and got good performance anyway. Must have been a feat.

Yaggo 10y ago

The benchmark code uses multiple processes to utilize all CPU cores (standard way in Node.js land). I would blame the highly dynamic nature of the language for (relative) slowness – the price you pay for flexibility / quickly-writable code. That being said, it's still fast for dynamically typed language.