Announcement

Collapse
No announcement yet.

Intel Wants To Contribute Parallel STL Support To libstdc++ / libc++

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

  • Intel Wants To Contribute Parallel STL Support To libstdc++ / libc++

    Phoronix: Intel Wants To Contribute Parallel STL Support To libstdc++ / libc++

    The last major item for GCC's libstdc++ standard library for C++17 support is supporting the technical specification around parallelism and Intel is hoping to land their implementation of it for both libstdc++ and libc++...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Thank you Intel for (yet again) making fundamental contributions that improve practically every program that runs on Linux.

    Comment


    • #3
      YES YES!!
      for me its the only useful feature of c++17 and that its not supported by the compilers is sad

      Comment


      • #4
        Very nice of Intel, but is it programmed to perform poorly if an AMD CPU is detected?

        Comment


        • #5
          Originally posted by hoohoo View Post
          Very nice of Intel, but is it programmed to perform poorly if an AMD CPU is detected?
          Nope. Not only did he explicitly say his implementation is vendor-neutral, but because it's very flexible those portions that invoke Intel-specific processor extensions can easily be replaced by AMD-specific extensions, if AMD want to contribute.

          Intel is offering to contribute a framework and a particular thread-based implementation, but is coordinating with another contributor who is working on a GPU-based implementation. It turns out this is an entire ripe field of research, so don't expect stability for quite a while.

          Comment


          • #6
            Seems like something you'd think AMD would've developed back when Bulldozer was released (since that CPU heavily depends upon parallelization to be worth using).

            Comment


            • #7
              I was very surprised in 2012 to find that not only was libstdc++ not parallelized, In places it wasn't even reentrant (and thus not safe to use in threaded code at all). We assume that because something is mature that it is not a candidate for major improvements. This is exciting development.

              No need to worry here about hurting another vendor. The usual way for this sort of thing is there will be a portable C/C++ codepath.
              If there is an opportunity for major vendor specific optimizations, , and an optimized one that can be enabled with compiler switches.
              I'm sure people will be looking at it on amd, arm, AARCH64, and other platforms to see if there is anything more they can do for their respective platforms.

              Comment


              • #8
                Originally posted by davidbepo View Post
                YES YES!!
                for me its the only useful feature of c++17 and that its not supported by the compilers is sad
                this is a library feature, you don't need new compiler for it, you could do it yourself, like intel did

                Comment


                • #9
                  Originally posted by schmidtbag View Post
                  Seems like something you'd think AMD would've developed back when Bulldozer was released (since that CPU heavily depends upon parallelization to be worth using).
                  seems like by something you mean c++17 standard

                  Comment


                  • #10
                    Originally posted by pal666 View Post
                    seems like by something you mean c++17 standard
                    Seeing as Bulldozer was released in 2011, no, I didn't mean that and as usual, I have no clue how you draw your conclusions.

                    Comment

                    Working...
                    X