V8bench Info: Difference between revisions
Nnethercote (talk | contribs) No edit summary |
|||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
== v8-crypto == | This info is for v8-v5. | ||
== v8-crypto == | |||
Almost all the time is spent in the function am3(), which is an integer arithmetic kernel that operates on arrays. | |||
JM generates good code for am3(). | |||
Type specialization (Crankshaft/TI) is expected to give a big perf boost here. | |||
See also [https://bugzilla.mozilla.org/show_bug.cgi?id=643565 bug 643565].<br> | |||
== v8-deltablue == | == v8-deltablue == | ||
The benchmark builds a system of constraints and runs a solver. The constraints are represented by object-oriented data structures with several levels of wrapping. The bottom level is 'function OrderedCollection', which wraps a JS array. | |||
Because of the many small functions that wrap each other in Java-esque style, this benchmark benefits strongly from fast method calls (o.f()) and/or inlining. | |||
This benchmark also creates many objects and arrays, so allocation speed is also important. GC mark/sweep speed is not critical, but matters somewhat. | |||
The benchmark does a lot of |array.length|, equality comparisons, and Array.push/pop, so making those faster would also help. | |||
See also [https://bugzilla.mozilla.org/show_bug.cgi?id=643615 bug 643615] | |||
== v8-earley-boyer == | == v8-earley-boyer == | ||
This is a mostly-mechanical Scheme->JS translation of two programs: earley, which does parsing, and boyer, which is a constraint solver. It has functions named 'sc_Pair' (like cons), 'sc_list', 'sc_append', and so on; the three just given are the ones that account for the most time. | |||
Being based on Scheme, this program creates a lot of small objects, so fast object allocation and generational GC are very important. Inlined constructors would also help. | |||
sc_list and sc_append use |arguments|, but only locally, so making this faster by not creating an arguments object would help. Same goes for call objects in closures. | |||
The extensive use of closures also generate a lot of CALLNAME ops, so those need to be fast. | |||
There is a lot of tail recursion, and also general tail calls. | |||
See also [https://bugzilla.mozilla.org/show_bug.cgi?id=642001 bug 642001]. | |||
== v8-raytrace == | == v8-raytrace == | ||
This is an object-oriented raytracer. It does a lot of arithmetic, for which JM generates good code. Type specialization would help a lot. | |||
The main thing that needs to get faster here (other than type specialization) is object allocation, initialization, and GC. | |||
See also [https://bugzilla.mozilla.org/show_bug.cgi?id=642002 bug 642002]. | |||
== v8-regexp == | == v8-regexp == | ||
| Line 15: | Line 53: | ||
== v8-richards == | == v8-richards == | ||
This is a simulation of an OS process scheduler. | |||
The main things that need to be fast here are method calls, property lookups, and equality comparisons. | |||
See also [https://bugzilla.mozilla.org/show_bug.cgi?id=643639 bug 643639]. | |||
== v8-splay == | == v8-splay == | ||
This does a bunch of junk with splay trees. | |||
It is mostly a GC benchmark, with fairly short-lived objects. It also needs fast allocation. | |||
See also [https://bugzilla.mozilla.org/show_bug.cgi?id=643643 bug 643643]. | |||
Latest revision as of 18:50, 23 March 2011
This info is for v8-v5.
v8-crypto
Almost all the time is spent in the function am3(), which is an integer arithmetic kernel that operates on arrays.
JM generates good code for am3().
Type specialization (Crankshaft/TI) is expected to give a big perf boost here.
See also bug 643565.
v8-deltablue
The benchmark builds a system of constraints and runs a solver. The constraints are represented by object-oriented data structures with several levels of wrapping. The bottom level is 'function OrderedCollection', which wraps a JS array.
Because of the many small functions that wrap each other in Java-esque style, this benchmark benefits strongly from fast method calls (o.f()) and/or inlining.
This benchmark also creates many objects and arrays, so allocation speed is also important. GC mark/sweep speed is not critical, but matters somewhat.
The benchmark does a lot of |array.length|, equality comparisons, and Array.push/pop, so making those faster would also help.
See also bug 643615
v8-earley-boyer
This is a mostly-mechanical Scheme->JS translation of two programs: earley, which does parsing, and boyer, which is a constraint solver. It has functions named 'sc_Pair' (like cons), 'sc_list', 'sc_append', and so on; the three just given are the ones that account for the most time.
Being based on Scheme, this program creates a lot of small objects, so fast object allocation and generational GC are very important. Inlined constructors would also help.
sc_list and sc_append use |arguments|, but only locally, so making this faster by not creating an arguments object would help. Same goes for call objects in closures.
The extensive use of closures also generate a lot of CALLNAME ops, so those need to be fast.
There is a lot of tail recursion, and also general tail calls.
See also bug 642001.
v8-raytrace
This is an object-oriented raytracer. It does a lot of arithmetic, for which JM generates good code. Type specialization would help a lot.
The main thing that needs to get faster here (other than type specialization) is object allocation, initialization, and GC.
See also bug 642002.
v8-regexp
Description. Numerous kernels stuck together. A collection of regexp operations gathered from 50 popular websites, lightly modified, and run in succession.
Key features. Ninety-four different regexps are used in many calls to RegExp.exec() and String.replace(). The return values of these calls are never used.
Mozilla-specific things. We convert RegExp.exec() to RegExp.test() if the result isn't used, or is only tested for null (bug 581595). This speeds the test up by about 1.8x.
v8-richards
This is a simulation of an OS process scheduler.
The main things that need to be fast here are method calls, property lookups, and equality comparisons.
See also bug 643639.
v8-splay
This does a bunch of junk with splay trees.
It is mostly a GC benchmark, with fairly short-lived objects. It also needs fast allocation.
See also bug 643643.