FLAC is a cross-platform codec, but when it comes to Windows, one has a pretty wide range of compiles. Some are more optimized than others.

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:

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).

FLAC build benchmarks (time in seconds)
FLAC build Action canonical MSVC8 ICL9.1 x64
Lateralus encode 140.198 124.146 121.821 135.206
decode 36.770 17.098 16.708 18.315
Bruckner encode 115.331 104.708 107.984 121.119
decode 33.384 33.338 30.030 31.387
Californication encode 106.954 98.283 90.309 100.668
decode 26.973 25.972 25.943 27.238

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.

§3477 · December 21, 2008 · Tags: , , , , , ·

3 Comments to “FLAC compile benchmarks”

  1. Conor says:

    Fascinating post. Definitely will be recommending the RareWares build to friends on 64-bit Vista.

    I just ran a very sloppy test on my system by taking my FLAC rip off Californication and making it one file WAV, then splitting it up again. To WAV was just about 25 seconds, back to FLAC just over a minute. I’m using FLAC 1.2.1 64-bit from the Ubuntu repos. Is there something terribly methodologically challenged about that?

  2. Rudy says:

    Have you try using AMD processor? Because Intel is notoriously slower on 64 bit applications than 32 bit ones

  3. Rudy says:

    Flac benchmark - Someone Like You

    Someone Like You – Susan Wong

    Principle of Lust - Enigma

    Principle of Lust – Enigma

    As you can see, 64 bit is faster than everything else. Intel crippled their 64 bit performance, only because the official name of x86-64 is AMD64 instructions, as you can see the name on every 64 bit OSes. It’s their dirty business practice as usual. They think with this practice, people will see that 64 bit has no benefit at all, thus blaming on AMD.

Leave a Reply