3 ms·
The problem with javascript JIT's is that benchmarks which run for tens of a second in a tiny piece of code are not reflective of general usage patterns. So the
by StillBored 9y ago
The problem with javascript JIT's is that benchmarks which run for tens of a second in a tiny piece of code are not reflective of general usage patterns. So the quality of the initial pass (baseline in Firefox) is likely more important. Worse, given fairly dynamic code paths, the system can get into a situations where it is cycling between optimization targets and spends a lot of time running sub-optimal code and entering/exiting the JITed code, or the JIT/compiler itself.
Anyway, there are so many engineering trade offs its like a big water balloon, squeeze it here and it gets faster in this spot, but slows down somewhere else. When, what you really need is a way to let some of the water out of the balloon.
- DonHopkins 9y agoLike nailing jello to a tree.
- fulafel 9y agoA bigger problem is the variability and pace of change combined with poor and level inspectability of generated code. This makes it fragile and laborious to design primitives that compile to efficient code. Contrast to eg. JVM.
- jopsen 9y agowebassembly is the answer to the few high-performance bottlenecks.
- fulafel 9y agoWebAssembly is a poor and high effort compile target for languages like ES6, ClojureScript, Elm, etc.
- espadrine 9y agoWebAssembly is not designed to be a compile target for ES6, ClojureScript, etc. At least not yet. Its primary target currently is languages like C, C++… low-level compiled languages that don't have a garbage collector. (Source: https://github.com/WebAssembly/design/blob/master/GC.md https://github.com/WebAssembly/design/blob/master/GC.md)
- fulafel 9y agoThat's what I tried to say, wasm does not solve the problem I described.
- deleted 9y ago[deleted]