Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 22

Thread: GNU C Library 2.16 Brings Many Features (GLIBC)

  1. #11
    Join Date
    Oct 2009
    Posts
    845

    Default

    Quote Originally Posted by peppepz View Post
    I think that with glibc having adopted its new "development model", the need for the eglibc fork itself is going away.
    From what I understand, Ulrich Drepper was perhaps the big reason for the fork, and now that he's gone maybe there's a big kumbaya happening

    That said, despite what seems like a very hard person to work with I don't think one can doubt his technical ability. His 'what every programmer should know about memory' is the best source of information I've read on the subject.

    Quote Originally Posted by Ibidem View Post
    A(nother?) musl user here...
    Most alternate libc versions are smaller/lighter than glibc.
    musl right now (0.9.2) has partial LSB ABI support, which is a subset of glibc ABI.
    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)

  2. #12
    Join Date
    Jan 2010
    Location
    Ghent
    Posts
    207

    Default

    I just managed to get php to build on my musl system:

    https://github.com/staalmannen/sabot...4935eb91c6f9d0

    Next up should be to try to get the phoronix test suite running.

    An issue that I still have is chainloading from my syslinux on my Arch root partition (/dev/sda1) to my "sabotage linux" partition (/dev/sda4). Somehow it does not get it and the syslinux info is not that informative unfortunately. The system does however run nicely in a chroot so some preliminary tests of musl libc with pts could probably be done already but ideally I should run a clean system without overhead from a host system.

  3. #13
    Join Date
    Jan 2010
    Location
    Ghent
    Posts
    207

    Default

    Quote Originally Posted by XorEaxEax View Post
    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.

  4. #14
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,034

    Default

    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.

  5. #15
    Join Date
    Jan 2010
    Location
    Ghent
    Posts
    207

    Default

    Quote Originally Posted by curaga View Post
    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/sabot...32a41a9a25d9b8

    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.

  6. #16
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,034

    Default

    Run what the musl comparison page ran?

  7. #17
    Join Date
    Nov 2011
    Posts
    267

    Default

    Quote Originally Posted by curaga View Post
    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!

  8. #18
    Join Date
    Jan 2010
    Location
    Ghent
    Posts
    207

    Default

    Quote Originally Posted by curaga View Post
    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.

  9. #19
    Join Date
    Jun 2008
    Location
    Perth, Scotland
    Posts
    435

    Default

    Quote Originally Posted by staalmannen View Post
    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.

  10. #20
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,034

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •