Announcement

Collapse
No announcement yet.

GNU C Library 2.36 Released With New Functions, More Optimizations

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

  • GNU C Library 2.36 Released With New Functions, More Optimizations

    Phoronix: GNU C Library 2.36 Released With New Functions, More Optimizations

    Released overnight was a new version of Glibc, the GNU C Library, commonly used by Linux systems as the default libc implementation...

    https://www.phoronix.com/news/GNU-C-Library-Glibc-2.36

  • #2
    I wonder if Glibc will become a little more competitive now that LLVM's libc is being worked on

    Comment


    • #3
      Typo:

      Originally posted by phoronix View Post
      - The fsopen, fsmount, move_mount, fsconfig, fspick, open_tree, and mount_setattr functions have been added that correspond to the Linux kerne's new mount APIs.
      Originally posted by phoronix View Post
      - The process_mrelease function has been added to release the memory of a dying process using the caller's CPU affinity and prirotiy with CPU usage accounted to the caller.

      Comment


      • #4
        Originally posted by FireBurn View Post
        I wonder if Glibc will become a little more competitive now that LLVM's libc is being worked on
        In which areas is GLIBC not competitive? I haven't followed LLVM libc in detail but I know they are doing crazy stuff like trying to write memcpy in C++. There are certain things one writes in assembler, for sound reasons, and it seems these lessons need to be relearned again and again...

        Comment


        • #5
          Originally posted by tildearrow View Post
          Typo:


          Whoops thanks!
          Michael Larabel
          https://www.michaellarabel.com/

          Comment


          • #6
            Originally posted by PerformanceExpert View Post
            In which areas is GLIBC not competitive?
            - You cannot statically linked with GLIBC
            - GLIBC is huge in binary size
            - A lot of non-std confirmant behavior, mentioned on https://wiki.musl-libc.org/functiona...rom-glibc.html

            Comment


            • #7
              Originally posted by NobodyXu View Post
              - You cannot statically linked with GLIBC
              sure you can.

              Originally posted by NobodyXu View Post
              - GLIBC is huge in binary size
              it also supports a LOT of functions. Besides, on modern systems most of it is shared by all processes using it, and ram has become plentiful.
              Outside of memory-constrained embedded systems this is not an issue, and these tend to use libraries better suited
              for their use case (I remember qnx6 allowed to trim the libc of the final image to contain only the functions that were
              actually used by any process of that image, saved a few kilobytes).

              Originally posted by NobodyXu View Post
              - A lot of non-std confirmant behavior, mentioned on https://wiki.musl-libc.org/functiona...rom-glibc.html
              And yet almost everyone outside of embedded uses it, and and noone has stepped up to rectify these differences. They must be doing something right or the incompatibility with posix is not as grave as you think.

              Comment


              • #8
                Originally posted by NobodyXu View Post

                - You cannot statically linked with GLIBC
                - GLIBC is huge in binary size
                - A lot of non-std confirmant behavior, mentioned on https://wiki.musl-libc.org/functiona...rom-glibc.html
                Of course you can statically link with GLIBC. GLIBC is large because it has lots of features and supports lots of targets and many optimizations. But how does its size matter given it is shared across many binaries? I don't see any non-standard behaviour in your link, it's not a bug if you support additional floating point formats or printf specifiers. It's funny you mention MUSL, they seem religiously against optimization - even today many MUSL string functions simply process one byte at a time without any optimization whatsoever. Good luck with that!

                Comment


                • #9
                  Originally posted by FireBurn View Post
                  I wonder if Glibc will become a little more competitive now that LLVM's libc is being worked on
                  Competition with musl already greatly improved glibc. For instance with libpthread removal. Also musl author's opinion on the LLVM's libc was a good read.

                  Comment


                  • #10
                    Originally posted by Ub42 View Post
                    Also musl author's opinion on the LLVM's libc was a good read.
                    His third point is incredibly important, but I'm sure it'll be ignored by the llvm developers...

                    Comment

                    Working...
                    X