Shocked: X32 can be 10% faster, but musl Libc 40% slower | Hacker News Reader

Shocked: X32 can be 10% faster, but musl Libc 40% slower

youtube.com

15 pointspantalaimon9 comments

"10% faster" than... "40% slower" than...

A lot of people who have time to scan an article to find out what the title should have said, have no time to do the same for video.

This is a linux kernel compilation benchmark comparing build tools of amd64-glibc, x32-glibc and x32-musl.

x32-glibc is about 10% faster than amd64-glibc, but surprisingly x32-musl is 40% slower than the glibc time.

Author mentions that it might just be stdout buffering, implicitly done by glibc but not by musl hinted at by 54min of kernel time vs 7min with glibc.

I'm actually more interested in memory usage.

> I'm actually more interested in memory usage.

CERN found that X32 saves between 10% to 20% memory, they found similar gains in execution speed due to better cache utilization

- https://twiki.cern.ch/twiki/pub/ITSDC/ProfAndOptExperimentsA...

- https://www.researchgate.net/publication/270980212_Evaluatio...

Last I checked (which was something like 8 years ago) musl didn't support VDSO properly.

(Meaning time() and gettimeofday() turn into kernel syscalls instead of a simple memory access.)

Lots of nuance here that can have far-reaching consequences.

man this is compile time, not execution time

The benchmark is compiling the Linux kernel with a GCC linked against a X32-glibc and a musl-libc.

Baseline is x86-64 glibc.

So that's an x64 toolchain linking to various libc's, roughly an x64-executable linker benchmark then, meh.

The entire userspace is X32 in the X32 case, you can't link a x64 binary to a x32 libc.

An x64 program can do whatever it wants with its data be it source text, x64 or x32 objects/libs.

So is this benchmark is comparing an toolchain of x32 binaries to a toolchain of x64 binaries? I assumed that it was cross-targeting.

Reply on news.ycombinator.com