20
top 3 comments
sorted by: hot top controversial new old
[-] snaggen@programming.dev 3 points 1 year ago

As I still run in to glibc version issues a little now and then (admittedly not very often, thankss to containers), I hope to see rust getting rid of libc one day. But I don't expect that in the near future, because as the author mentions, libc is very mature, so replacing it must be done with a lot of caution. But this really looks like a step in the right direction.

[-] BB_C@programming.dev 7 points 1 year ago* (last edited 1 year ago)

Funny you should mention that. Recently, glibc 2.38 was released with broken performance in its allocator API. Hell, one of the developers tried to argue the regression is good to force people to stop using the regressed API unnecessarily (the argument didn't go far, regressions got fixed).

Reports in the wild:
https://github.com/mpv-player/mpv/issues/12076
https://bugs.archlinux.org/task/79300

Links to the libc-alpha relevant threads can be found there.

Speaking of libc allocators, musl's allocator is also shit. That's why some Rust projects use another global allocator in their musl builds. Some of them probably haven't noticed yet that those builds are not static anymore because of that ๐Ÿ˜‰ .

[-] Nereuxofficial@programming.dev 1 points 1 year ago

Hmm now it would be interesting how eyra fares for allocating. And also why does musl not implement a faster allocator? I get that it should be backwards compatible but the gap to glibc seems to be really large.

this post was submitted on 26 Sep 2023
20 points (100.0% liked)

Rust

5938 readers
1 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS