Previously, I’ve casually benchmarked the Javascript speeds of 64-bit browsers v. their 32-bit counterparts (here); more recently, I benchmarked a 64-bit compile of FLAC against several other 32-bit compiles of the same version (here).

This time, I decided to test various and sundry file compression utilities—more specifically, those which offer both 32- and 64-bit versions of themselves. This benchmark did not exhaustively test all potential combinations of compression options (if you’re interested in that, see Werner Bergman’s excellent Maximum Compression and Matt Mahoney’s Data Compression Programs), nor will it compare various compressors to each other; neither will it even list how well the programs actually compressed, since that’s not really a consideration here. The sole purpose of the benchmark was to compare the execution time of a 32-bit program with its 64-bit version.

The corpus in this case was enwiki9, compressed to a RAM disk to minimize the potential effects of write latency. I wanted the corpus to be sufficiently large to better tease out significant differences in these compressors over a large dataset.

The results for each compressor are listed on their own page, as well as an explanation of the compressor, its origin, and any additional notes. One notable exception to this list is WinRK, which is available in a 64-bit version but contains no command-line interface.

What’s come up since the last time I did any sort of Javascript performance comparison? Well, Google Chrome and its JS engine (“V8″), for one. Also, something of a new era in Javascript handling that attempts to optimize how browsers handle it by converting it to bytecode (or, in the case of JavaScriptCore/Squirrelfish Extreme/Nitro, directly to native machine code). In addition, there’s been some new benchmarks arrive on the scene, which allows us to tease out bias from any particular one.

It’s amazing, really, to compare these numbers against the linked benchmark from a mere 1.5 years ago. Opera went from being the top of the heap with 9.5 to being a lazy 3rd or 4th place. And Chrome, of course, decimated the competition (so far). Read on for the testing methodology and the results.

The tests

I chose four different benchmarks, three of which are entirely Javascript and one of which is mostly Javascript.

1. Dromaeo is a large, comprehensive benchmark that optionally incorporates some of the other benchmarks we’re looking at today. It was created by the Mozilla Corporation. It offers several test suites, but the one used here was the Dromaeo subset of tests
2. SunSpider is a benchmark created by the folks behind WebKit. It quickly became and remains one of the most popular and venerated Javascript benchmarks available.
3. V8 Benchmark is a benchmark application designed by Google to test its V8 Javascript engine. It’s actually a very short and simple benchmark that fantastically favors Google’s browser (and Safari).
4. Peacekeeper is a new browser benchmark by FutureMark. It’s supposed to test not just Javascript performance, but some rendering performance as well. As you will notice below, the numbers seem a little funny, as it appears to favor Safari (WebKit + Nitro) by a significant margin

The Hardware

All tests were run in Safe Mode (where applicable; meaning that no additional plugins or widgets were loaded) on the following hardware:

• Intel Core2 Quad @ 2.4GHz
• 4GB RAM
• Windows 7 build 7229, x64 Ultimate Edition

The Data

What follows is the raw data table. Jump down for the summary.

The Conclusion

So what does this data tell us?

For starters, it means that the much-vaunted but long-developed Tracemonkey javascript engine in Firefox 3.5 is already a distant third-place player, if not fourth-place. Chrome’s V8 engine outperforms it by no less than a factor of 2 on just about every test. In fact, Chrome 3 on Windows 7 is the fastest browser available, period. Now, Chrome is a very simplistic browser (not even a print preview) and it remains to be seen if its competitive edge in terms of rendering and javascript speed will hold true when it’s got other things to worry about (i.e. plugins).

Safari 4 is a combination of the WebKit rendering engine (like Chrome) and JavaScriptCore, which is the umbrella project name for WebKit javascript engine. While the SquirrelFish engine in Safari 3.1 was fast (doing the JIT bytecode compiling that Firefox 3.5 is doing now…), the new SquirrelFish Extreme engine actually compiles to native machine code. It pulls respectable performance across all tests, usually ranking just behind Chrome…. with the notable exception of the Peacekeeper benchmark, where it takes the lead score. Unfortunately for Safari, its greatest accomplish with version 4 is only managing to not look completely horrible on other platforms, so needless to say it isn’t going to be a contender for the Win32 crown anytime soon.

