8 ms·
This article has a number of issues. JS with JIT is waaay faster than Python. Not “between python and java” as purported. Second, generalizing jits as “un-ergon
by banachtarski 7y ago
This article has a number of issues. JS with JIT is waaay faster than Python. Not “between python and java” as purported. Second, generalizing jits as “un-ergonomic” seems silly given that what’s being specifically looked at is benchmarking. But what makes this claim ridiculous is that nothing is easy to benchmark. Even native code is hard to profile and this is literally my day job. If the JIT makes your code that much faster, this strikes me as a pretty suspect complaint
- pizlonator 7y agoI 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 agoThat still doesn't make sense to me.. how can JIT in general be slower than Java when Java is JITed?
- throwaway894345 7y agoThe claim wasn’t about JIT in general, but rather about JS.
- deleted 7y ago[deleted]
- pizlonator 7y agoThen 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 agoI’m not advocating for the post or anything else, I was just clarifying a misunderstanding.
- seanmcdirmid 7y agoThe 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 agoThis. 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 agoThis 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 agoYeah what you said.
- raverbashing 7y agoYou'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 agoVerbosity makes the programmer slower not the program.
- kevingadd 7y agoThe 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 agoThe 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 agoPython 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 agoPython does not seem to be even trying to be competitive in performance though so it's less of an issue for them.
- progval 7y agoThey 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.
- j88439h84 7y agoPypy JIT is way faster than CPython
- throwaway894345 7y agoIt is, but that’s not saying a lot and it’s still far far slower than Go/Java/C#, and it also isn’t compatible with lots of existing Python code. Such as anything that would like to talk to a Postgres database. Pypy is great, but it can’t fix a broken ecosystem and general lack of leadership in the Python community. :( (Broken ecosystem = lots of things don’t work with lots of other things; package managers are another example; Mypy another)
- aeyes 7y agoWhat's the problem with Postgres on PyPy? Running fine in production here.
- throwaway894345 7y agoThere are no supported drivers for it as far as I could find. The common answer is to use psycopg2cffi, but that hasn’t had a commit in like 4 years. The alternatives I could find were in the same shape or worse.
- anarazel 7y agoThere's a few pure python drivers. Check https://wiki.postgresql.org/wiki/Python https://wiki.postgresql.org/wiki/Python and https://wiki.python.org/moin/PostgreSQL https://wiki.python.org/moin/PostgreSQL E.g. pg8000 looks like it's being maintained?
- throwaway894345 7y agoI recall looking at pg8000 in particular, but it didn't inspire confidence for our production use case. It had only 20 commits in 2019 and fewer than 100 stars. I also didn't have a good understanding of the performance tradeoffs (pypy/pg8000 vs C library).
- fnord123 7y ago>JS with JIT is waaay faster than Python. Not “between python and java” as purported. You are correct that JS is not between Python and Java. Python is faster than Java which is faster than JS. Though some people seem to think calling APIs written in C is "not Python" but if the ecosystem provides the library and I call it from Python then it's Python enough for me!
- gbear605 7y agoBy that logic, Python, Javascript, and Java are all the same speed, just call out to C, or assembly perhaps if you really want to tune some code.
- fnord123 7y agoNo, not at all. Java FFI is extremely expensive.
- pizlonator 7y agoYeah. And so is JS’s. I think CPython’s design makes it a champ at native interop and a loser at pure compute perf. That’s a valid trade off for lots of important situations.
- frankpf 7y agoAre you referring to V8's/Node's C FFI? Why is that extremely expensive?
- smabie 7y agoIt's not a trade-off. There's no reason why you can't have a blazing fast and expressive language that also has good C FFI. A single good programmer could make a language that was as expressive as Python (that is, not very), faster, and with a good C FFI in under 6 months.
- progval 7y ago
- imtringued 7y agoThat was not a general statement about Javascript performance. The entire article is about the unpredictability of the JIT. When the JIT hits a bad codepath then it really does perform like python or when it hits a good code path (most of the time) then it performs like java. This unpredictability is what is causing the issues, not the general performance.