GNU C Library 2.16 Brings Many Features (GLIBC)

[Ibidem]

Hmmm... kinda doubt that, the places asm is used are likely places where it has really been proven to be very beneficial performance-wise. It's not as if it's added because it's more convenient than portable c code.

Anyway if you have a benchmarks concerning this I'd be very interested.

(And also @curaga: )

First:
Benchmarks have been mentioned previously; see http://www.etalabs.net/compare_libcs.html under "Performance" (if you doubt the comparisons, the benchmark program is libc-bench)
No-one's done any tests with pts just yet, but I'm too busy with other things to bother myself.

If you don't want benchmarks from an Atom, don't ask me. I have an Atom N270 on my (current) main laptop, a PIII that I occasionally boot but it's running NetBSD now, and an AMD Neo (K8) in a laptop which currently has a flaky keyboard, so I haven't booted it in some time.
If you're wondering what the applicable optimizations are, decode this:

$ grep flags /proc/cpuinfo                                    
flags           : fpu vme de tsc msr pae mce cx8 apic mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 xtpr pdcm movbe lahf_lm
flags           : fpu vme de tsc msr pae mce cx8 apic mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 xtpr pdcm movbe lahf_lm

Second:

> One criticism I've heard (not saying I agree!) is that you lose
> performance with musl thanks to most functions being in C...

I haven't found that to be the case. When it is, asm can be added if
needed. If you're aware of some operations that are significantly
slower than glibc and believe lack of asm is the problem, please
report them.

@Chewi: static linking is one of glibc's weak points, so the speed of static binaries is an advantage of musl/uclibc/dietlibc/any other libc.

Other points:
More bloat means less reliability.
glibc's libm does well under default settings...but from what I hear, it messes up on some alternate settings (rounding).

Here's Rich's draft "promotional material":

Consistent quality and implementation behavior from tiny embedded
systems to full servers.

Minimal machine-specific code, meaning less chance of breakage on
minority architectures and better success with "write once run
everywhere" development.

Extremely efficient static and dynamic linking support, yielding small
binaries and minimal startup overhead.

Realtime-quality robustness. No unnecessary dynamic allocation. No
unrecoverable late failures. No lazy binding or lazy allocation.

MIT license.

Full math library with a focus on correctness. Exact and
correctly rounded conversion between binary floating point and decimal
strings.

Reentrancy, thread-safety, and async-signal safety well beyond the
requirements of POSIX. Even snprintf and dprintf are fully reentrant
and async-signal-safe.

Highly resource-efficient POSIX threads implementation, making
multi-threaded application design viable even for memory-constrained
systems.

Simple source code and source tree layout, so it's easy to customize
or track down the cause of unexpected behavior or bugs, or simply
learn how the library works.

[XorEaxEax]

2. In many places, it ends up being faster than glibc, because of the implementation method.

Hmmm... kinda doubt that, the places asm is used are likely places where it has really been proven to be very beneficial performance-wise. It's not as if it's added because it's more convenient than portable c code.

Anyway if you have a benchmarks concerning this I'd be very interested.

[curaga]

2. In many places, it ends up being faster than glibc, because of the implementation method.

Yup, better algorithms tend to win. Though, if you have better algo for function X, where's the patch to enable it in glibc
I hear they're quite a lot more open nowadays for patches.

3. I know ASM has a reputation for being fast, but the truth is, these days good C code + a compiler that does well at optimizing, with appropriate optimizations enabled, can go faster than hand-optimized asm (one example off the top of my head is some crypto routine Torvalds did, vs OpenSSL...saw it on one of his websites, don't remember which)

That's another example of bad asm vs good C, not even counting the god-tier coder doing the C.

[Chewi]

actually, it would be really interesting to do a 4-way comparison: static-vs-dynamic and musl-vs-glibc

some readouts: binary size, execution speeed/performance

I have seen example tests where static binaries are orders of magnitude faster. No idea if this is a general feature.

glibc hates being statically linked though. It kicks up a fuss about it and breaks things like DNS resolution.

[staalmannen]

Run what the musl comparison page ran?

those tests

http://www.etalabs.net/libc-bench.html

are not integrated into phoronix and (although I doubt it) the tests may be biased in favour of musl since it is made by the same author.

I am guessing that any test that measures the performance of a compiled binary from C-code should work...

actually, it would be really interesting to do a 4-way comparison: static-vs-dynamic and musl-vs-glibc

some readouts: binary size, execution speeed/performance

I have seen example tests where static binaries are orders of magnitude faster. No idea if this is a general feature.

[Ibidem]

Re musl - it does cut the bloat, but it also cuts any performance optimizations (no ASM in musl, IIRC)

1. The only _necessary_ ASM is in the loader, but there are now several functions (math and others) where an ASM implementation is used instead of the C one (C and ASM versions provided, ASM built).
2. In many places, it ends up being faster than glibc, because of the implementation method.
3. I know ASM has a reputation for being fast, but the truth is, these days good C code + a compiler that does well at optimizing, with appropriate optimizations enabled, can go faster than hand-optimized asm (one example off the top of my head is some crypto routine Torvalds did, vs OpenSSL...saw it on one of his websites, don't remember which)

as well as many used functions and behaviors that aren't quite standard, but are supported by glibc and used in the real world.

still missing a number, but getting better!

[curaga]

Run what the musl comparison page ran?

[staalmannen]

The comparison table was run on an Atom - in-order cpu with hardly any applicable optimizations (probably sse2 or sse3 at most). It'll be interesting to read benches on more reasonable cpus when you get them out

Also, as mentioned, strict POSIX compliance is a drawback too, depending on your conditions.

For anyone willing to bootstrap a "Sabotage linux" system, I have now also packaged phoronix test suite:

https://github.com/staalmannen/sabotage/commit/448676afdf818322ed6aa1339532a41a9a25d9b8

I still have not had time to play with it and I am also a bit unsure about what types of tests that would be informativ with regards to libc performance. I guess quite many since it is a major communication layer between userland and kernel.

[curaga]

The comparison table was run on an Atom - in-order cpu with hardly any applicable optimizations (probably sse2 or sse3 at most). It'll be interesting to read benches on more reasonable cpus when you get them out

Also, as mentioned, strict POSIX compliance is a drawback too, depending on your conditions.

[staalmannen]

Thanks for the info, are there any other features you'd like to hightlight outside the realm of small memory footprint? (although small memory footprint certainly is a great feature, particularly since my interest stems from stuff I'm thinking of doing with my Raspberry Pi)

small memory footprint is one thing. I think strict POSIX compliance is another.

I do believe that this library might replace bionic in Android in the future.

When I got time, I will try to get phoronix test suite running on my sabotage install (which now boots) since I now got php properly ported.
It may well be that this library also is faster on some operations, which the comparison table seems to indicate. This is still up for testing though.