How far Opera has fallen from grace. Whereas a couple of years ago it sported the fastest rendering, some of the greatest features, and a great javascript stack, it was quickly eclipsed by the flurry of development happening in other browsers recently. The beta of version 10.00 improves javascript performance significantly, although Opera’s own efforts toward bytecode-based javascript handling aren’t scheduled to land until well after 10.00.

Internet Explorer is, well, still Internet Explorer. While version 8 is a remarkable improvement over version 7, just as 7 was a spectacular improvement over 6, it is still the last shriveled pickle at the bottom of the jar, limping by in each and every benchmark. Microsoft, in their latest FUD to paint IE8 as a wunder-browser, correctly point out that javascript speed isn’t everything, but both benchmark and simple user testing are enough to point out that Microsoft’s browser team is working hard just to stay in the race; they’re not gaining ground at all.

I decided to do some quick and dirty benchmarks to track the progress of LZMA/7-Zip over time. I went back as far as Igor supplied binaries, including one from the very old 3.x series. Rather than test every single release between then and now, I used only “stable” releases, with the exception of version 4.65, which is the latest version of any sort, as well as 4.66, which uses an alpha version of Igor’s new LZMA2 codec (and, as you’ll see, provides definite performance improvement).

I used Igor’s Timer utility to time the process (global time was reported). The corpus in this case was the Linux kernel source, v2.6.28. I conducted these tests on a RAM disk to eliminate hard disk latency issues (especially for decompressions, which improved by about 25% from my initial HDD-based tests). My rig is a Intel Core 2 Quad Q6600 [2.4Ghz], with 4GB of RAM (one dedicated to the RAM disk), running Vista SP1 x64.

The command line setup was an approximation of the 7-Zip GUI’s “ultra” settings: -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on, letting the archiver auto-choose the number of threads to spawn.

The Data

The Analysis

Without conducting a more thorough battery of tests on a variety of different configurations, it’s difficulty to say with certain just where the performance improvements came from, be it better using of threading or multiprocessors, general algorithmic improvements, or something else. I also don’t know if the performance increases we see reside in improvements to LZMA itself as Igor was finalizing it, or just the code quality of 7-Zip, which implements LZMA.

In any case, the improvements since 3.13 are very clear (remember that lower is better), at least for compression, and for “ultra” settings. Decompression remained largely similar, which surprised me. Some of these results might be directly tied to the number and type of files that were compressed in the case: 4.66, for instance, improves decompression speed for uncompressable files, but no such files exist here since it’s source code.

Hats off to Igor Pavlov for his steady improvement on both a really great compression standard and one of my favorite pieces of software for Windows.

I first got the idea for this benchmark when I stumbled upon a native 64-bit FLAC executable for Windows. Curious, I did a quick and dirty test against the canonical build for Windows and found that while encoding times were similar, decoding times were considerably faster.

To figure out why this is so (the 64-bitness or something else), I quickly pulled some some additional compiles and benchmarked them against a few different samples.

I have three different samples I used, ripped in WAV format as single files:

• Lateralus, by Tool
• Californication, by the Red Hot Chili Peppers
• Bruckner’s 9th Symphony, by Giulini/Vienna Philharmonic, 1989

I’ve included a table for each sample, split into encode/decode times and compilation.

The builds I included were:

• The canonical build from the official FLAC website
• MSVC8 (Microsoft) compile from RareWares
• ICL 9.1 (Intel) compile from RareWares
• 64-bit compile (MSVC?) from HardwareHacks 2000

My test system is a Intel Core 2 Quad Q6600, with 4GB of RAM, running Windows Vista x64 SP1, with all available patches. The timer used was by Igor Pavlov (the developer of 7-zip). Reported times are global (as opposed to kernel, user, or process times).

It turns out that the x64′s advantage when it comes to decoding isn’t due to its 64-bitness, but probably because it includes some extra optimizations (SSE?) that are inherent ot a 64-bit compilation.

The clear winner in both encoding and decoding is the ICL9.1 compile (I wonder if a 10.1 compile would be even better); at least, it is so on my machine. The x64 compile was sometimes better, sometimes worse than the canonical compile. Clearly, there’s an early benefit from some optimization (probably SSE routines), along with a small margin of benefit from using Intel’s superior compiler. 64-bitness is beneficial for FLAC processes only insofar as it necessarily encompasses these routines as part of its instruction set.

If you’re looking to use a particular build of FLAC, I suggest you mosey on over to RareWares and john33′s ICL build: the resulting files are a few KB larger, but the processes itself is noticeably faster.

