A Modest Construct » Linux

Linux Command-Line Compressors Compared

Ben — Tue, 03 May 2011 13:22:31 +0000

A long time ago, I ran a comparison of various command-line compressors in Linux. Recently, intrigued by the rise of parallel computing and the emergence of multi-processor versions of old *nix favorites like gzip and bzip2, I thought I’d give the benchmark another go.

The Setup

My machine is an Intel Core 2 Quad Q6600 [2.4Ghz] on a Gigabyte GA-N680SLI-DQ6 (nVidia 680i), with 4GB of Corsair XMS2(PC2 6400). The tests were run on a vanilla installation of Ubuntu 10.10 x64, fully updated. The compressors themselves were compiled by me from source code, so I would have the latest and greatest at the time of testing.

I did not use a RAM disk, since I wanted all of my available RAM available for compression (some of the tests used aggressive settings). I did use a freshly-formatted SATA disk for the purpose, however. For further information, see the methodology and results.

Timing was done with the GNU time command.

The Compressors

gzip. Perhaps the most well-known compressor on Linux, gzip is a DEFLATE-based compressor which offers moderate compression at a very fast speed. Note: I made the mistake of retrieving the sources from www.gzip.org, which has links to v1.2.4, from 1999. The most recent stable version is 1.4, from GNU’s servers. The version reflected in the benchmark, therefore, is out of date.
bzip2. An old favorite, bzip2 is a basic block-level compressor which is more aggressive than its cousin, gzip, at the cost of speed.
xz. A relatively new compressor, xz arose from the ashes of LZMAUtils, an implementation of the LZMA compression spec from Igor Pavlov’s 7-zip project. xz is is the command-line equivalent, and similar in usage to gzip and bzip2; more to the point, it’s been accepted by the GNU toolchain and now has its own filter in tar (-J).
rzip. Originally written by Andrew Tridgell (of Samba fame, and who indirectly caused git, when you think about it) as a doctoral project. It functions similarly to gzip and bzip2, according to its author, but attempts to take advantage of “long-distance redundancies” in larger files; that is, where bzip2 may only process 900K chunks at a time, rzip will seek to look beyond that in order to eek out additional compression.
lzop. One of the Lempel-Ziv-Oberhumer (LZO) compressors, it focuses on decompression speed rather than pure compression.
compress. Though not really a contender in any real zip, I included the old compress program for comparative purposes. Compress is a fast LZW compressor which creates .Z files, and can be triggered as a filter in tar with -Z. The implementation used is ncompress.
zip. An old standby, zip creates, well, .zip files, using the DEFLATE algorithm. One difference between zip and gzip is that zip creates a structured archive (no tar necessary).
lzip. Another LZMA-based compressor, lzip is heavily-asynchronous, emphasizing small decompression times at the expensive of larger initial compression time.
p7zip. The *nix version of Igor Pavlov’s 7-Zip for Windows, p7zip has a slew of options (including different compressors, such as ppmd), but we’ll be focusing on lzma2.
pigz. A parallel implementation of gzip. Like most parallel implementations, pigz sacrifices a small amount of compression efficiency for large gains in speed.
lbzip2. A parallel implementation of bzip2.
pbzip2. Another parallel implementation of bzip2.
quicklz (qpress). A very fast implementation of LZO, the QuickLZ library was at version 1.5.0 at the time of the benchmark, but its companion compressor program, QPress, was linked against 1.4.1.
lxz. A parallel implementation of the xz compressor. By the same creator as lbzip2. It supports compression only, so the benchmark will not contain decompression numbers for this tool. The author considers it a stopgap until xz gets multithreading support.
lrzip. Long ago, a fork of rzip, Con Kolivas’ lrzip has become a full-fledged compressor with multiple possible algorithms to choose from; the only one tested was LZMA. Note that the version tested here (0.571) was replaced shortly after I ran my benchmarks by v0.600, which was a large rewrite ostensibly improving decompression speed.
plzip. A straightfoward parallelization of the lzip compressor.

A note on options.

