3 ms·

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

15 points by pantalaimon 5y ago

hdjjhhvvhga 5y ago
man this is compile time, not execution time
- pantalaimon 5y ago
  The benchmark is compiling the Linux kernel with a GCC linked against a X32-glibc and a musl-libc. Baseline is x86-64 glibc.
  - karmakaze 5y ago
    So that's an x64 toolchain linking to various libc's, roughly an x64-executable linker benchmark then, meh.
    - pantalaimon 5y ago
      The entire userspace is X32 in the X32 case, you can't link a x64 binary to a x32 libc.
      - karmakaze 5y ago
        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.
fivelessminutes 5y ago
"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.
ysleepy 5y ago
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.
- pantalaimon 5y ago
  > 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/ProfAndOptExperimentsApps/x32.pdf https://twiki.cern.ch/twiki/pub/ITSDC/ProfAndOptExperimentsA... - https://www.researchgate.net/publication/270980212_Evaluation_of_X32-ABI_in_the_context_of_LHC_applications https://www.researchgate.net/publication/270980212_Evaluatio...
- otabdeveloper4 5y ago
  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.

15 points by pantalaimon 5y ago

hdjjhhvvhga 5y ago

man this is compile time, not execution time

pantalaimon 5y ago
The benchmark is compiling the Linux kernel with a GCC linked against a X32-glibc and a musl-libc. Baseline is x86-64 glibc.
- karmakaze 5y ago
  So that's an x64 toolchain linking to various libc's, roughly an x64-executable linker benchmark then, meh.
  - pantalaimon 5y ago
    The entire userspace is X32 in the X32 case, you can't link a x64 binary to a x32 libc.
    - karmakaze 5y ago
      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.

fivelessminutes 5y ago

"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.

ysleepy 5y ago

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.

pantalaimon 5y ago
> 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/ProfAndOptExperimentsApps/x32.pdf https://twiki.cern.ch/twiki/pub/ITSDC/ProfAndOptExperimentsA... - https://www.researchgate.net/publication/270980212_Evaluation_of_X32-ABI_in_the_context_of_LHC_applications https://www.researchgate.net/publication/270980212_Evaluatio...
otabdeveloper4 5y ago
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.