My hypothesis, before performing the tests, was that the 64-bit compilation would have little or no effect on the Javascript engine performance. It’s so difficult to optimize Javascript rendering, which is inherently single-threaded, and it seems likely to only benefit from a faster CPU clock than bigger memory registers. Afterward, I felt vindicated: Internet Explorer is likely the best test, and the difference was not statistically significant. In Firefox’s case, the 64-bit build was actually significantly worse, though this could easily be due to some other factor I have not taken into account; I have assumed that the source was compiled on the same date. See below for more details.

The Data Tables

The Raw Data

Internet Explorer x86 7.0.6001.18000
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  21972.4ms +/- 6.2%
--------------------------------------------

  3d:                    1233.0ms +/- 1.1%
    cube:                 346.6ms +/- 4.7%
    morph:                415.2ms +/- 2.7%
    raytrace:             471.2ms +/- 1.9%

  access:                1834.6ms +/- 2.5%
    binary-trees:         443.0ms +/- 3.9%
    fannkuch:             739.4ms +/- 1.5%
    nbody:                346.4ms +/- 7.3%
    nsieve:               305.8ms +/- 5.8%

  bitops:                1610.0ms +/- 3.7%
    3bit-bits-in-byte:    409.0ms +/- 2.0%
    bits-in-byte:         405.4ms +/- 4.8%
    bitwise-and:          446.2ms +/- 5.0%
    nsieve-bits:          349.4ms +/- 6.3%

  controlflow:            493.0ms +/- 2.2%
    recursive:            493.0ms +/- 2.2%

  crypto:                1051.4ms +/- 4.6%
    aes:                  374.2ms +/- 5.2%
    md5:                  330.8ms +/- 4.9%
    sha1:                 346.4ms +/- 6.2%

  date:                   873.6ms +/- 2.3%
    format-tofte:         433.6ms +/- 2.0%
    format-xparb:         440.0ms +/- 3.7%

  math:                  1186.0ms +/- 1.6%
    cordic:               465.0ms +/- 4.6%
    partial-sums:         327.6ms +/- 0.2%
    spectral-norm:        393.4ms +/- 4.1%

  regexp:                 387.0ms +/- 4.2%
    dna:                  387.0ms +/- 4.2%

  string:               13303.8ms +/- 10.4%
    base64:              7298.0ms +/- 6.8%
    fasta:                464.6ms +/- 3.5%
    tagcloud:            1391.4ms +/- 4.0%
    unpack-code:          461.8ms +/- 3.7%
    validate-input:      3688.0ms +/- 25.4%

Internet Explorer x64
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  19955.4ms +/- 1.2%
--------------------------------------------

  3d:                     938.6ms +/- 2.3%
    cube:                 262.0ms +/- 6.2%
    morph:                311.8ms +/- 6.3%
    raytrace:             364.8ms +/- 2.9%

  access:                1450.6ms +/- 2.8%
    binary-trees:         321.2ms +/- 3.3%
    fannkuch:             586.6ms +/- 3.7%
    nbody:                258.6ms +/- 6.6%
    nsieve:               284.2ms +/- 3.1%

  bitops:                1154.0ms +/- 1.7%
    3bit-bits-in-byte:    290.0ms +/- 3.7%
    bits-in-byte:         290.0ms +/- 7.6%
    bitwise-and:          284.0ms +/- 5.8%
    nsieve-bits:          290.0ms +/- 6.0%

  controlflow:            349.4ms +/- 3.0%
    recursive:            349.4ms +/- 3.0%

  crypto:                 786.2ms +/- 2.8%
    aes:                  296.4ms +/- 4.6%
    md5:                  243.2ms +/- 7.1%
    sha1:                 246.6ms +/- 10.3%

  date:                   664.6ms +/- 6.0%
    format-tofte:         315.0ms +/- 11.6%
    format-xparb:         349.6ms +/- 3.1%

  math:                   845.6ms +/- 2.5%
    cordic:               340.0ms +/- 2.5%
    partial-sums:         228.0ms +/- 4.5%
    spectral-norm:        277.6ms +/- 6.0%

  regexp:                 302.6ms +/- 3.5%
    dna:                  302.6ms +/- 3.5%

  string:               13463.8ms +/- 1.4%
    base64:              8527.2ms +/- 0.9%
    fasta:                334.2ms +/- 5.2%
    tagcloud:            1145.0ms +/- 2.6%
    unpack-code:          346.6ms +/- 6.2%
    validate-input:      3110.8ms +/- 2.4%

