6 ms·

> NodeJS relies on V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner), and a spectacular piece of software. Uhm, has V8

by patrec 5y ago

> NodeJS relies on V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner), and a spectacular piece of software. Uhm, has V8 come anywhere near LuaJIT's performance by now? And LuaJIT is basically a one-man effort.

samhw 5y ago
Sorry, I should have been clearer: I meant that it's had the most manpower dedicated to optimising it, not that it's necessarily the most optimal. It's hard to make apples-to-apples comparisons in that respect, given the significant differences between different language specifications. (For instance, it's hard for anyone to write a reference-compliant interpreter for Python which is as fast as the interpreter they could write for, say, Ada or Haskell.)
- danachow 5y ago
  Well you did say: “ NodeJS relies on V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner)” But even in manpower this is pretty hyperbolic compared to Java and .NET. There was probably more manpower in even some of the third party Java runtimes like Azul.
  - samhw 5y ago
    > Well you did say: "NodeJS relies on V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner)" Yes, and that's exactly what I meant. It's undergone the most optimisation. That doesn't mean the result will necessarily be more performant than some other interpreter for a different language which is simpler to interpret. By that logic, I could write an 'x86 interpreter' which would blow LuaJIT out of the water... > But even in manpower this is pretty hyperbolic compared to Java and .NET. I wasn't including Java because it's not strictly an interpreted language, though I admit you could write a whole book about the philosophical differences between V8's abstract machine vs Java's bytecode VM. .NET I don't know so much about. As far as I'm aware, .NET hasn't had as much manpower invested, though Java has & would certainly beat V8 if you included it.
- yccs27 5y ago
  That is precisely the point jvanderbot made: nodejs has less-than-optimal performance, and not for lack of trying to improve it. Its hard to write fast implementations of js or python, so they should not be used where speed matters.
  - samhw 5y ago
    > nodejs has less-than-optimal performance, and not for lack of trying to improve it I think you mean "less-than-C" performance, no? I'd say it's pretty close to optimal performance - it's just that the optimum is not that high compared with a stricter language, or indeed a compiled language, which are able to exploit far more invariants (especially in the latter case). Anyway, I think his point was fundamentally correct, but it just seemed like an odd choice to single out one of the world's best interpreters - and one which is fairly competitive even with fast compiled languages - as your example. If he'd chosen CPython, I'd have been with him all the way, haha. (As someone who's written a faster Python interpreter, ...don't even get me started on that one.)
