Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Surprises in GopherJS Performance

gopherjs.org

Post reply on HN
Print view View original

1–10 of 29 posts

Re: Surprises in GopherJS Performance

#3

Post by pauljz »

In the final example where he switches to int32 for Go (after "Let's make it use int32 consistently and try again"), he runs gopherjs twice instead of running go and gopherjs. I hope that's a typo.

The reasoning seems correct, but it'd be nice to have the benchmarks corrected to verify.

Re: Surprises in GopherJS Performance

#5

Post by gizmo »

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.

Re: Surprises in GopherJS Performance

#7

Post by shurcooL »

pauljz wrote: post #3

In the final example where he switches to int32 for Go (after "Let's make it use int32 consistently and try again"), he runs gopherjs twice instead of running go and gopherjs. I hope that's a typo. The reasoning seems correct, but it'd be nice to have the benchmarks corrected to verify.

It is indeed a typo, sorry about that!

I've fixed it [1] after confirming [2] (yet again just now; I've ran those numbers many many times so I'm very confident it's not a one time fluke).

Thanks for catching it. You're also welcome to try to confirm the results yourself, they should be reproducible!

[1] https://github.com/gopherjs/gopherjs.github.io/commit/acea7a...

[2] https://gist.github.com/shurcooL/02183a57c51b28eaadf4

Re: Surprises in GopherJS Performance

#9

Post by hacker_9 »

gizmo wrote: post #5

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…

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/

[2] http://jsperf.com/cache-lines-a-demonstration

Post reply on HN