Firefox x86 Firefox 3.0b5pre (20080322 nightly)
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                 3750.2ms +/- 1.4%
--------------------------------------------

  3d:                   432.8ms +/- 9.8%
    cube:               147.2ms +/- 17.4%
    morph:              137.8ms +/- 1.2%
    raytrace:           147.8ms +/- 22.7%

  access:               598.8ms +/- 2.1%
    binary-trees:        60.6ms +/- 5.5%
    fannkuch:           261.6ms +/- 1.7%
    nbody:              173.2ms +/- 6.0%
    nsieve:             103.4ms +/- 1.4%

  bitops:               493.6ms +/- 5.4%
    3bit-bits-in-byte:   85.6ms +/- 2.2%
    bits-in-byte:       123.0ms +/- 6.4%
    bitwise-and:        136.4ms +/- 11.9%
    nsieve-bits:        148.6ms +/- 9.2%

  controlflow:           57.0ms +/- 3.1%
    recursive:           57.0ms +/- 3.1%

  crypto:               271.4ms +/- 7.3%
    aes:                105.0ms +/- 19.4%
    md5:                 78.4ms +/- 3.8%
    sha1:                88.0ms +/- 2.0%

  date:                 331.4ms +/- 12.3%
    format-tofte:       202.2ms +/- 16.2%
    format-xparb:       129.2ms +/- 8.3%

  math:                 432.2ms +/- 3.9%
    cordic:             186.2ms +/- 7.6%
    partial-sums:       149.2ms +/- 7.0%
    spectral-norm:       96.8ms +/- 1.4%

  regexp:               255.6ms +/- 8.3%
    dna:                255.6ms +/- 8.3%

  string:               877.4ms +/- 4.7%
    base64:             119.2ms +/- 6.0%
    fasta:              205.2ms +/- 10.4%
    tagcloud:           152.2ms +/- 6.2%
    unpack-code:        272.8ms +/- 4.1%
    validate-input:     128.0ms +/- 10.3%

Firefox x64
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  7421.4ms +/- 1.2%
--------------------------------------------

  3d:                    807.8ms +/- 2.0%
    cube:                312.6ms +/- 3.5%
    morph:               230.8ms +/- 7.8%
    raytrace:            264.4ms +/- 6.5%

  access:               1135.0ms +/- 1.9%
    binary-trees:        126.6ms +/- 11.7%
    fannkuch:            540.6ms +/- 2.3%
    nbody:               282.8ms +/- 2.9%
    nsieve:              185.0ms +/- 10.4%

  bitops:               1040.8ms +/- 2.3%
    3bit-bits-in-byte:   213.6ms +/- 5.8%
    bits-in-byte:        271.0ms +/- 4.5%
    bitwise-and:         246.2ms +/- 6.8%
    nsieve-bits:         310.0ms +/- 6.1%

  controlflow:           140.8ms +/- 6.6%
    recursive:           140.8ms +/- 6.6%

  crypto:                533.8ms +/- 4.3%
    aes:                 195.0ms +/- 5.8%
    md5:                 175.2ms +/- 11.5%
    sha1:                163.6ms +/- 3.5%

  date:                  664.6ms +/- 4.5%
    format-tofte:        406.4ms +/- 4.6%
    format-xparb:        258.2ms +/- 6.3%

  math:                  818.8ms +/- 3.8%
    cordic:              367.4ms +/- 3.2%
    partial-sums:        257.2ms +/- 10.5%
    spectral-norm:       194.2ms +/- 4.9%

  regexp:                652.8ms +/- 2.7%
    dna:                 652.8ms +/- 2.7%

  string:               1627.0ms +/- 3.1%
    base64:              220.6ms +/- 4.7%
    fasta:               388.8ms +/- 4.4%
    tagcloud:            294.8ms +/- 5.2%
    unpack-code:         489.4ms +/- 2.9%
    validate-input:      233.4ms +/- 11.1%

Continuing the tradition of my previous post about Safari, I thought I would revisit Firefox’s performance on the SunSpider benchmark.

