Announcement

Collapse
No announcement yet.

LLVM's Clang Compiler Is Now C++11 Feature Complete

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

  • #41
    Originally posted by DeepDayze View Post
    Thanks for the clarification, but can using threads rather than separate processes also be useful for parallel operations?
    I'm certain that it can be done, but it just isnt easy. It's very difficult to code for even just 8 threads, but it is relatively simple to spawn 8 processes. The same goes for compilers. C/C++ is simply not suitable for parallel workloads. I don't think it ever will be. I don't think we'll see commonplace massively parallel code bases until c/c++ gets displaced. It trains people to think in serial. There are workloads that are inherently parallel but that you see is written in a very serial way. And it is commonplace. It's because it just isnt made for parallelism. and people get so used to the concepts that it enforces that they can't think any other way.
    Last edited by duby229; 21 April 2013, 01:56 PM.

    Comment


    • #42
      Originally posted by wargames View Post
      Sorry, but what the hell... how many programs use hundreds of threads ?
      A few do, but most don't run that many threads AT THE SAME TIME, making scheduling irrelevant to the discussion at hand. Its when you have that many threads ready to run at the same time that you really need a good scheduler.

      Comment


      • #43
        So it?s possible that there never will be decent OpenMP support in LLVM? And that?s what they consider full-featured?

        Comment


        • #44
          Originally posted by duby229 View Post
          I'm certain that it can be done, but it just isnt easy. It's very difficult to code for even just 8 threads, but it is relatively simple to spawn 8 processes. The same goes for compilers. C/C++ is simply not suitable for parallel workloads. I don't think it ever will be. I don't think we'll see commonplace massively parallel code bases until c/c++ gets displaced. It trains people to think in serial. There are workloads that are inherently parallel but that you see is written in a very serial way. And it is commonplace. It's because it just isnt made for parallelism. and people get so used to the concepts that it enforces that they can't think any other way.
          Spawning threads in C/C++ is trivial (at least on Windows...). The main problem is that the vast majority of processing is serial in nature. And most of the stuff that is naturally parallel (large dataset processing, rendering, etc) is already offloaded to the GPU through various API's.

          OpenMP helps parallize the trivial stuff (FOR loops are good example) that is simply too much of a pain to thread by hand, but that only gets you so far. Nevermind the extra layer of complexity when it comes to debugging...

          Comment


          • #45
            In the GCC 4.8.1 release announcement, they claim that GCC is the first compiler to fully support C++11:

            Support for C++11 ref-qualifiers has been added to GCC 4.8.1, making G++ the first C++ compiler to implement all the major language features of the C++11 standard.
            Didn't they lose that race already?

            Comment


            • #46
              I think there is a difference between "we fully support C++11" and "we support the major features".

              Comment


              • #47
                Originally posted by Vim_User View Post
                I think there is a difference between "we fully support C++11" and "we support the major features".
                Not really. No compiler supports *all* the features. Both GCC and Clang will have some (minor) features that will never be implemented due to technical issues. This remains true for older standards like C99 etc.

                Comment


                • #48
                  Originally posted by RahulSundaram View Post
                  Not really. No compiler supports *all* the features. Both GCC and Clang will have some (minor) features that will never be implemented due to technical issues. This remains true for older standards like C99 etc.
                  "technical issues"

                  Comment


                  • #49
                    Originally posted by gamerk2 View Post
                    Spawning threads in C/C++ is trivial (at least on Windows...). The main problem is that the vast majority of processing is serial in nature. And most of the stuff that is naturally parallel (large dataset processing, rendering, etc) is already offloaded to the GPU through various API's.

                    OpenMP helps parallize the trivial stuff (FOR loops are good example) that is simply too much of a pain to thread by hand, but that only gets you so far. Nevermind the extra layer of complexity when it comes to debugging...
                    ^^This.^^ Thread-spawning on Linux is at least as easy as on Windows, if not more so. API's such as Intel's Threading Building Blocks make coding multi-threaded programs that spawn any (finite) number of threads very straghtforward, hiding an awfully large portion of the bookkeeping. Intel (Cilk) and Microsoft (AMP) both have working C++ extensions that codify massive-multi-threading as part of the language. The HPC big-boys -- the ones who spawn the thousands of threads modelling everything from weather to climate to nukes to in-vivo protein conformations on the Really Big Iron, code mostly in Fortran and C++. I think it premature to hope either will somehow be "displaced" within our lifetimes. Continue to evolve, yes.

                    Comment


                    • #50
                      Originally posted by LightBit View Post
                      "technical issues"
                      Yes. What's amusing about that?

                      Comment

                      Working...
                      X