Comparison of C/POSIX standard library implementations for Linux
14 comments
·May 10, 2025ObscureScience
That table is unfortunately quite old. I can't personally say what have changed, but it is hard to put much confidence in the relevance of the information.
thrtythreeforty
It really ought to lead with the license of each library. I was considering dietlibc until I got to the bottom - GPLv2. I am a GPL apologist and even I can appreciate that this is a nonstarter; even GNU's libc is only LGPL!
LeFantome
musl seems to have displaced dietLibc. Much more complete yet fairly small and light.
moomin
No cosmopolitan, pity.
edam
Pretty obviously made by the musl authors.
snickerer
Fun libc comparison by the author of musl.
My getaway is: glibc is bloated but fast. Quite unexpected combination. Am I right?
LeFantome
A lot of the “slowness” of MUSL is the default allocator. It can be swapped out.
For example, Chimera Linux uses MUSL with mimalloc and it is quite snappy.
kstrauser
It’s not shocking. More complex implementations using more sophisticated algorithms can be faster. That’s not always true, but it often is. For example, look at some of the string search algorithms used by things like ripgrep. They’re way more complex than just looping across the input and matching character by character, and they pay off.
Something like glibc has had decades to swap in complex, fast code for simple-looking functions.
weinzierl
In case of glibc I think what you said is orthogonal to its bloat. Yes, it has complex implementations but since they are for a good reason I'd hardly call them bloat.
Independently from that glibc implements a lot of stuff that could be considered bloat:
- Extensive internationalization support
- Extensive backward compatibility
- Support for numerous architectures and platforms
- Comprehensive implementations of optional standards
kstrauser
Ok, fair points, although internationalization seems like a reasonable thing to include at first glance.
Is there a fork of glibc that strips ancient or bizarre platforms?
timeinput
My take away is that it's not a meaningful chart? Just in the first row musl looks bloated at 426k compared to dietlibc at 120k. Why were those colors chosen? It's arbitrary and up to the author of the chart.
The author of musl made a chart, that focused on the things they cared about and benchmarked them, and found that for the things they prioritized they were better than other standard library implementations (at least from counting green rows)? neat.
I mean I'm glad they made the library, that it's useful, and that it's meeting the goals they set out to solve, but what would the same chart created by the other library authors look like?
jay-barronville
Please note that the linked comparison table has been unmaintained for a while. This is even explicitly stated on the legacy musl libc website[0][0] (i.e., “The (mostly unmaintained) libc comparison is still available on etalabs.net.”).
My own perf comparison: when I switched from Fil-C running on my system’s libc (recent glibc) for yololand to my own build of musl, I got a 1-2% perf regression. My best guess is that it’s because glibc’s memcpy/memmove/memset are better. Couldn’t have been the allocator since Fil-C’s runtime has its own allocator.