On Mon, Apr 22, 2013 at 11:37 PM, Andrei Kashcha <[email protected]> wrote: > Recently I've been profiling a lot v8's garbage collection. Surprising truth > is it's really slow when JS program does heavy computation. For example, > consider a straightforward n-body computation for 5 bodies, over 50 000 000 > iterations [1]. > > When running this program in d8: > >> time ./d8 ./nbody_plain_objects.js -- 50000000 > -0.169075164 > -0.169059907 > ./d8 ./nbody_plain_objects.js -- 50000000 46.95s user 0.07s system 99% cpu > 47.036 total > > Now compare the same results with Mozilla's SpiderMonkey shell [2]: > >> time ./js ./nbody_plain_objects.js 50000000 > -0.169075164 > -0.169059907 > ./js ./nbody_plain_objects.js 50000000 20.27s user 0.02s system 99% cpu > 20.288 total > > SpiderMonkey is more than two times faster! Why? Turns out V8 produces a lot > of numbers on the heap, when using plain javascript objects: > > function Body(x,y,...) { > this.X = x; > this.Y = y; ... > > } > > This creates lots of garbage and slows down performance of the algorithm > significantly. The garbage collection could be avoided in V8, if program is > rewritten with use of Float64Arrays, and manual implementation of heap-like > structure. Doing so [3], puts v8 on the same speed level with SpiderMonkey: > >> time ./d8 ./nbody_array.js -- 50000000 > -0.169075164 > -0.169059907 > ./d8 ./nbody_array.js -- 50000000 21.45s user 0.02s system 99% cpu 21.487 > total > > SpiderMonkey insignificantly suffers, but still shows decent results: >> time ./js ./nbody_array.js 50000000 > -0.169075164 > -0.169059907 > ./js ./nbody_array.js 50000000 23.73s user 0.02s system 99% cpu 23.749 > total > > I definitely could rewrite my programs with use of native arrays, but I > don't really think this scales well for the larger audience of programmers, > who are doing calculus in JS. Maybe I'm missing a technique which would let > me avoid GCs at all, with no need to rewrite programs? I would also like to > avoid imposing on my users a need to launch chrome (v8) with a special > flags... > > PS: All tests are done on MacBook Pro, 2.4 GHz, Intel Core i5, with latest > x64.release build of V8, and latest nightly build of SpiderMonkey [2]. > > [1] https://gist.github.com/anvaka/5438615 > [2] http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ > [3] https://gist.github.com/anvaka/5438702
That's because in V8 floating point numbers are (mostly) heap allocated while SM uses NaN tagging (though it calls it nun boxing, I believe.) If you run your benchmarks with integral types instead, I'll bet good money that V8 comes out on top. -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
