Sunspider Info
This info is for Sunspider 0.9.1.
Contents
- 1 3d-cube
- 2 3d-morph
- 3 3d-raytrace
- 4 access-binary-trees
- 5 access-fannkuch
- 6 access-nbody
- 7 access-nsieve
- 8 bitops-3bit-bits-in-byte
- 9 bitops-bits-in-byte
- 10 bitops-bitwise-and
- 11 bitops-nsieve-bits
- 12 controlflow-recursive
- 13 crypto-aes
- 14 crypto-md5
- 15 crypto-sha1
- 16 date-format-tofte
- 17 date-format-xparb
- 18 math-cordic
- 19 math-partial-sums
- 20 math-spectral-norm
- 21 regexp-dna
- 22 string-base64
- 23 string-fasta
- 24 string-tagcloud
- 25 string-unpack-code
- 26 string-validate-input
3d-cube
3d-morph
3d-raytrace
access-binary-trees
access-fannkuch
access-nbody
access-nsieve
bitops-3bit-bits-in-byte
bitops-bits-in-byte
bitops-bitwise-and
Description. A microbenchmark. This is the whole program:
bitwiseAndValue = 4294967296;
for (var i = 0; i < 600000; i++)
bitwiseAndValue = bitwiseAndValue & i;
Note that after the first iteration, bitwiseAndValue is 0.
Key features. A single tight loop. One of the shortest-running Sunspider tests.
Mozilla-specific things. The tracer does really well, unsurprisingly.
bitops-nsieve-bits
controlflow-recursive
Description. A toy benchmark. Computes three values using three simple recursive mathematical functions (Fibonacci, Ackermann, Tak).
Key features. The benchmark's speed is almost entirely determined by how fast recursive function calls are.
crypto-aes
crypto-md5
Description. Either a small real application or a kernel, depending on your point of view. Computes the md5sum hash of a 15,825 char string.
Key features. Most of the action is in the big loop in core_md5() starting spanning lines 51--130. It calls many small functions, many of which call other small functions, and so on. The function safe_add() is called 64,480 times; it looks like this:
/*
* Add integers, wrapping at 2^32. This uses 16-bit operations internally
* to work around bugs in some JS interpreters.
*/
function safe_add(x, y)
{
var lsw = (x & 0xFFFF) + (y & 0xFFFF);
var msw = (x >> 16) + (y >> 16) + (lsw >> 16);
return (msw << 16) | (lsw & 0xFFFF);
}
Mozilla-specific things. Our time isn't very good, largely because of trace-compilation overhead. Almost 20,000 LIR instructions are generated for the big loop. Interval analysis (bug 575529) helps a lot, as it can determine that all the additions in safe_add() cannot overflow. This improves the generated code, but more importantly, it improves compile-time because adds-with-overflows require lots of stack stores (to keep the operand stack consistent should we exit); converting to unchecked adds allows *many* of these to be removed, which then faciliates lots of additional dead code elimination. The end result is that less than 4,000 LIR instructions remain alive by the end of compilation.
Nonetheless, the tracer actually generates really good code for this benchmark. Obviously, inlining all those calls to tiny functions is great. Indeed, if you make the input a lot bigger the trace-compiled version runs about 4x faster than the method-compiled version. So this benchmark should be traced.