Most of the compressors tested follow the same basic pattern for specifying compression strength, modeled after the options of gzip and bzip2. -# specifies compression strength, where # is a number. On some compressors, 0 is the lowest; on others, it’s 1. My approach was to test the lowest strength, the highest strength, and the default strength (either 5 or 6, depending).

On some multithreaded compressors, it was necessary to specify the number of threads or processors to use. Where this was required, I use a value of 4, the number of cores in my processor.

The Methodology

Corpus. I downloaded the 11/3/2009 pages-articles.xml.bz2 from Wikipedia’s mirror an uncompressed it. 23+ GB. Uh oh. Realizing that I didn’t have all the time in the world to spend compressing things, I truncated the file to its first 1’073’741’824 bytes (1GB) using the truncate command.

For each compressor/setting, the compression was run three times; the compressed size was recorded; then the decompression was run three times. Each run’s time was recorded, and the average and standard deviation was calculated for both compression and decompression.

Note that in some cases, operation speed was limited by the speed of the hard drive (I’ll cover this in detail in the next section); there isn’t much to be done about this, other than the note it. Multiple runs should tease out inconsistencies and show where there is a real discrepancy as opposed to a consistent bottleneck.

The Results

The data table itself is far too large to fit in this template, but you can see it as Google Spreadsheet here.

There’s no way to crown a clear winner, since all compressors mean tradeoffs. If I were as smart and capable as Werner Bergman, I could have a formula worked up for compressor efficiency, but I’m more curious to see the differences between single-threaded compressors and their multithreaded variants.

To get it out of the way: xz at maximum compression had the best compression ratio of all tested configurations. At 243’350’864 bytes, it shrank the test corpus to 22.7% of its original size. This came at a heavy cost, though, as compression at this level took an average of 27 minutes, give or take 200 seconds.

The fastest compression, by far, came from QuickLZ, whose lowest setting managed to process the entire 1GB file in an average of 6.3 seconds. Its maximum setting doubled the time to 12 seconds and shaved off an additional 75MB, but the price of such fantastic speed is much less compression: the maximum setting reduced our test corpus to only 44.4% of its original size.

Remember that there is no best compressor; there is only a compressor that is best for your needs. Compression is all about diminishing returns: it takes a mere 12 seconds to get from 100% to 44% with QuickLZ. It takes an additional 27 minutes to get from 44% to 22% with xz.

When looking at the decompression times, one might notice that the scores bottom out at between 12-15 seconds. My guess is this does not reflect the decompression speed at much as the write speed of the hard drive. In theory, one might see even lower numbers with a RAMdisk, but in practice, decompression speeds which outpace storage write speeds are unlikely to be taken advantage of outside a benchmark scenario.

The numbers for bzip2 vary wildly, for reasons I haven’t figured out. I ran a second iteration of three tests for each setting and got similar numbers, so I stuck with my initial measurements. Other compressors don’t have such high standard deviations relative to their runtimes, so I don’t think it was a problem with my setup.

Generally speaking, the parallel implementations of single-threaded compressors fare extremely well. Let’s look at the average times for some of the standard ones. Note that compression ratios are given as the percentage of the original filesize, not the percent reduction, so lower is better.

bzip2
Compressor	Compression Time (s)	Compression Ratio	Decompression Time (s)
bzip2 (min)	186.509	31.59%	63.342
lbzip2 (min)	38.852	31.63%	18.520
pbzip2 (min)	38.072	31.61%	13.533
bzip2 (default)	169.474	28.14%	64.432
lbzip2 (default)	42.085	28.15%	19.140
pbzip2 (default)	40.698	28.33%	14.630
bzip2 (max)	206.307	27.18%	66.460
lbzip2 (max)	52.091	27.19%	23.092
pbzip2 (max)	52.438	27.19%	20.617

gzip
Compressor	Compression Time (s)	Compression Ratio	Decompression Time (s)
gzip (min)	36.146	40.09%	19.195
pigz (min)	8.892	40.06%	12.199
gzip (default)	82.452	34.65%	16.912
pigz (default)	16.673	34.69%	12.852
gzip (max)	134.889	34.24%	16.513
pigz (max)	25.051	34.28%	12.129

