Announcement

Collapse
No announcement yet.

GNU C Library 2.16 Brings Many Features (GLIBC)

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Run what the musl comparison page ran?

    Comment


    • #17
      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!

      Comment


      • #18
        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.

        Comment


        • #19
          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.

          Comment


          • #20
            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.

            Comment


            • #21
              Originally posted by Ibidem View Post
              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.

              Comment


              • #22
                Originally posted by XorEaxEax View Post
                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:
                Code:
                $ 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:
                Originally posted by Rich Felker
                > 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.
                Last edited by Ibidem; 07-14-2012, 09:54 PM.

                Comment

                Working...
                X