Comparison of C/POSIX standard library implementations for Linux

Post by ethan_smith » Sun, May 11, 2025, 9:43 AM UTC

jay-barronville wrote: post #9

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

Post by imcritic » Sun, May 11, 2025, 11:33 AM UTC

skissane wrote: post #31

pizlonator wrote: post #29

Earlier quoted context omitted.

The Fil-C stack is composed of : - Userland: the place where you C code lives. Like the normal userland you're familiar with, but everything is compiled with Fil-C, so it's memory safe. - Yololand: the place where Fil-C's runtime lives. Fil-C's runtime is about 100,000 lines of C code (almost entirely written by me), which currently has libc as a dependency (because the runtime makes syscalls using the normal C funct…

Why does yoyoland need to use libc’s memcpy? Can’t you just use __builtin_memcpy? On Linux, if all you need is syscalls, you can just write your own syscall wrapper-like Go does. Doesn’t work on some other operating systems (e.g. Solaris/Illumos, OpenBSD, macOS, Windows) where the system call interface is private to the system shared libraries

Post by ape4 » Sun, May 11, 2025, 2:09 PM UTC

kstrauser wrote: post #4

snickerer wrote: post #3

Fun 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-…

Post by pizlonator » Sun, May 11, 2025, 5:22 PM UTC

pjmlp wrote: post #46

pizlonator wrote: post #13

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.

Are you sure they were being used at all? GCC replaces memcpy/memmove/memset with its own intrisics, if compiling in high optimization levels.

Post by pizlonator » Sun, May 11, 2025, 6:44 PM UTC

cryptonector wrote: post #48

imcritic wrote: post #43

Earlier quoted context omitted.

You keep repeating the name wrong: yololand, not yololand.

GP was saying 'yoyoland', when it's 'yololand' (as in YOLO?).