xz
Compressor	Compression Time (s)	Compression Ratio	Decompression Time (s)
xz (min)	138.272	33.82%	50.916
lxz (min)	29.890	33.80%
xz (default)	1164.772	24.45%	34.114
lxz (default)	39.997	24.96%
xz (max)	1643.367	22.66%	31.968
lxz (max)	699.268	23.07%

As you can see, most parallel implementations decrease compression and decompression times by a factor of between 3 and 5, while taking, at most, a few tenths of a percent increase in final file size.

GNOME Audio Player Shootout v3.0

Ben — Sun, 29 Aug 2010 17:08:05 +0000

In January 2007 I published the GNOME Audio Player Shootout, a simple comparison of the options available to GNOME users for handling their day-to-day playback needs. It proved to be so popular that in December of 2008 I did a followup, excluding some abandoned players and adding some new ones. Though it hasn’t been quite two years yet, I thought it was time for another look at the state of audio players in the GNOME ecosystem.

This time around, I’ve got a heavy focus on new players, as there have been a number of new arrivals since my last shootout that show a lot of promise. This article will cover (in no particular order):

Rhythmbox (0.12.8)
Exaile (3.2.0)
Banshee (1.7.4)
Quod Libet (2.2.1)
Guayadeque (0.2.6-svn1186)
DeaDBeeF (0.4.1)
aTunes (2.0.1)
xnoise (0.1.10)
GMusicBrowser (1.1.5-git)
Aqualung (0.9~beta11)

All testing was done using an up-to-date Ubuntu Lucid x64 with all necessary repositories added, including some PPAs for the last versions of these players. Considered but not reviewed were Decibel Audio Player (hasn’t changed appreciably since last time), Gejengel (so unstable as to be unusable), and Bluemindo (still too simple to be useful).

Please note that this article necessarily incorporates some of my own biases. I am an avowed foobar2000 fan and you will notice that I tend to favor the utility-minded players over the media centers and iTunes clones. This article should still be useful, even if your own inclinations are different from mine.

Tracking LZMA efficiency

Ben — Tue, 10 Feb 2009 04:51:26 +0000

I’m a big fan of 7-Zip. It isn’t the best-looking application ever written, but that could be because its creator, Igor Pavlov, is concerned much more with its compression methods than its interface. 7-Zip has its own container format, but more important is the LZMA compression algorithm that Igor wrote and put into the public domain.

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

LZMA Efficiency
7-zip version	encoding time (s)	decoding time (s)
3.13	541.271	43.379
4.20	531.457	44.040
4.23	527.871	42.425
4.32	341.290	42.126
4.42	219.451	42.211
4.57	174.064	44.163
4.62	170.973	42.836
4.65	170.917	43.058
4.66 (lzma2)	126.259	46.663

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.

GNOME Audio Player Shootout Revisited

Ben — Fri, 19 Dec 2008 16:13:56 +0000

It’s been close to two years since I wrote GNOME Audio Player Shootout, a visual and textual comparison of some the best available audio players for the GNOME desktop.

As is usually the case in the world of free software, a lot has happened since then (and yet, in a strange way, things have stayed exactly the same). I decided to revisit some of those players and see how they’ve progressed. Some of them listed last time haven’t seen any appreciable development, and have been left off.

I realize that I am totally ignoring the daemon-based players (read: Music Player Daemon, XMMS2); this is by design, since those players open up a whole new can of worms. Suffice it to say that if you’ve decided on and XMMS2 or MPD-based player and successfully configured it, you probably don’t need any advice on choosing software.

The following programs will be covered in this review (development versions):

BMPx (0.40.14)
Rhythmbox (0.11.6)
Exaile (2.99.1-svn)
Banshee (1.4.1)
Quod Libet (2.0)
Decibel (1.00)
Songbird (1.0)
Listen (0.6~svn1044)

