Page 3 of 3 FirstFirst 123
Results 21 to 22 of 22

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

  1. #21
    Join Date
    Oct 2009
    Posts
    845

    Default

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

  2. #22
    Join Date
    Nov 2011
    Posts
    263

    Default

    Quote 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:
    Quote 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 at 09:54 PM.

Posting Permissions

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