The fastest computers working with a fully free boot firmware distribution are Intel GM45 laptops from 2008 like Lenovo X200 and R400. No newer Intel system can work without signed and nonfree firmware which probably cannot be replaced without a significant breakthrough in number theory. Some AMD systems are known to work without nonfree firmware with coreboot, up to K10 (with some hope of liberating newer systems, up to Richland and Kabini APUs), while no one provides a binary distribution of free boot firmware for them. Is a K10 desktop board from 2010 faster than GM45, making it a useful target for improving performance of systems running completely free software?

Let’s compare compilation time of bash, version 4.3. It should depend mostly on the CPU (using all of their cores) and memory.


In this article I name computers after their chipsets, since these are most important for support in boot firmware. I have these computers:

  • GM45 + ICH9: Lenovo R400 with Intel Core2 Duo P8400 CPU (two cores), 8 GiB DDR3 RAM
  • K10 + RS780: ASUS M4A78LT-M-LE board with AMD Athlon II X2 255 (two cores), 4 GiB DDR3 RAM
  • Richland (Family 15h model 10h) + Hudson: ASUS F2A85-M board with AMD A8-6600K APU (four cores), 16 GiB DDR3 RAM

The K10 system runs a proprietary BIOS (similar boards are supported in coreboot), while the two other boards use coreboot with custom hacks to not identify R400 as X200 and to use a Richland APU instead of Trinity on F2A85-M.

The GM45 and Richland systems run Debian Sid, while K10 runs Jessie. I have installed the needed dependency packages using aptitude build-dep bash. GCC identifies itself as gcc (Debian 4.9.2-10) 4.9.2 on all three systems.

Benchmark script


set -e -x

build=$(mktemp -d)
cp bash-4.3.tar.gz "$build"
cd "$build"
tar xf bash-4.3.tar.gz
cd bash-4.3
./configure -q
time make -s -j$(nproc)
make -s clean
time make -s -j$(nproc)

cd -
rm -rf "$build"

The package is built twice so some work is hopefully done before the CPU changes to the highest frequency.

I use a tmpfs for /tmp on all my computers, so the sources and built binaries are kept only in memory. This should avoid benchmarking the varied disks in my computers.



42.32user 2.76system 0:25.16elapsed 179%CPU (0avgtext+0avgdata 73808maxresident)k
496inputs+0outputs (5major+956964minor)pagefaults 0swaps
42.36user 2.72system 0:25.78elapsed 174%CPU (0avgtext+0avgdata 73868maxresident)k
0inputs+0outputs (0major+956294minor)pagefaults 0swaps


33.38user 1.84system 0:19.93elapsed 176%CPU (0avgtext+0avgdata 73408maxresident)k
0inputs+0outputs (0major+950564minor)pagefaults 0swaps
33.40user 1.86system 0:19.94elapsed 176%CPU (0avgtext+0avgdata 73376maxresident)k
0inputs+0outputs (0major+950164minor)pagefaults 0swaps


36.36user 2.69system 0:11.14elapsed 350%CPU (0avgtext+0avgdata 73768maxresident)k
0inputs+0outputs (0major+954845minor)pagefaults 0swaps
36.63user 2.84system 0:12.38elapsed 318%CPU (0avgtext+0avgdata 73800maxresident)k
0inputs+0outputs (0major+954075minor)pagefaults 0swaps

Compilation times of packages with well-written build systems strongly benefit from having more CPU cores, as shown by the Richland result: my quad core APU doesn’t use less user/system time than the dual core Athlon II. A K10 system with four or six cores would most probably get better results: the exact board that I have supports them, unlike the laptop limited to two cores.