All of the testing was done on a fresh install (and update) of Ubuntu 8.10 in VirtualBox, using a small representative sample of my music collection (some modern, some classical, in Vorbis, MP3, and FLAC).

In defense of open models

Ben — Wed, 22 Oct 2008 20:50:54 +0000

Andrew Keen has no idea how open models work.

In his latest article, he pontificates that the recent economic downturn is a death knell for community-supported or community-built programs/sites/&c.

So how will today’s brutal economic climate change the Web 2.0 “free” economy? It will result in the rise of online media businesses that reward their contributors with cash; it will mean the success of Knol over Wikipedia, Mahalo over Google, TheAtlantic.com over the HuffingtonPost.com, iTunes over MySpace, Hulu over YouTube Inc., Playboy.com over Voyeurweb.com, TechCrunch over the blogosphere, CNN’s professional journalism over CNN’s iReporter citizen-journalism… The hungry and cold unemployed masses aren’t going to continue giving away their intellectual labor on the Internet in the speculative hope that they might get some “back end” revenue. “Free” doesn’t fill anyone’s belly; it doesn’t warm anyone up.

There are really two broad fallacies that need addressing here. The first is Keen’s use of the word “open source,” which here is a misnomer. He never mentions Linux, Apache, or other open source programs which always have and will continue to have a dedicated base of programmers, most of whom work on it in their spare time, without any remuneration except personal pride and the esteem of their peers. It need hardly be noted that an economic downtown is likely to increase interest in open-source software, as it likely reduces operating costs for businesses.

No, what Keen means when he says “open source” is free-as-in-beer services, often serving liberally-licensed content; Wikipedia’s content is not open source (there’s no source to open), but it is available under the GNU Free Documentation License, which is something like a liberal Creative Commons license. Perhaps Keen has a sheet of words vaguely associated with Web 2.0 and just likes to throw them around in case his readers are too stupid to know better.

But then comes the bigger fallacy—i.e. in an economic depression, the things that motivated people to contribute to social sites and content servers will vanish entirely. Nevermind the fact that most of these services don’t necessarily imply the forfeiture of copyright; or that many already include ways to monetize one’s content. No, Keen fundamentally misunderstands why people contribute to things like Wikipedia. This isn’t a recent phenomenon borne on the largess of the Web 2.0 bubble; people didn’t start contributing to Wikipedia simply because they were so rich from their day jobs that they felt like giving something back. No, people like being a part of something. They like attaching their name to good work, free or not.

This is all a very roundabout way of saying that Keen couldn’t be more wrong; he apparently is crass enough to believe that anything one does can and should be tied to monetary compensation. I imagine he gets paid for his articles for Internet Evolution (if he was doing them pro bono, it would certainly speak volumes about his argument); perhaps he overestimates the value of his labor.

Desktop Linux revisited

Ben — Fri, 20 Jun 2008 21:15:49 +0000

About 2 years ago I wrote a piece called Five things that Desktop Linux really needs, attempting to air out my five biggest grievances with Desktop Linux. If you follow FOSS news, every year is heralded as “The Year of the Linux Desktop,” although such a thing clearly hasn’t happened yet. Now, two years later, I thought it would be interesting to revisit those five problems and see what kind of progress has been made in two years.

Linux needs a good CD ripper

When I last wrote, the favorite CD ripper for the GNOME environment was grip, which had the benefit of being extremely customizable, even if its ripping was plain-Jane cdparanoia. Grip is still used, I imagine, but the default ripper with the GNOME desktop is Sound Juicer, which is a gstreamer-based ripper/encoder that abstracts everything quite heavily and gives damn few options.

The good news is that the semi-abandoned cdparanoia project at least saw a maintenance release that fixed some bugs; the bad news is that the promised further revisions have failed to materialize, meaning that there’s still no compelling cd ripper available for Linux. The Exact Audio Copys and the dBpoweramps remain Windows-only tools.