ecnahc515 5y ago
To be fair, there's a bound how much the JIT/interpreter can do for a given language. Lua is a lot simpler, and a lot easier to optimize as a result, compared to JS.
- patrec 5y ago
  I don't buy that. If you squint a bit, Lua and Javascript are basically the same language. Lua shares many of javascript's peculiarities and warts (strings you can do arithmetic on, all numbers are doubles (originally), arrays are objects are hashtables of sorts, global scope by default etc). Now it's of course true that Lua is less of a mess than javascript, but a) the complexity explosion of javascript postdates V8 quite a bit b) lua has plenty of optimization challenges of its own that javascript lacks (e.g. metatables) c) the relative amount of resources poured into both projects differ by orders of magnitude (3?). I'm pretty doubtful anyone tasked to build the fastest JIT in the world from scratch upon being offered a choice between targetting lua (with luajit's total budget) and javascript (with v8's total budget) would pick lua.
  - samhw 5y ago
    No offence, but have you written any compilers or interpreters? The points that you discuss (all numbers are doubles, strings have arithmetic methods) may be performance concerns for application developers, but they have very little to do with the optimisations you can make as a compiler/interpreter writer. The only one that's somewhat relevant is 'global scope by default', but this doesn't touch the surface of the issues that make JS hard to optimise, such as the fact that your, say, memoisation of an object property or method may be broken by an `eval` call of an arbitrary runtime value somewhere else in the code (which, due to asynchronicity, could take place at more or less any time from the point of view of your given 'peephole').
    - patrec 5y ago
      > No offence, but have you written any compilers or interpreters? I have, but nothing sophisticated. > The points that you discuss [...] may be performance concerns for application developers [...] but they have very little to do with the optimisations you can make as a compiler/interpreter writer. [...] The only one that's somewhat relevant is 'global scope by default' I didn't mean to imply that these where the three common traits that make both Javascript and Lua particularly hard to optimize, I just picked them as examples for how Javascript and Lua are closer to each other than most other dynamic languages. But let's dig in a bit on your claim that things like all numbers being doubles or having a array cum map cum record type has very little to do with the optimizations you can make as a compiler/interpreter writer, because it sure seems to me that LuaJIT and V8 do a bunch of optimizations around these things. Both have dual number representations under the hood and will try to avoid representing numbers that remain in the domain of 32 bit integers as double values internally when that gives performance gains. The logic for figuring out if that's the case doesn't seem to be super-straightforward or target architecture independent from looking at the comments in <https://github.com/LuaDist/luajit/blob/master/src/lj_opt_narrow.c https://github.com/LuaDist/luajit/blob/master/src/lj_opt_nar...>. LuaJIT furthermore uses NaN tagging (as do some JS engines, although not V8), which looks less attractive to me as a representation strategy if your numbers are not all/mostly notional doubles (as is indeed the case in newer version of Lua where 64bit integers are the dominant number type). Do you disagree? Also, as far as the super-flexible lua tables are concerned, I'm pretty sure LuaJIT goes through some amount of trouble to specialize various common use cases of tables, e.g. as arrays without holes, and surprise, so does V8 (https://v8.dev/blog/fast-properties#elements-or-array-indexed-properties https://v8.dev/blog/fast-properties#elements-or-array-indexe...). I don't think you'd find something equivalent in a high performance scheme implementation. > but this doesn't touch the surface of the issues that make JS hard to optimise, such as the fact that your, say, memoisation of an object property or method may be broken by an `eval` call of an arbitrary runtime value somewhere else in the code (which, due to asynchronicity, could take place at more or less any time from the point of view of your given 'peephole'). Eval belongs to a core set of features that basically all popular dynamic languages share that presents headaches for high performance implementations. How is Javascript's eval particularly problematic in this regard, and specifically much more so than Lua's loadstring/load? More generally what do you think makes (pre-ES6) javascript significantly harder to optimize than lua 5.0?

by patrec 5y ago

samhw 5y ago

Sorry, I should have been clearer: I meant that it's had the most manpower dedicated to optimising it, not that it's necessarily the most optimal. It's hard to make apples-to-apples comparisons in that respect, given the significant differences between different language specifications. (For instance, it's hard for anyone to write a reference-compliant interpreter for Python which is as fast as the interpreter they could write for, say, Ada or Haskell.)

danachow 5y ago
Well you did say: “ NodeJS relies on V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner)” But even in manpower this is pretty hyperbolic compared to Java and .NET. There was probably more manpower in even some of the third party Java runtimes like Azul.
- samhw 5y ago
  > Well you did say: "NodeJS relies on V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner)" Yes, and that's exactly what I meant. It's undergone the most optimisation. That doesn't mean the result will necessarily be more performant than some other interpreter for a different language which is simpler to interpret. By that logic, I could write an 'x86 interpreter' which would blow LuaJIT out of the water... > But even in manpower this is pretty hyperbolic compared to Java and .NET. I wasn't including Java because it's not strictly an interpreted language, though I admit you could write a whole book about the philosophical differences between V8's abstract machine vs Java's bytecode VM. .NET I don't know so much about. As far as I'm aware, .NET hasn't had as much manpower invested, though Java has & would certainly beat V8 if you included it.
yccs27 5y ago
That is precisely the point jvanderbot made: nodejs has less-than-optimal performance, and not for lack of trying to improve it. Its hard to write fast implementations of js or python, so they should not be used where speed matters.
- samhw 5y ago
  > nodejs has less-than-optimal performance, and not for lack of trying to improve it I think you mean "less-than-C" performance, no? I'd say it's pretty close to optimal performance - it's just that the optimum is not that high compared with a stricter language, or indeed a compiled language, which are able to exploit far more invariants (especially in the latter case). Anyway, I think his point was fundamentally correct, but it just seemed like an odd choice to single out one of the world's best interpreters - and one which is fairly competitive even with fast compiled languages - as your example. If he'd chosen CPython, I'd have been with him all the way, haha. (As someone who's written a faster Python interpreter, ...don't even get me started on that one.)

