Kraken Info
This info is for Kraken 1.0.
ai-astar
A toy benchmark. A path-finding program that uses A* search.
Key features. The benchmark spends almost all of its time in the loop in the following function.
Array.prototype.findGraphNode = function(obj) {
for(var i=0;i<this.length;i++) {
if(this[i].pos == obj.pos) { return this[i]; }
}
return false;
};
Mozilla-specific things. The above loop is traced and accounts for roughly 95% of execution time.
audio-beat-detection
This is identical to audio-fft, except it has an insignificant amount of extra stuff at the end. Bug 603837 is open for this.
audio-dft
Description. A kernel. Computes a Discrete Fourier Transform.
Key features. Most of run-time is in this loop:
for ( var n = 0; n < buffer.length; n++ ) {
real += this.cosTable[k*n] * buffer[n];
imag += this.sinTable[k*n] * buffer[n];
}
buffer.length is 2048. Property and array gets dominate.
Mozilla-specific things. Execution is dominated by a single trace fragment.
audio-fft
Description. A kernel. Computes a Fast Fourier Transform.
Key features. A big chunk of run-time is in this loop:
while ( i < bufferSize ) {
off = i + halfSize;
tr = (currentPhaseShiftReal * real[off]) - (currentPhaseShiftImag * imag[off]);
ti = (currentPhaseShiftReal * imag[off]) + (currentPhaseShiftImag * real[off]);
real[off] = real[i] - tr;
imag[off] = imag[i] - ti;
real[i] += tr;
imag[i] += ti;
i += halfSize << 1;
}
Array gets and sets dominate.
Mozilla-specific things. In the above loop, 'i' and 'off' are loaded as doubles and have to be converted to integers using a combination of inline code and calls to js_DoubleToInt32(). This should be avoided (bug 606879).
audio-oscillator
imaging-gaussian-blur
Description. A kernel. The image (and representation thereof) from imaging-desaturate.js is reused. The program transforms the contents of the array.
Key features. The benchmark features a quadruply-nested loop. The inner loop is dominated by array gets and some highly repetitive array index computations, including numerous calls to Math.abs(). Array sets aren't very important as they only occur in the 2nd-most outer loop.
Similar to imaging-desaturate, this benchmark starts with the main array holding integers, but they quickly become doubles.
Mozilla-specific things. Nanojit's CSE pass commons up the repetitive index computations beautifully.
Using an integer-only version of Math.abs() is easy and makes things much faster (bug 606441).
Again, similar to imaging-desaturate, because the array-of-ints becomes an array-of-doubles, the tracer generates code assuming it's always an array-of-ints, and so the fragment for the inner loop frequently (about 50% of the time) side-exits to a secondary fragment.
All the integer overflow checks hurt. Removing them (unsafe in general, ok for this benchmark) makes it 1.27x faster.
The first three capacity checks on squidImageData[] are redundant w.r.t. the fourth. Removing those would help a little.
imaging-darkroom
imaging-desaturate
Description. A kernel. A 400 x 267 image is represented as an array where each pixel gets four consecutive elements, representing its R/G/B/Alpha values. All values are in the range 0..255. The program transforms the contents of the array.
Key features. Almost all the benchmark's time is spent in this loop:
while (p--)
data[pix-=4] = data[pix1=pix+1] = data[pix2=pix+2] = (data[pix]*0.3 + data[pix1]*0.59 + data[pix2]*0.11);
It iterates through each pixel, setting the R/G/B values all to the the same value, which is a function of the prior R/G/B values.
This desaturation loop is repeated 200 times. The first time the desaturation loop runs, the (R, G, B) values are converted from integers to doubles. The remaining 199 times, the values are doubles to begin with.
The program is kind of stupid for (a) not truncating the desaturated R/G/B values and (b) desaturating the image 200 times in a row. Indeed, the benchmarks admits as much for (b):
//XXX improve dataset rather than loop
for (var pixcounter = 0; pixcounter < 200; pixcounter++)
Pixastic.Actions.desaturate.process(params);
Bug 603841 is open to change this behaviour.
Mozilla-specific things. The trace code generated assumes the array elements are integers, because that's what is seen at record-time, but in the end 99.5% of the time it's not, so we end up taking a particular side-exit every time to a second trace fragment.
If bug 603841 isn't fixed, it would be good if we could somehow (using the oracle?) detect that the side-exit is hot and recompile the fragment.
json-parse-financial
json-stringify-tinderbox
A microbenchmark. Calls JSON.stringify() 1000 times on an object that takes up over 450,000 chars to express in a file.
Key features. The result of the call to JSON.stringify() is never used, so this benchmark is susceptible to gaming -- an implementation could detect that the result isn't used and call a faster version of JSON.stringify() that doesn't build the result (ie. an empty function). Bug 603838 is open for this.