Also in these past two years, however, a new ripper has emerged: RubyRipper, a Ruby/GTK2 program that tries to emulate EAC’s approach to ripping; that is, it reads segments multiple times and compares them using Ruby’s checksum matcher. While there are some audiophiles at HydrogenAudio who insist that this isn’t a perfect approach to ripping (of course it isn’t), it’s still far more than any of the desktop-standard rippers can come up with. Ideally, it will eventually feature AccurateRip support, though this is tentative.

So, I’m happy to report that some progress has been made in this area, though Linux is still a second-class citizen when it comes to CD ripping.

Linux needs good and consistent font rendering

You wouldn’t think it, compared to issues like multimedia codecs, but font rendering is awash in legal issues. Be it Apple’s patent for BCI (byte code interpreter) or Microsoft’s patent on TrueType (both of which are legally dubious), it’s legal threats and not technical problems that keep the default font smoother for most distros from producing nice, clean, antialiased fonts. The code already exists in the upstream source code for TrueType, but it’s disabled by default. Ubuntu finally made the decision to enable it by default in their distribution, for which I applaud them. Packages exist for many other distributions, which is still a damn sight better than the typical “compile it yourself” response, which always strikes me as utterly absurd.

In my previous post, I highlighted the discrepancy between various types of programs in Linux when it comes to font rendering. I can say without hesitation that the situation has improved since then, though I’m not entirely sure where the responsibility for the fixes lie.

What you see is my blog in Firefox 3.0, some source code in Netbeans 6.1, and the template picker in OpenOffice 2.4. Notice that the font rendering is pretty similar in all three of them. I can tell you that Netbeans looks that good because I’m running it with the Java 6 JDK, which finally added decent font antialiasing. Running it with Java 5 produces some pretty obnoxious font quality. As to OpenOffice, they either fixed font rendering on their end, or else OpenOffice benefits from the larger system font smoothing included in Ubuntu.

Linux needs better inter-distro compatibility and less dependence on repositories

My choice of Linux is Ubuntu; this decision is spurred largely by some æsthetic choices, and the truly orgasmic package management system. If it were not for this, I might very well be running OpenSUSE, which has greatly improved its package management with v11.0. One of OpenSUSE’s more compelling features is that they’re more willing (and the community is more willing) to add new software to the repositories. It’s significantly easier for me to get the latest and greatest software for openSUSE, often by dint of either Pacman’s wonderful repository or the openSUSE build service, which Ubuntu has responded to with the Personal Package Archive (read: build service).

The one benefit of the Ubuntu’s approach is that packages tend to play nicely with each other, whereas with openSUSE and it’s build service, there are sometimes overlapping dependencies.

But there are still a bunch of different package types and packages managers; even among package types, there are incompatible versions. And because of the shared nature of Linux libraries, each distribution’s release will likely have a narrow slice of software versions that will work for that particular library. Say what you will about the Windows approach, but when I install the latest FileZilla on Windows, I don’t get bitched at by my system for needing newer wxWidgets libraries (and therefore necessitating that I either compile my own version or wait 6 month until somebody does it for me). Similarly, installing new graphics drivers doesn’t mean I have to also set up the latest kernel headers and reconfiguring my display configuration file so that it doesn’t fail spectacularly when I reboot.

Initiatives like LSB, FreeDesktop, and PackageKit have made bold steps to make Linux play well with itself. But there’s no middle ground with Linux: you either let distributions do all the work for you, and limit yourself to the particular software, and the particular versions, that they feel like offering you, or you can do everything yourself, compiling and installing your software manually.

Linux needs better multimedia

OK, multimedia on Linux still sucks, and it still sucks hard. Even providing that you’ve enabled extra (legally dubious) repositories for your installation and downloaded all of the plugins and codecs that are available to you (after, of course, you’ve decided to use either GStreamer or Xine as a video engine), you still have the unfortunate issues of video in Linux being slower and of an inferior quality to video on Windows. Is there a reason that rendering with Totem-GStreamer is blocky and awful, and rendering with The KMPlayer is picture-perfect? Even xine is far from perfect.