ecnahc515 5y ago

To be fair, there's a bound how much the JIT/interpreter can do for a given language. Lua is a lot simpler, and a lot easier to optimize as a result, compared to JS.

patrec 5y ago
I don't buy that. If you squint a bit, Lua and Javascript are basically the same language. Lua shares many of javascript's peculiarities and warts (strings you can do arithmetic on, all numbers are doubles (originally), arrays are objects are hashtables of sorts, global scope by default etc). Now it's of course true that Lua is less of a mess than javascript, but a) the complexity explosion of javascript postdates V8 quite a bit b) lua has plenty of optimization challenges of its own that javascript lacks (e.g. metatables) c) the relative amount of resources poured into both projects differ by orders of magnitude (3?). I'm pretty doubtful anyone tasked to build the fastest JIT in the world from scratch upon being offered a choice between targetting lua (with luajit's total budget) and javascript (with v8's total budget) would pick lua.
- samhw 5y ago
  No offence, but have you written any compilers or interpreters? The points that you discuss (all numbers are doubles, strings have arithmetic methods) may be performance concerns for application developers, but they have very little to do with the optimisations you can make as a compiler/interpreter writer. The only one that's somewhat relevant is 'global scope by default', but this doesn't touch the surface of the issues that make JS hard to optimise, such as the fact that your, say, memoisation of an object property or method may be broken by an `eval` call of an arbitrary runtime value somewhere else in the code (which, due to asynchronicity, could take place at more or less any time from the point of view of your given 'peephole').
  - patrec 5y ago
    > No offence, but have you written any compilers or interpreters? I have, but nothing sophisticated. > The points that you discuss [...] may be performance concerns for application developers [...] but they have very little to do with the optimisations you can make as a compiler/interpreter writer. [...] The only one that's somewhat relevant is 'global scope by default' I didn't mean to imply that these where the three common traits that make both Javascript and Lua particularly hard to optimize, I just picked them as examples for how Javascript and Lua are closer to each other than most other dynamic languages. But let's dig in a bit on your claim that things like all numbers being doubles or having a array cum map cum record type has very little to do with the optimizations you can make as a compiler/interpreter writer, because it sure seems to me that LuaJIT and V8 do a bunch of optimizations around these things. Both have dual number representations under the hood and will try to avoid representing numbers that remain in the domain of 32 bit integers as double values internally when that gives performance gains. The logic for figuring out if that's the case doesn't seem to be super-straightforward or target architecture independent from looking at the comments in <https://github.com/LuaDist/luajit/blob/master/src/lj_opt_narrow.c https://github.com/LuaDist/luajit/blob/master/src/lj_opt_nar...>. LuaJIT furthermore uses NaN tagging (as do some JS engines, although not V8), which looks less attractive to me as a representation strategy if your numbers are not all/mostly notional doubles (as is indeed the case in newer version of Lua where 64bit integers are the dominant number type). Do you disagree? Also, as far as the super-flexible lua tables are concerned, I'm pretty sure LuaJIT goes through some amount of trouble to specialize various common use cases of tables, e.g. as arrays without holes, and surprise, so does V8 (https://v8.dev/blog/fast-properties#elements-or-array-indexed-properties https://v8.dev/blog/fast-properties#elements-or-array-indexe...). I don't think you'd find something equivalent in a high performance scheme implementation. > but this doesn't touch the surface of the issues that make JS hard to optimise, such as the fact that your, say, memoisation of an object property or method may be broken by an `eval` call of an arbitrary runtime value somewhere else in the code (which, due to asynchronicity, could take place at more or less any time from the point of view of your given 'peephole'). Eval belongs to a core set of features that basically all popular dynamic languages share that presents headaches for high performance implementations. How is Javascript's eval particularly problematic in this regard, and specifically much more so than Lua's loadstring/load? More generally what do you think makes (pre-ES6) javascript significantly harder to optimize than lua 5.0?