3 ms·

Are you sure? According to [1] the V8 Javascript engine also includes function inlining. Additionally cache locality is still achievable in JS, if the user desi

Are you sure? According to [1] the V8 Javascript engine also includes function inlining. Additionally cache locality is still achievable in JS, if the user designs their data structures/code-patterns with the goal of maximising locality [2]. As the engine does not know the types of variables, or the layout of types immediately there is definitely a slower startup than pure C code, but it looks like the V8 engine does do a lot under the hood to get definite type information and thus get the speed advantages. [1] http://www.html5rocks.com/en/tutorials/speed/v8/ http://www.html5rocks.com/en/tutorials/speed/v8/ [2] http://jsperf.com/cache-lines-a-demonstration http://jsperf.com/cache-lines-a-demonstration

azakai 11y ago
Yes, v8 and all other modern JS engines perform function inlining and type profiling. Still, it is extremely common to see modern JS engines be competitive with C on small microbenchmarks, but lag behind on large, realistic codebases. There are several reasons for this: 1. JS engines must make tradeoffs between what to inline and what not - each inlining requires a recompilation. Offline C compilers don't have such concerns. 2. Inlining creates large functions, and large codebases tend to have large functions anyhow, and large functions take longer to JIT, making realistic codebases much more challenging for JS engines. 3. It's fairly easy for modern JS engines to figure out types at runtime in a small loop. However, when figuring out types in a large program spread over many functions, it takes substantial overhead to try to do a holistic solution, and instead, JS engines generally just do a local analysis and hope that what really needs to be optimized is inlined anyhow - but see 1 and 2. And when not inlining, function call arguments generally do not happen in an optimized type, but in boxed form. Overall, it is not surprising at all that the article saw C-like performance on a small micro-benchmark, on a modern browser. But in a realistic codebase, there almost certainly would be a large slowdown. That's why asm.js exists and why WebAssembly is on the way.

azakai 11y ago

Yes, v8 and all other modern JS engines perform function inlining and type profiling. Still, it is extremely common to see modern JS engines be competitive with C on small microbenchmarks, but lag behind on large, realistic codebases. There are several reasons for this: 1. JS engines must make tradeoffs between what to inline and what not - each inlining requires a recompilation. Offline C compilers don't have such concerns. 2. Inlining creates large functions, and large codebases tend to have large functions anyhow, and large functions take longer to JIT, making realistic codebases much more challenging for JS engines. 3. It's fairly easy for modern JS engines to figure out types at runtime in a small loop. However, when figuring out types in a large program spread over many functions, it takes substantial overhead to try to do a holistic solution, and instead, JS engines generally just do a local analysis and hope that what really needs to be optimized is inlined anyhow - but see 1 and 2. And when not inlining, function call arguments generally do not happen in an optimized type, but in boxed form. Overall, it is not surprising at all that the article saw C-like performance on a small micro-benchmark, on a modern browser. But in a realistic codebase, there almost certainly would be a large slowdown. That's why asm.js exists and why WebAssembly is on the way.