An update. I ran the test again, as of Jul 10th, 2013.
V8 version 3.20.5:
> time ./d8 ./nbody_plain_objects.js -- 50000000
-0.169075164
-0.169059907
./d8 ./nbody_plain_objects.js -- 50000000 16.13s user 0.01s system 99% cpu
16.156 total
SpiderMonkey's js shell, version: JavaScript-C25.0a1:
> time ./js ./nbody_plain_objects.js 50000000
-0.169075164
-0.169059907
./js ./nbody_plain_objects.js 50000000 18.88s user 0.02s system 99% cpu
18.904 total
Nicely done, guys! Thank you very much for this :)!
--
Andrei
On Monday, April 22, 2013 2:37:51 PM UTC-7, Andrei Kashcha 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
>
--
--
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.
