Is FreeBSD faster than Linux?

Yes, FreeBSD is faster than Linux. Yet, Linux is faster than FreeBSD. So it depends on what you’re talking about. The TL;DR version is: FreeBSD has lower latency, and Linux has faster application speeds.

Yes, the TCP/IP stack of FreeBSD has far less latency than Linux. That’s why Netflix chooses to stream its movies and shows to you on FreeBSD and never Linux. It’s also why Netflix chooses to pay some of its best engineers to contribute to the current and future codebase of the FreeBSD kernel and not the Linux kernel. In general, many web applications feel “faster” on FreeBSD servers due to the better “response time” or latency.

But nearly all applications run faster on Linux than FreeBSD. IBM and Intel are the two largest benefactors to the Linux kernel, and they are very application (not networking) focused. Virtually every supercomputer runs on Linux for this very reason. If you are using *nix as a workstation rather than Windows or Mac, nearly everything you could run, except perhaps games, runs faster on Linux than FreeBSD.

These two statements (FreeBSD has lower latency; Linux has more raw power) have been true for two decades now. But they may change just a bit soon! There are some “BSD-inspired” networking improvements to Linux starting with the 4.16 kernel. Facebook has in fact employed engineers for the sole purpose of trying to get Linux up to speed with FreeBSD for the web, and some parts of 4.16 are the fruits of their labors.

But unless you’re using Fedora, your servers aren’t gonna taste it soon. Just by bad timing, the new Ubuntu LTS (18.04) due out next week will still use 4.15, which it will support for 5 years. Since CentOS and Debian are even further behind on kernels, you won’t see a lot of “fast Linux” in production until April 2020 when Ubuntu 20.04 LTS comes out.

At any rate, thanks to the support of corporate behemoths like Netflix (for FreeBSD) and Intel (for Linux) both of these operating systems are likely to be around for at least another 40 years, which is how old *BSD is today (original BSD Unix goes back to 1977, Linux to 1991, and FreeBSD to 1993). FreeBSD has something like 5,000 or 6,000 developers involved in some way in the project (along with several hundred working on OpenBSD and NetBSD) and Linux has many more than that if counting all the distributions. This is not a zero-sum game, and both will continue to have many users, developers, and unique strengths.

PS, I’m always surprised to see how many Linux people don’t realize it’s generally slower than FreeBSD for web servers or networking, or FreeBSD people who don’t realize Linux has a lot more horsepower for applications. For instance, many FreeBSD fans will note that Steve Jobs and Apple went to FreeBSD as the backbone of OS X (now MacOS) instead of Linux, but that was really because of licensing differences. MacOS would probably be faster today if it has been based on Linux rather than FreeBSD, as TCP/IP and networking is not the bottleneck of typical Mac usage.

PPS, if you want a bunch of benchmarks comparing the two, try sifting through a website called Phoronix. If you find networking or latency benchmarks, FreeBSD is much better. Every time you find new application or encoding or compiler or even PHP benchmarks, Linux is much better.

PPPS, Linux doesn’t need to close the entire TCP/IP gap to be the faster choice for some web applications. If you’re using Laravel or WordPress without sophisticated caching plugins/techniques, that’s a lot of PHP to be processed on the server and Linux does that faster. But languages like Java are compiled, so FreeBSD is usually faster there even without caching. Response time is also the main thing to worry about (and therefore FreeBSD’s faster) if you have mostly flat HTML/CSS files with client-side JavaScript, or if you have a ton of cache usage on your (for example) WordPress site. On the other hand, if you’re using Java or tons of caching, your site is probably plenty fast already without needing to worry about switching from Linux to FreeBSD.

I can’t speak to the current state of things, because Linux has had a lot of development over the years, but…

My good friend Matt Dillon, of Dragonfly BSD fame, was a committer to the FreeBSD project for years. One of his commits was a crazy radical change to the scheduler that made a night/day difference in FreeBSD’s performance. The upgrade was noticeable even when using the shell.

It all boils down to algorithms. FreeBSD has always had a large community of academics working on it, using among the best choices of algorithms from the start.

Linux was a one man show, almost a science fair kind of project (impressive nonetheless, and quite an accomplishment) where a lot of corners were cut just to have functionality. Over the years, big companies hacked on Linux and contributed pull requests, vastly improving on Linux’ deficiencies. To the point where Linux is now dominant among operating systems (especially servers, but also android phones if you want to be technical).

FreeBSD did have one big flaw that likely led to its stagnation in the server space (Yahoo! at its peak was pretty much run on FreeBSD servers). When CPUs started having multiple cores, or motherboards with multiple CPUs became prevalent, FreeBSD was slow to support them. The initial hack was to put a big lock (it was known as the “big lock”, seriously) around all the code that wasn’t able to handle multiple threads of CPU execution. This ultimately was almost all of the kernel. So effectively, you had a 4 core system running only one core at a time with the other 3 waiting on the big lock to be released. It took many man years to excise the routines in the kernel to allow true multicore/multithreading in the kernel.

Meanwhile, Linux supported multiple cores early on, and only got better at it.

I’ll end this with a true story. I was tasked, a long time ago, with making my company multihomed network-wise. We had two T1s to two different providers. To properly use those two connections, we needed a router of some kind. My first attempt was to buy a high speed serial card for a PC that I installed Linux on. I hooked up the T1s to it and turned on gated, called one of the providers and said, “turn on the routing!” And they did. The machine came to a dead stop. I could not type into the console to even list the routes and see if anything was actually happening.

So I sent the serial card back and found one compatible with FreeBSD. Set up the FreeBSD system and gated. Called the provider and said, “turn on the routing!” And he did, and the machine was fully responsive. You could hardly tell there was a massive BGP4 stream going both ways on the serial connections.

Post mortem of what went on.

Linux implemented its routing table as a linear linked list. Every BGP4 route add/delete coming in caused a linear linked list insertion/deletion operation on a very long list. The CPU was spending 100% of its time in the kernel trying to keep up with all the add/delete routes coming in. This is why it was unresponsive.

FreeBSD implemented its routing table as a radix tree. The cost of an add or delete to the tree was many orders of magnitude faster.

The bottom line, algorithms. FreeBSD is likely to have closer to the ultimate in algorithms for every detail of the OS. As a starting point, the source code is a much better place to start from.

Don’t get me wrong, I’m a huge Linux fan and use it on my laptop and a couple of desktop systems in my home lab, and in VMs on my Mac laptop and desktop, too. And I have no FreeBSD anywhere.