Sunspider Info

From MozillaWiki
Jump to: navigation, search

This info is for Sunspider 0.9.1.

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.

crypto-sha1

date-format-tofte

date-format-xparb

math-cordic

math-partial-sums

math-spectral-norm

regexp-dna

string-base64

string-fasta

string-tagcloud

string-unpack-code

string-validate-input