Then there’s the age-old problem of the X server and the graphics stack on Linux being shit to begin with. Compiz is great, and I’ve spent a fair amount of time watching my windows wobble and painting fire on my screen, but is there a reason that emulators perform so much worse in Linux? Is there a reason that I can’t switch tabs in Firefox with a several-second delay before the page contents are written to the screen? Is there a reason that the X server breaks at the slightest provocation? Is there a reason that the graphics stack offers so little to developers when compared to DirectX on Windows? Is there a reason that all the good-looking audio players on Linux can’t offer me anywhere near the same functionality that foobar2000 does on Windows?

I see individual programs making great progress, but there are fundamental flaws in the Linux approach to multimedia that aren’t going to be solved no matter how many widgets we give our apps. Multimedia on Linux still has a long way to go.

Linux needs disk image mounters

I’m pleased to report that since I last talked about this issue, there have been a couple of programs written to provide just this functionality. Programs like Daemon Tools or Alcohol 52% on Windows provide a way to mount virtual copies of CD or DVD images, allowing the computer to interact with them as though they were physical discs sitting in the drive.

On Gnome, there’s the Furius ISO Mount; on KDE, there’s AcetoneISO, which is also gaining burning support a la Alcohol 120%. Both of these programs function pretty much exactly how you would expect them to. Of the five issues I highlighted last time, this appears to be the most completely resolved; unfortunately, it was also the least important of the issues, and has gotten even less important to me personally since my previous writeup.

Conclusion

My biggest problem is that although the open source community continues to produce extremely compelling software, it suffers from the same fundamental flaws it did years ago: its X server and graphics layer are slow and difficult to work with, which is why you’ll find much better software emulators, games, and video playback on Windows than you will on Linux; its distro-centric repositories are both a boon to the end-user and a version lock-in that eliminates the “Go to the vendor site and download an .exe” ease of Windows. Linux is still a “Do It Yourself” operating system, meaning that despite all of the work being done, there’s not necessarily a complete and versatile environment for developers to program against. Certainly, there isn’t a consistent environment, and things are constantly changing in the world of Linux.

Fatuous criticisms of Linux

Ben — Fri, 04 Apr 2008 20:27:05 +0000

I love Jeff Atwood’s blog, and can even accept that he’s drank of the Microsoft Kool-Aid seemingly for both desktop and server because he’s a great writer and a great programmer.

But I admit to being troubled by his recent post. I might think it to be an April Fool’s Day joke, except the post is dated 31 March 2008. After quoting a couple of Linux upgrade horror stories from a software-engineer-turned-club-owner, he concludes:

I can’t fault Jamie’s approach. A clean install of an operating system on a new hard drive — for kiosks running controlled hardware, no less — that’s as good as it gets.

Apparently, Linux is so complex that even a world class software engineer can’t always get it to work.

I find it highly disturbing that a software engineer of Jamie’s caliber would give up on upgrading software. Jamie lives and breathes Linux. It is his platform of choice. If he throws in the towel on Linux upgrades, then what possible hope do us mere mortals have?

I see a couple of mistaken assumptions here. The first is that kiosks are a simple platform for Linux to work on. In fact, I have no idea what hardware is in these kiosks, and have no idea if there are proprietary hardware bits in them that aren’t supported well in Linux. The second poor assumption is that the only necessary step here is simply installing the new O/S. In fact, the engineer does a lot of custom configuration to his kiosks, and it may be that which is causing the crashiness; or, it could be bad hardware. I simply don’t have enough information to know.

Atwood places the blame squarely on Linux’s “complexity.” If Linux was that awful, or if Windows was that great, why hasn’t Jamie simply gotten the kiosks to run Windows? I don’t know for sure, but I’m guessing they might be just as crashy. And certainly more expensive.

Finally, as many commenters on Atwood’s entry have pointed out, a good software engineer != a good sysadmin. And using Fedora Core is not a good path to stability. And more importantly, that anecdotes from one guy, however smart, do not a comprehensive criticism make.

OpenOffice 2.4.0

