7 ms·

I think that by “between python and java” they meant “faster than python and slower than java”. I think Java still beats JS unless you get lucky. You’re totall

I think that by “between python and java” they meant “faster than python and slower than java”. I think Java still beats JS unless you get lucky. You’re totally right that benchmarking and profiling is hard even for native code. I think this post fetishizes whether or not a piece of code got JITed a little too much. Maybe the author had a bad time with microbenchmarks. There’s this anti pattern in the JS world to extract a small code sample into a loop and see how fast it goes - something that C perf hackers usually know not to do. That tactic proves especially misleading in a JIT since JITs salivate at the sight of loops.

shawnz 7y ago
That still doesn't make sense to me.. how can JIT in general be slower than Java when Java is JITed?
- throwaway894345 7y ago
  The claim wasn’t about JIT in general, but rather about JS.
  - deleted 7y ago
    [deleted]
  - pizlonator 7y ago
    Then it’s problematic to be so JS and V8 centric. Also the post specifically talked about JS being faster than Python and slower than Java so that’s what this thread is about.
    - throwaway894345 7y ago
      I’m not advocating for the post or anything else, I was just clarifying a misunderstanding.
- seanmcdirmid 7y ago
  The Java JIT has static type information to work with, the JS JIT can only infer type information via heroic efforts. Static types do mean something, especially when working with primitives and other unboxed data types.
  - erik_seaberg 7y ago
    This. Javascript engines have to do stuff like https://mathiasbynens.be/notes/shapes-ics https://mathiasbynens.be/notes/shapes-ics to assume many objects will have the same key names and types and create an optimized class layout, with some kind of expensive fallback if anyone ever randomly stores a key or value that violates the assumption. They can't even be sure you'll always be doing integer math (unless you resort to bit masking a la asm.js). Hinting (like __slots__ in Python) might have helped some.
    - discreteevent 7y ago
      This was one of the main motivations for writing dart. The V8 implementers were tired of having to write these kinds of hacks. Even though dart was initially a dynamically typed language, the shape of the objects was stable.
  - pizlonator 7y ago
    Yeah what you said.
  - raverbashing 7y ago
    You're not wrong, but I always wonder how the verbosity and crazy class hierarchy of Java code doesn't make things slower. I know that compilers are smart, but the API doesn't make things easier at all
    - bosswipe 7y ago
      Verbosity makes the programmer slower not the program.
- kevingadd 7y ago
  The design of JavaScript is not very friendly to high performance. Even though Java is itself not easy to generate efficient code from, producing efficient code from JavaScript is far more difficult.
- ridiculous_fish 7y ago
  The peer comment about static typing is correct, but there's more, err, flavor to be enjoyed in the challenges of JITing JS. Here's some deopt scenarios to keep you up at night. To whet your appetite, what happens if you redefine Math.round? Java prohibits this for obvious reasons, but a JS joker may write: Math.round = () => Infinity; JS engines really do inline Math.round, and must be prepared for this nonsense. It gets worse. Maybe you check for a property which is usually not found: if (!val.uuid) val.uuid = uuidgen(); Hidden classes can almost reduce this to a pointer comparison. But what if someone adds a uuid property on Object.prototype? Every check is busted! v8 handles this with "validity cells", and it's ugly, requiring that every object know about every object which "inherits" from it. Now if you are a monster you may choose to write: Object.defineProperty(Array.prototype, "42", {value: "lol"}); console.log([][42]); // yes it prints "lol" Every array gets a default value for 42. Think about how you would JIT numeric code in such an environment...
  - progval 7y ago
    Python suffers the same issue. There's some discussion about dealing with it in this PEP and the pages it links: https://www.python.org/dev/peps/pep-0509/ https://www.python.org/dev/peps/pep-0509/
    - The_Colonel 7y ago
      Python does not seem to be even trying to be competitive in performance though so it's less of an issue for them.
      - progval 7y ago
        They do, it's just not a priority. The PEP I linked (as well as most of the work of its author, Victor Stinner, in the last years) are motivated by JITing. There's also the "frame evaluation API" PEP [1], whose purpose is to allow pluggable evaluators in CPython without forking the entire interpreter, like Unladen Swallow had to. [1]: https://www.python.org/dev/peps/pep-0523/ https://www.python.org/dev/peps/pep-0523/
    - 7y ago
