3 ms·
The basic idea makes a lot of sense though when there's tons of server-side code running in interpreted PHP, Python or JIT'ted Javascript which would run 10x ..
by flohofwoe 3y ago
The basic idea makes a lot of sense though when there's tons of server-side code running in interpreted PHP, Python or JIT'ted Javascript which would run 10x .. 100x faster and more energy efficient when picking any compiled language instead.
Interpreting and JIT'ing wastes a lot of resources with identical but unnecessary work on each invocation that would only need to happen once before deployment. We're not recompiling C++, Swift or Rust applications each time they are started on the user's mobile phone either.
- nindalf 3y agoIt's certainly possible to make the case you're saying. And I would be interested in reading such a paper. But my view is that someone using the benchmarks game hasn't proved anything.
- flohofwoe 3y ago> How often do you restart the server so that the JIT compiling time matters? In a highly dynamic language like Javascript you have not much control on when which parts of the code might be 'de-optimized' and re-jitted (e.g. when the 'shape' of objects changes), it definitely doesn't only happen at startup or when a function is first called.
- igouy 3y agoThat view seems cynical rather than skeptical. Other comments you've made on this topic seem wrong on basic facts? https://news.ycombinator.com/item?id=39145414 https://news.ycombinator.com/item?id=39145414
- AstralStorm 3y agoHow often do you restart the server so that the JIT compiling time matters? (Moreover the result is often cached.) This point it's more relevant for full interpreters... And perhaps better compilers matter more than their performance - it just so happens that C and C++ compilers are the most developed at the moment. (Except perhaps some shader compilers and Fortran.) The JIT cost gets more egregious in JavaScript since it's paid by every user. Wasm is therefore much more efficient if we can skip the JS compiler...