Ben — Tue, 25 Mar 2008 19:13:58 +0000

After a number of delays, OpenOffice 2.4.0 has been officially released. Get it here. Check the mirrors for your own OS and localization. ~~OpenOffice 2.4.0 has not quite been released yet.~~ Some major new features include OpenGL transitions for Impress, some major charting improvements for Calc, and block selection for Writer.

Linux 2.6 filesystem benchmarks

Ben — Fri, 21 Mar 2008 21:30:33 +0000

A recent Linux filesystem benchmark, using modern filesystems, takes a look at some hard numbers. Looks like JFS usually comes in on top.

Common compression and corpuses

Ben — Sun, 20 Jan 2008 04:43:21 +0000

Every so often, I dink around with benchmarking common lossless compressors. One of the best sites for it is, I think, Werner Bergman’s Maximum Compression, which is a rather comprehensive running benchmark of just about every lossless compression benchmark under the sun. Really, there’s a lot. What you have to understand about the world of compressors is that they are very often academic projects or toys that very smart people play with in their free time. There are also companies (but not many) who invest in their own proprietary algorithms for lossless compression.

Here’s the catch, though: the quality of a compressor isn’t measured by its final compression ratio. The PAQ series of a compressors, for instance, offer great compression and really, truly awful compression times. The time goes with the highest compression levels of WinRK (a proprietary Win32 format with an accompanying GUI). But disk is cheap: nobody really cares about a fraction of a percentage of compression efficiency, do they? What people really want is for their (inevitable) archiving GUI to take less time doing what it does.

In this spirit, I have compiled not so much an exhaustive less of possible compression algorithms (I’ll leave that to Werner, who is very good at what he does), but rather a short list of the most common formats, tested on three different (relatively well-known) corpuses: the Calgary Corpus, the newer Canterbury Corpus, and Andrew Tridgell’s 1999 Large Corpus. The first of these two are corpuses used to test the very kind of academic project which I’ve avoided. I dislike using them because they are small in size, which means that there is significantly less opportunity for variations in compression formats to manifest themselves. In the interest of verifiability, however, I have used them. I also included Andrew Tridgell’s large corpus because it’s been my experience that small test corpuses tend to vary too much too to disk I/O latency and other vagaries of compression algorithms.

What will follow is a data table for each corpus, followed by some brief observations about each.

First, a note about the test environment:

Windows Vista x64
Intel Q6600 Quad-Core
4GB Corsair PC2 6400
Western Digital Caviar WD1600YS SATAII, 160GB (system drive)
Timer: Igor Pavlov’s timer.exe (times reported are “Process” times).

Next, a note about compressor versions

Compressor versions used
Compressor	Version	Source
tar	1.13	GnuWin32
gzip	1.3.12	GnuWin32
tar	1.0.4	GnuWin32
zip/unzip	2.32/5.52	GnuWin32
7z (32-bit)	4.57	7-Zip
rar	3.71	RarLabs

Now on to the benchmarks…

Calgary Corpus
Codec	Setting	Enc. Speed (s)	Dec. Speed (s)	Size (b)	Ratio
tar		0.000	0.000	3,265,536	1.000
gzip	fast	0.171	0.062	1,244,763	0.381
gzip		0.312	0.093	1,070,276	0.328
gzip	best	0.561	0.062	1,062,584	0.325
bzip2	fast	0.499	0.218	961,633	0.294
bzip2		0.514	0.202	891,321	0.273
bzip2	best	0.483	0.218	891,321	0.273
zip	-1	0.187	0.078	1,244,985	0.381
zip		0.358	0.078	1,070,495	0.328
zip	-9	0.516	0.046	1,062,803	0.325
7z	1	0.436	0.171	962,460	0.295
7z	6	1.996	0.140	856,273	0.262
7z	9	2.152	0.140	853,686	0.261
rar	m1	0.265	0.140	1,167,991	0.358
rar	m3	1.950	0.140	935,499	0.286
rar	m5	1.762	0.891	788,671	0.242