Skunkleton 7y ago
> I think that by “between python and java” they meant “faster than python and slower than java”. I think Java still beats JS unless you get lucky. Yeah, that is what they meant, but it is a little misleading. Javascript's performance is usually within a single digit multiple of java's, whereas python is often significantly slower. Javascript is somewhere between Java and an abacus too.

shawnz 7y ago

That still doesn't make sense to me.. how can JIT in general be slower than Java when Java is JITed?

throwaway894345 7y ago
The claim wasn’t about JIT in general, but rather about JS.
- deleted 7y ago
  [deleted]
- pizlonator 7y ago
  Then it’s problematic to be so JS and V8 centric. Also the post specifically talked about JS being faster than Python and slower than Java so that’s what this thread is about.
  - throwaway894345 7y ago
    I’m not advocating for the post or anything else, I was just clarifying a misunderstanding.
seanmcdirmid 7y ago
The Java JIT has static type information to work with, the JS JIT can only infer type information via heroic efforts. Static types do mean something, especially when working with primitives and other unboxed data types.
- erik_seaberg 7y ago
  This. Javascript engines have to do stuff like https://mathiasbynens.be/notes/shapes-ics https://mathiasbynens.be/notes/shapes-ics to assume many objects will have the same key names and types and create an optimized class layout, with some kind of expensive fallback if anyone ever randomly stores a key or value that violates the assumption. They can't even be sure you'll always be doing integer math (unless you resort to bit masking a la asm.js). Hinting (like __slots__ in Python) might have helped some.
  - discreteevent 7y ago
    This was one of the main motivations for writing dart. The V8 implementers were tired of having to write these kinds of hacks. Even though dart was initially a dynamically typed language, the shape of the objects was stable.
- pizlonator 7y ago
  Yeah what you said.
- raverbashing 7y ago
  You're not wrong, but I always wonder how the verbosity and crazy class hierarchy of Java code doesn't make things slower. I know that compilers are smart, but the API doesn't make things easier at all
  - bosswipe 7y ago
    Verbosity makes the programmer slower not the program.
kevingadd 7y ago
The design of JavaScript is not very friendly to high performance. Even though Java is itself not easy to generate efficient code from, producing efficient code from JavaScript is far more difficult.
ridiculous_fish 7y ago
The peer comment about static typing is correct, but there's more, err, flavor to be enjoyed in the challenges of JITing JS. Here's some deopt scenarios to keep you up at night. To whet your appetite, what happens if you redefine Math.round? Java prohibits this for obvious reasons, but a JS joker may write: Math.round = () => Infinity; JS engines really do inline Math.round, and must be prepared for this nonsense. It gets worse. Maybe you check for a property which is usually not found: if (!val.uuid) val.uuid = uuidgen(); Hidden classes can almost reduce this to a pointer comparison. But what if someone adds a uuid property on Object.prototype? Every check is busted! v8 handles this with "validity cells", and it's ugly, requiring that every object know about every object which "inherits" from it. Now if you are a monster you may choose to write: Object.defineProperty(Array.prototype, "42", {value: "lol"}); console.log([][42]); // yes it prints "lol" Every array gets a default value for 42. Think about how you would JIT numeric code in such an environment...
- progval 7y ago
  Python suffers the same issue. There's some discussion about dealing with it in this PEP and the pages it links: https://www.python.org/dev/peps/pep-0509/ https://www.python.org/dev/peps/pep-0509/
  - The_Colonel 7y ago
    Python does not seem to be even trying to be competitive in performance though so it's less of an issue for them.
    - progval 7y ago
      They do, it's just not a priority. The PEP I linked (as well as most of the work of its author, Victor Stinner, in the last years) are motivated by JITing. There's also the "frame evaluation API" PEP [1], whose purpose is to allow pluggable evaluators in CPython without forking the entire interpreter, like Unladen Swallow had to. [1]: https://www.python.org/dev/peps/pep-0523/ https://www.python.org/dev/peps/pep-0523/
  - 7y ago

Skunkleton 7y ago

> I think that by “between python and java” they meant “faster than python and slower than java”. I think Java still beats JS unless you get lucky. Yeah, that is what they meant, but it is a little misleading. Javascript's performance is usually within a single digit multiple of java's, whereas python is often significantly slower. Javascript is somewhere between Java and an abacus too.