Clearly, Firefox has also made drastic strides in its Javascript engine, which is an entirely new piece donated by Adobe (and is the same engine, or so I understand, which powers the Actionscript interpreter of Flash). These results put the new Firefox 3 beta at four times the speed of the latest 2.x series. The newly released Safari/Webkit build narrowly outperforms the latest test build of Firefox, but clearly there’s a lot of progress being made (and perhaps more before its final release).

The tests were done on a Windows XP SP2 machine; it has a Pentium 4 and 2GB of RAM.

Firefox 2.0.0.12
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                 23493.8ms +/- 6.3%
--------------------------------------------

  3d:                   2865.8ms +/- 1.3%
    cube:                812.6ms +/- 3.0%
    morph:              1562.2ms +/- 2.0%
    raytrace:            491.0ms +/- 4.5%

  access:               1874.4ms +/- 3.0%
    binary-trees:        243.6ms +/- 14.6%
    fannkuch:            571.8ms +/- 1.8%
    nbody:               721.6ms +/- 2.2%
    nsieve:              337.4ms +/- 3.2%

  bitops:               4709.2ms +/- 1.3%
    3bit-bits-in-byte:   362.4ms +/- 7.0%
    bits-in-byte:        381.2ms +/- 2.8%
    bitwise-and:        3406.2ms +/- 0.9%
    nsieve-bits:         559.4ms +/- 1.5%

  controlflow:           153.2ms +/- 13.9%
    recursive:           153.2ms +/- 13.9%

  crypto:               1150.0ms +/- 2.8%
    aes:                 356.2ms +/- 6.0%
    md5:                 393.8ms +/- 5.3%
    sha1:                400.0ms +/- 5.5%

  date:                 4769.0ms +/- 0.9%
    format-tofte:       1294.0ms +/- 1.3%
    format-xparb:       3475.0ms +/- 1.0%

  math:                 1868.8ms +/- 3.0%
    cordic:              940.8ms +/- 4.8%
    partial-sums:        546.6ms +/- 2.4%
    spectral-norm:       381.4ms +/- 8.5%

  regexp:               1400.4ms +/- 81.1%
    dna:                1400.4ms +/- 81.1%

  string:               4703.0ms +/- 9.4%
    base64:              928.2ms +/- 2.3%
    fasta:               640.8ms +/- 3.1%
    tagcloud:           1025.0ms +/- 46.6%
    unpack-code:        1512.2ms +/- 10.5%
    validate-input:      596.8ms +/- 6.7%

Firefox 3.0b4
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  6102.8ms +/- 2.3%
--------------------------------------------

  3d:                    842.0ms +/- 4.8%
    cube:                301.0ms +/- 5.3%
    morph:               245.8ms +/- 1.7%
    raytrace:            295.2ms +/- 10.5%

  access:                910.4ms +/- 2.9%
    binary-trees:         95.6ms +/- 2.4%
    fannkuch:            412.2ms +/- 5.6%
    nbody:               282.2ms +/- 3.2%
    nsieve:              120.4ms +/- 8.5%

  bitops:                782.2ms +/- 5.8%
    3bit-bits-in-byte:   120.4ms +/- 22.1%
    bits-in-byte:        143.0ms +/- 21.1%
    bitwise-and:         267.2ms +/- 4.3%
    nsieve-bits:         251.6ms +/- 3.1%

  controlflow:            89.0ms +/- 1.7%
    recursive:            89.0ms +/- 1.7%

  crypto:                500.8ms +/- 5.5%
    aes:                 148.8ms +/- 17.2%
    md5:                 171.4ms +/- 2.0%
    sha1:                180.6ms +/- 1.9%

  date:                  560.0ms +/- 4.2%
    format-tofte:        329.6ms +/- 6.8%
    format-xparb:        230.4ms +/- 2.1%

  math:                  815.2ms +/- 5.5%
    cordic:              321.0ms +/- 1.1%
    partial-sums:        310.4ms +/- 9.2%
    spectral-norm:       183.8ms +/- 16.1%

  regexp:                295.6ms +/- 6.4%
    dna:                 295.6ms +/- 6.4%

  string:               1307.6ms +/- 3.7%
    base64:              157.8ms +/- 16.5%
    fasta:               280.0ms +/- 9.8%
    tagcloud:            249.6ms +/- 3.9%
    unpack-code:         412.2ms +/- 7.9%
    validate-input:      208.0ms +/- 4.5%

