GNU C Library 2.36 Released With New Functions, More Optimizations

[phoronix]

Phoronix: GNU C Library 2.36 Released With New Functions, More Optimizations

Released overnight was a new version of Glibc, the GNU C Library, commonly used by Linux systems as the default libc implementation...

https://www.phoronix.com/news/GNU-C-Library-Glibc-2.36

[FireBurn]

I wonder if Glibc will become a little more competitive now that LLVM's libc is being worked on

[tildearrow]

Typo:

- The fsopen, fsmount, move_mount, fsconfig, fspick, open_tree, and mount_setattr functions have been added that correspond to the Linux kerne's new mount APIs.

- The process_mrelease function has been added to release the memory of a dying process using the caller's CPU affinity and prirotiy with CPU usage accounted to the caller.

[PerformanceExpert]

I wonder if Glibc will become a little more competitive now that LLVM's libc is being worked on

In which areas is GLIBC not competitive? I haven't followed LLVM libc in detail but I know they are doing crazy stuff like trying to write memcpy in C++. There are certain things one writes in assembler, for sound reasons, and it seems these lessons need to be relearned again and again...

[Michael]

Typo:

Whoops thanks!

[NobodyXu]

In which areas is GLIBC not competitive?

- You cannot statically linked with GLIBC
- GLIBC is huge in binary size
- A lot of non-std confirmant behavior, mentioned on https://wiki.musl-libc.org/functiona...rom-glibc.html

[mlau]

- You cannot statically linked with GLIBC

sure you can.

- GLIBC is huge in binary size

it also supports a LOT of functions. Besides, on modern systems most of it is shared by all processes using it, and ram has become plentiful.
Outside of memory-constrained embedded systems this is not an issue, and these tend to use libraries better suited
for their use case (I remember qnx6 allowed to trim the libc of the final image to contain only the functions that were
actually used by any process of that image, saved a few kilobytes).

- A lot of non-std confirmant behavior, mentioned on https://wiki.musl-libc.org/functiona...rom-glibc.html

And yet almost everyone outside of embedded uses it, and and noone has stepped up to rectify these differences. They must be doing something right or the incompatibility with posix is not as grave as you think.

[PerformanceExpert]

- You cannot statically linked with GLIBC
- GLIBC is huge in binary size
- A lot of non-std confirmant behavior, mentioned on https://wiki.musl-libc.org/functiona...rom-glibc.html

Of course you can statically link with GLIBC. GLIBC is large because it has lots of features and supports lots of targets and many optimizations. But how does its size matter given it is shared across many binaries? I don't see any non-standard behaviour in your link, it's not a bug if you support additional floating point formats or printf specifiers. It's funny you mention MUSL, they seem religiously against optimization - even today many MUSL string functions simply process one byte at a time without any optimization whatsoever. Good luck with that!

[Ub42]

I wonder if Glibc will become a little more competitive now that LLVM's libc is being worked on

Competition with musl already greatly improved glibc. For instance with libpthread removal. Also musl author's opinion on the LLVM's libc was a good read.

[mlau]

Also musl author's opinion on the LLVM's libc was a good read.

His third point is incredibly important, but I'm sure it'll be ignored by the llvm developers...