4 ms·

These micro programs are very easy to JIT, so nearly identical performance is to be expected. It's when you get larger programs that C compilers with function i

by gizmo 11y ago

These micro programs are very easy to JIT, so nearly identical performance is to be expected. It's when you get larger programs that C compilers with function inlining and better cache locality and whole program optimization leave JIT compiled languages in the dust. When you have a loop of a billion iterations the JIT compiler can instantly tell that it's worth optimizing whatever is in the loop body. When you have a more complex program the JIT does not know which parts to optimize. Any time spent on this kind of "what should I optimize" meta-analysis has to be earned back by making future code run faster, so you run into diminishing returns pretty quickly.

hacker_9 11y ago
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.
hinkley 11y ago
When the users complain that the app is 'too slow' and the devs say "we've done everything we can", I'm usually the guy who goes and finds another 30% without doing anything crazy. Two things I see pretty consistently. First is that when there are no tall tent poles (20 functions take 5% of the time each), people don't know what to do, so they don't do anything. Second, and possibly easier to fix, is that people believe the perf analysis tool (the breakdown of where time is spent) is telling them the objective truth. Often it's wrong, which is why we try things, benchmark them, and revert changes if things get worse. When there are no tall tent poles I switch to invocation count, which is the best secondary indicator of hotspots. There was one method that the perf tool told me was taking 10% of the run time. But the call count was fishy. Due to a bad call structure it was being called far more often than necessary. In the worst spot in the code two sequential calls were calling this function, so I flipped the code around so they could take the answer as an argument (memoization). I reran the benchmarks. I had removed 50% of calls to a function that took 10% of our time, and the code overall was now 20% (twenty percent!) faster. Why? Functions allocate memory. They evict cache lines in the data and instruction caches. They might even access constrained resources, like disk. And as you said, they change how the JIT decides to optimize things. Sometimes, the symptom is that the code that runs immediately afterward gets blamed for problems they didn't create, and the profiler has no way of following the problem back to the root cause, so it assigns blame at the point of contention, not at the start of the contention. The only tools I've found that helps with this are clean coding practices, and figuring out if your invocation counts match your expectations (I will run a call tree 100 times and then compare the call counts of everything to find things that were called 2+ times as often as they strictly should have been called)
- johnmaguire2013 11y ago
  > I reran the benchmarks. I had removed 50% of calls to a function that took 10% of our time, and the code overall was now 20% (twenty percent!) faster. This reminds me on another comment I read on HN, that I consider something of a "performance paradox": https://news.ycombinator.com/item?id=9895531 https://news.ycombinator.com/item?id=9895531
  - 11y ago

by gizmo 11y ago

hacker_9 11y ago

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.

hinkley 11y ago

When the users complain that the app is 'too slow' and the devs say "we've done everything we can", I'm usually the guy who goes and finds another 30% without doing anything crazy. Two things I see pretty consistently. First is that when there are no tall tent poles (20 functions take 5% of the time each), people don't know what to do, so they don't do anything. Second, and possibly easier to fix, is that people believe the perf analysis tool (the breakdown of where time is spent) is telling them the objective truth. Often it's wrong, which is why we try things, benchmark them, and revert changes if things get worse. When there are no tall tent poles I switch to invocation count, which is the best secondary indicator of hotspots. There was one method that the perf tool told me was taking 10% of the run time. But the call count was fishy. Due to a bad call structure it was being called far more often than necessary. In the worst spot in the code two sequential calls were calling this function, so I flipped the code around so they could take the answer as an argument (memoization). I reran the benchmarks. I had removed 50% of calls to a function that took 10% of our time, and the code overall was now 20% (twenty percent!) faster. Why? Functions allocate memory. They evict cache lines in the data and instruction caches. They might even access constrained resources, like disk. And as you said, they change how the JIT decides to optimize things. Sometimes, the symptom is that the code that runs immediately afterward gets blamed for problems they didn't create, and the profiler has no way of following the problem back to the root cause, so it assigns blame at the point of contention, not at the start of the contention. The only tools I've found that helps with this are clean coding practices, and figuring out if your invocation counts match your expectations (I will run a call tree 100 times and then compare the call counts of everything to find things that were called 2+ times as often as they strictly should have been called)

johnmaguire2013 11y ago
> I reran the benchmarks. I had removed 50% of calls to a function that took 10% of our time, and the code overall was now 20% (twenty percent!) faster. This reminds me on another comment I read on HN, that I consider something of a "performance paradox": https://news.ycombinator.com/item?id=9895531 https://news.ycombinator.com/item?id=9895531
- 11y ago