5 ms·

The problem with these tricks is that they're dependant on V8 internals, which means that there's no guarantee that it will be fast on Firefox (or edge, or even

The problem with these tricks is that they're dependant on V8 internals, which means that there's no guarantee that it will be fast on Firefox (or edge, or even Safari). So now if google changes the back end, websites will slow down, which means that Google has to ossify implementation details, furthering this sort of black magic into CS lore forever. This, honestly, is what I hate with modern dev. A few days back there was a discussion on how programming is hard nowadays. Really, programming is more accessible than ever. What is hard is the "black magic" that's becoming more and more prevalent, most of which is implementation defined, that everyone is expected to know (and really, most don't really know anything. They just repeat rumors they read about online, often years out of date).

kibwen 9y ago
The article does mention SpiderMonkey, though not Safari or Edge, and the point does stand that profiling four different JS JITs to guarantee that you trigger their optimizations is always going to be more work than profiling one C++/Rust program generated by a single compiler toolchain (though it remains to be seen how much individual browsers' implementations of WASM will diverge in runtime optimization potential).
- abritinthebay 9y ago
  They will diverge about as much as JS does, that will hardly be a surprise
  - kibwen 9y ago
    I doubt it. If further optimizing pre-optimized assembly were that easy (or that valuable), then we'd also expect to see more tools for postprocessing compiled binaries. (Just because WASM is a bytecode format doesn't mean it's comparable to Java bytecode and Java's JITs; javac isn't an optimizing compiler.) I'd be happy if anyone actually working on a WASM interpreter could chime in regarding expected optimization potential.
Pxtl 9y ago
It's like SQL servers all over again, where an infinite plethora of rumours and received wisdom and magical thinking guides performance optimization because it's such a goddamned black box that will optimize your query however it sees fit.
- pjmlp 9y ago
  Which is why profilers exist. Writing code based on gut feeling and urban myths was never a good idea.
lkbm 9y ago
In this case, it looks like he's optimizing for Firefox and Chrome--he mentions benchmark results from both and also running into a SpiderMonkey optimization that was causing problems. That does leave out Safari, Edge, Opera, and probably some other obscure browsers, and doesn't help with your point about future engine changes potentially breaking the optimizations.
pjmlp 9y ago
Same applies to other languages with multiple implementations. You might have some high performance C code only tested in gcc on GNU/Linux, and then get some nasty surprises when testing on HP-UX with aC, for example. Back in the day, DDJ and The C/C++ User's Journal used to run articles comparing the quality of all most well known compilers.
vbezhenar 9y ago
Even x86 machine code will work differently on different processors, because it's not executed directly but translated on another machine code and this translation is different on different processors (and AFAIK completely proprietary). There are layers above layers. I won't be surprised if someone will implement JVM over WASM to run Java applications in the browser. And JVM has JavaScript engine, so...

kibwen 9y ago

The article does mention SpiderMonkey, though not Safari or Edge, and the point does stand that profiling four different JS JITs to guarantee that you trigger their optimizations is always going to be more work than profiling one C++/Rust program generated by a single compiler toolchain (though it remains to be seen how much individual browsers' implementations of WASM will diverge in runtime optimization potential).

abritinthebay 9y ago
They will diverge about as much as JS does, that will hardly be a surprise
- kibwen 9y ago
  I doubt it. If further optimizing pre-optimized assembly were that easy (or that valuable), then we'd also expect to see more tools for postprocessing compiled binaries. (Just because WASM is a bytecode format doesn't mean it's comparable to Java bytecode and Java's JITs; javac isn't an optimizing compiler.) I'd be happy if anyone actually working on a WASM interpreter could chime in regarding expected optimization potential.

Pxtl 9y ago

It's like SQL servers all over again, where an infinite plethora of rumours and received wisdom and magical thinking guides performance optimization because it's such a goddamned black box that will optimize your query however it sees fit.

pjmlp 9y ago
Which is why profilers exist. Writing code based on gut feeling and urban myths was never a good idea.

lkbm 9y ago

In this case, it looks like he's optimizing for Firefox and Chrome--he mentions benchmark results from both and also running into a SpiderMonkey optimization that was causing problems. That does leave out Safari, Edge, Opera, and probably some other obscure browsers, and doesn't help with your point about future engine changes potentially breaking the optimizations.

pjmlp 9y ago

Same applies to other languages with multiple implementations. You might have some high performance C code only tested in gcc on GNU/Linux, and then get some nasty surprises when testing on HP-UX with aC, for example. Back in the day, DDJ and The C/C++ User's Journal used to run articles comparing the quality of all most well known compilers.

vbezhenar 9y ago

Even x86 machine code will work differently on different processors, because it's not executed directly but translated on another machine code and this translation is different on different processors (and AFAIK completely proprietary). There are layers above layers. I won't be surprised if someone will implement JVM over WASM to run Java applications in the browser. And JVM has JavaScript engine, so...