Comparison of C/POSIX standard library implementations for Linux
1–10 of 58 posts
Re: Comparison of C/POSIX standard library implementations for Linux
#2That 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.
Re: Comparison of C/POSIX standard library implementations for Linux
#3Fun libc comparison by the author of musl.
My getaway is: glibc is bloated but fast. Quite unexpected combination. Am I right?
Re: Comparison of C/POSIX standard library implementations for Linux
#4Fun libc comparison by the author of musl. My getaway is: glibc is bloated but fast. Quite unexpected combination. Am I right?
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.
Re: Comparison of C/POSIX standard library implementations for Linux
#5Fun libc comparison by the author of musl. My getaway is: glibc is bloated but fast. Quite unexpected combination. Am I right?
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?
Re: Comparison of C/POSIX standard library implementations for Linux
#6Fun libc comparison by the author of musl. My getaway is: glibc is bloated but fast. Quite unexpected combination. Am I right?
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-…
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
Re: Comparison of C/POSIX standard library implementations for Linux
#7Earlier quoted context omitted.
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-…
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 op…
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?
Re: Comparison of C/POSIX standard library implementations for Linux
#8It 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!
Re: Comparison of C/POSIX standard library implementations for Linux
#9Please 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.”).
Re: Comparison of C/POSIX standard library implementations for Linux
#10Earlier quoted context omitted.
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 op…
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?
What problem are you trying to solve? glibc works just fine for most use cases. If you have some niche requirements, you have alternative libraries you can use (listed in the article). Forking glibc in the way you describe is literally pointless