Safari 3.1 has been released, bringing with it all the latest and great Webkit code. Even though the UI still sucks (at least on Windows; ever hear of native GUIs, Apple?)

I decided to benchmark the Javascript performance of the new Safari against its more immediate predecessor, 3.04. This testing was done on a Windows XP SP2 installation; a HP workstation with a Pentium 4 and 2GB of RAM.

As you can see in the table below, the JS engine has improved considerably since the last build, cutting the total time by more than half.

Here’s the raw data, if you so desire it.

Safari 3.04

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                 13525.2ms +/- 0.6%
--------------------------------------------

  3d:                   1834.4ms +/- 4.8%
    cube:                478.0ms +/- 5.5%
    morph:               818.6ms +/- 8.8%
    raytrace:            537.8ms +/- 6.1%

  access:               2355.8ms +/- 2.1%
    binary-trees:        212.6ms +/- 17.9%
    fannkuch:            977.8ms +/- 1.1%
    nbody:               581.4ms +/- 4.4%
    nsieve:              584.0ms +/- 6.0%

  bitops:               2322.2ms +/- 2.4%
    3bit-bits-in-byte:   515.8ms +/- 2.7%
    bits-in-byte:        537.4ms +/- 5.4%
    bitwise-and:         450.0ms +/- 7.1%
    nsieve-bits:         819.0ms +/- 3.1%

  controlflow:           315.2ms +/- 12.5%
    recursive:           315.2ms +/- 12.5%

  crypto:               1331.2ms +/- 2.2%
    aes:                 337.6ms +/- 8.8%
    md5:                 475.0ms +/- 6.3%
    sha1:                518.6ms +/- 3.2%

  date:                 1062.6ms +/- 5.1%
    format-tofte:        390.6ms +/- 7.0%
    format-xparb:        672.0ms +/- 5.4%

  math:                 1600.2ms +/- 3.3%
    cordic:              847.0ms +/- 3.0%
    partial-sums:        387.6ms +/- 4.2%
    spectral-norm:       365.6ms +/- 9.8%

  regexp:                531.2ms +/- 5.8%
    dna:                 531.2ms +/- 5.8%

  string:               2172.4ms +/- 3.1%
    base64:              453.2ms +/- 6.2%
    fasta:               628.2ms +/- 5.1%
    tagcloud:            340.8ms +/- 11.7%
    unpack-code:         312.6ms +/- 10.7%
    validate-input:      437.6ms +/- 5.4%

Safari 3.1
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  5865.4ms +/- 1.8%
--------------------------------------------

  3d:                    703.0ms +/- 11.3%
    cube:                218.6ms +/- 15.4%
    morph:               197.0ms +/- 22.7%
    raytrace:            287.4ms +/- 10.1%

  access:                943.8ms +/- 7.0%
    binary-trees:        106.4ms +/- 19.8%
    fannkuch:            446.8ms +/- 10.0%
    nbody:               256.4ms +/- 4.2%
    nsieve:              134.2ms +/- 12.8%

  bitops:                659.2ms +/- 4.4%
    3bit-bits-in-byte:   128.0ms +/- 6.5%
    bits-in-byte:        156.2ms +/- 15.3%
    bitwise-and:         212.4ms +/- 13.8%
    nsieve-bits:         162.6ms +/- 16.1%

  controlflow:           146.8ms +/- 17.9%
    recursive:           146.8ms +/- 17.9%

  crypto:                459.6ms +/- 11.7%
    aes:                 175.2ms +/- 21.4%
    md5:                 128.4ms +/- 16.3%
    sha1:                156.0ms +/- 15.1%

  date:                  678.2ms +/- 4.4%
    format-tofte:        262.6ms +/- 12.1%
    format-xparb:        415.6ms +/- 7.1%

  math:                  724.8ms +/- 7.0%
    cordic:              271.8ms +/- 10.7%
    partial-sums:        287.4ms +/- 9.0%
    spectral-norm:       165.6ms +/- 17.7%

  regexp:                334.6ms +/- 7.7%
    dna:                 334.6ms +/- 7.7%

  string:               1215.4ms +/- 4.5%
    base64:              190.4ms +/- 13.3%
    fasta:               290.6ms +/- 8.9%
    tagcloud:            203.2ms +/- 13.4%
    unpack-code:         234.2ms +/- 10.2%
    validate-input:      297.0ms +/- 9.1%