[HN Gopher] Comparison of C/POSIX standard library implementatio...
___________________________________________________________________
Comparison of C/POSIX standard library implementations for Linux
Author : smartmic
Score : 78 points
Date : 2025-05-10 14:55 UTC (8 hours ago)
(HTM) web link (www.etalabs.net)
(TXT) w3m dump (www.etalabs.net)
| ObscureScience wrote:
| 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.
| lifthrasiir wrote:
| Yeah, also it doesn't compare actual implementations, just
| plain checkboxes. I'm aware of two specific substantial
| performance regressions for musl: exact floating point printing
| (it uses Dragon4 but implemented it way slower than it could
| have been) and memory allocator (for a long time it didn't any
| sort of arena like pretty much every modern allocator---now it
| does with mallocng though).
| snickerer wrote:
| Fun libc comparison by the author of musl.
|
| My getaway is: glibc is bloated but fast. Quite unexpected
| combination. Am I right?
| kstrauser wrote:
| 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 wrote:
| 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 wrote:
| 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?
| dima55 wrote:
| 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
| kstrauser wrote:
| Nothing really. I was just curious and this isn't
| something I know much about, but would like to learn more
| of.
| SAI_Peregrinus wrote:
| It's called glibc. Essentially all that "bloat" is
| conditionally compiled, if your target isn't an ancient
| or bizarre platform it won't get included in the runtime.
| kstrauser wrote:
| That's mostly true, but not quite. For instance, suppose
| you aim to support all of 32/64-bit and little/big-
| endian. You'll likely end up factoring straightforward
| math operations out into standalone functions. Granted,
| those will probably get inlined, but it may mean your
| structure is more abstracted than it would be otherwise.
| Just supporting the options has implications.
|
| That's not the strongest example. I just meant it to be
| illustrative of the idea.
| jcranmer wrote:
| The way glibc's source works (for something like math
| functions) is that essentially every function is
| implemented in its own file, and various config knobs can
| provide extra directories to compile and provide function
| definitions. This can make actually finding the
| implementation that's going to be used difficult, since a
| naive search for the function name can turn up like 20
| different function definitions, and working out which one
| is actually in play can be difficult (especially since
| it's more than just the architecture name).
|
| Math functions aren't going to be strongly impacted by
| diverse hardware support. In practice, you largely care
| about 32-bit and 64-bit IEEE 754 types, which means your
| macros to decompose floating-point types to their
| constituent sign/exponent/significand fields are already
| going to be pretty portable even across different
| endianness (just bitcast to a uint32_t/uint64_t, and all
| of the shift logic will remain the same). And there's not
| much reason to vary the implementation except to take
| advantage of hardware instructions that implement the
| math functions directly... which are generally better
| handled by the compiler anyways.
| timeinput wrote:
| 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?
| LeFantome wrote:
| 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.
| cyberax wrote:
| Not quite correct. glibc is slow if you need to be able to fork
| quickly.
|
| However, it does have super-optimized string/memory functions.
| There are highly optimized assembly language implementations of
| them that use SIMD for dozens of different CPUs.
| thrtythreeforty wrote:
| 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 wrote:
| musl seems to have displaced dietLibc. Much more complete yet
| fairly small and light.
| yusina wrote:
| Note that dietlibc is the project of a sole coder in the CCC
| sphere from Berlin (Fefe). His main objective was to learn
| how low level infra is implemented and started using it in
| some of his other projects after realizing that there is a
| lot of bloat he can skip with just implementing the bare
| essentials. Musl has a different set of objectives.
| jay-barronville wrote:
| 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.").
|
| [0]: https://www.musl-libc.org
| pizlonator wrote:
| 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.
| abnercoimbre wrote:
| Interesting! Will you stick around with the musl build? And if
| so, why?
| pizlonator wrote:
| Not sure but in likely to because right now I to use the same
| libc in userland (the Fil-C compiled part) and yololand (the
| part compiled by normal C that is below the runtime) and the
| userland libc is musl.
|
| Having them be the same means that if there is any libc
| function that is best implemented by having userland call a
| Fil-C runtime wrapper for the yololand implementation (say
| because what it's doing requires platform specific assembly)
| then I can be sure that the yololand libc really implements
| that function the same way with all the same corner cases.
|
| But there aren't many cases of that and they're hacks that I
| might someday remove. So I probably won't have this "libc
| sandwich" forever
| edam wrote:
| Pretty obviously made by the musl authors.
| deaddodo wrote:
| > "I have tried to be fair and objective, but as I am the
| author of musl"
|
| Yeah, pretty obvious when they state as much in the first
| paragraph.
| moomin wrote:
| No cosmopolitan, pity.
___________________________________________________________________
(page generated 2025-05-10 23:00 UTC)