The Calgary Corpus dates back to the late 80s. It’s become the test to perform, but it may or may not adequately represent the standard compressor workload in 2008. You’ll notice that Winrar’s maximum setting produces the smallest archive, and more quickly than the neighboring 7-zip runs. Notice, too, that among the lowest values, there tends to be a sort of “bottoming-out” point at which the speed of the compressor’s process in CPU is limited by the speed of the disk.

Canterbury Corpus
Codec	Setting	Enc. Speed (s)	Dec. Speed (s)	Size (b)	Ratio
tar		0.000	0.000	2,821,120	1.000
gzip	fast	0.140	0.062	872,570	0.309
gzip		0.249	0.062	739,066	0.262
gzip	best	1.138	0.062	736,223	0.261
bzip2	fast	0.390	0.156	584,964	0.207
bzip2		0.514	0.171	570,856	0.202
bzip2	best	0.390	0.156	570,856	0.202
zip	-1	0.140	0.078	872,795	0.309
zip		0.343	0.062	739,286	0.262
zip	-9	1.170	0.062	736,443	0.261
7z	1	0.280	0.930	569,953	0.202
7z	6	1.950	0.124	487,919	0.172
7z	9	2.199	0.124	485,391	0.173
rar	m1	0.218	0.124	772,369	0.274
rar	m3	1.232	0.093	515,831	0.183
rar	m5	1.170	0.561	427,178	0.151

I’m still not entirely able to figure out the Canterbury Corpus; it’s ostensibly an “update” to the aging Calgary Corpus. One would think that having been created more than a decade after it’s predecessor, and with the express purpose of more accurately representing the compressor workload of 2001, it would at least be larger (hard disks and file sizes have increased in size since 1989, believe it or not), but in fact it’s not, which was somewhat of a disappointment to me, as I saw entirely the same trends as with the previous corpus. Is that an accurate determination of the algorithms in question? Maybe not—read on.

Large-Corpus
Codec	Setting	Enc. Speed (s)	Dec. Speed (s)	Size (b)	Ratio
tar		0.000	0.000	247,933,952	1.000
gzip	fast	7.347	2.698	65,782,177	0.265
gzip		13.072	3.151	53,870,968	0.217
gzip	best	21.855	2.449	53,536,722	0.216
bzip2	fast	40.591	9.360	52,791,871	0.213
bzip2		54.506	10.567	39,372,759	0.159
bzip2	best	54.228	10.935	39,372,759	0.159
zip	-1	6.349	2.208	65,782,411	0.265
zip		12.682	2.527	53,871,197	0.217
zip	-9	21.529	2.433	53,536,951	0.216
7z	1	19.578	6.608	47,343,400	0.191
7z	6	128.645	4.035	26,373,931	0.106
7z	9	172.677	3.712	24,722,887	0.100
rar	m1	9.016	4.446	48,939,730	0.197
rar	m3	125.128	3.868	31,916,951	0.129
rar	m5	138.435	23.852	29,200,310	0.118

Mostly interestingly in the Tridgell’s “large-corpus,” we finally see 7-Zip spring ahead of WinRAR in terms of pure compression ratio (and in speed, too, in some cases). I’m not an expert on compression, so I can’t tell you why certain efficiencies only manifest themselves over large datasets, but clearly 7-Zip wins in more modern cases where large data-sets (mostly text, if Tridgell’s description is accurate) are present.

Clearly, the LZMA algorithm (the heart of 7-Zip) is something to be proud of; not only is it GPL, but it often outperform the popular WinRAR in both pure compression and in efficiency as well. I’m a little surprised that the 7-Zip *nix port, p7zip, hasn’t gained more traction in Linux, but I suppose that old ways die hard. The cheapness of disk and bandwidth nowadays rather point to more transparent compression as the ideal rather than whatever archiving format has the best compression in terms of purely numeric results.

For those of you looking for a decent free arching program, check 7-Zip out; for those of you who lust after data tables of compression benchmarks, give Werner’s a look: it’ll satiate your desire for tabular results in ways you never thought possible.