Announcement

Collapse
No announcement yet.

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

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

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


            • #51
              Originally posted by RahulSundaram View Post
              Yes. What's amusing about that?
              If this is true, either standardisation committee is insane or compiler devs are incompetent.
              I guess it is rather lack of interest.

              Comment


              • #52
                Originally posted by pipe13 View Post
                ^^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.


                That multi-tread model that some of you describe doesn't exist. For example, a video encoding program can have 1000 threads for a movie. That's because a movie has a key-frame every 6 second and the next frames are depend on that frame. So 6000 seconds=1000 maximum possible threads. Cannot have 2000 threads even if "God" wants to. An office program cannot have more than two threads for the same reason. You have a program with if/else, first goes the one and only then the other. You have two equations, you cannot run them in parallel because the outcome of the first is a variable of the second, so you must have the first finished. Programming language has nothing to do with paralelization. And those helpers cannot do magically the job.

                Comment


                • #53
                  Originally posted by LightBit View Post
                  If this is true, either standardisation committee is insane or compiler devs are incompetent.
                  I guess it is rather lack of interest.
                  Why would you prefer to roll your eyes and guess wrong rather than go ahead and look at the relevant pages? The issues are very well documented and are not due to issues with standards body or developers.

                  Comment


                  • #54
                    Originally posted by artivision View Post
                    That multi-tread model that some of you describe doesn't exist. For example, a video encoding program can have 1000 threads for a movie. That's because a movie has a key-frame every 6 second and the next frames are depend on that frame. So 6000 seconds=1000 maximum possible threads. Cannot have 2000 threads even if "God" wants to. An office program cannot have more than two threads for the same reason. You have a program with if/else, first goes the one and only then the other. You have two equations, you cannot run them in parallel because the outcome of the first is a variable of the second, so you must have the first finished. Programming language has nothing to do with paralelization. And those helpers cannot do magically the job.
                    Never said they could. You are perhaps trying to create an argument where none exists?

                    Comment


                    • #55
                      Originally posted by RahulSundaram View Post
                      Why would you prefer to roll your eyes and guess wrong rather than go ahead and look at the relevant pages? The issues are very well documented and are not due to issues with standards body or developers.
                      Sorry, but I can't find anything.

                      Comment


                      • #56
                        Originally posted by LightBit View Post
                        Sorry, but I can't find anything.
                        Why not? Even a trivial search returns

                        http://gcc.gnu.org/gcc-4.8/cxx0x_status.html
                        http://clang.llvm.org/cxx_status.html

                        Comment


                        • #57
                          Originally posted by RahulSundaram View Post
                          Doesn't say why it isn't implemented.

                          Comment


                          • #58
                            Originally posted by LightBit View Post
                            Doesn't say why it isn't implemented.
                            What feature are you referring to? You should read the references in more detail and the specification if you want more specific details.

                            Comment


                            • #59
                              Originally posted by RahulSundaram View Post
                              What feature are you referring to? You should read the references in more detail and the specification if you want more specific details
                              For example: http://www.open-std.org/jtc1/sc22/wg...2008/n2670.htm

                              It seems like they have standardized something unfinished. It should be implement than standardize.
                              On the other hand they say minimal implementation is trivial:
                              Originally posted by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2670.htm
                              An implementation that does not support garbage collection and implements all library-calls described here as no-ops is conforming. Hence a minimal implementation is trivial.

                              Comment


                              • #60
                                Originally posted by artivision View Post
                                That multi-tread model that some of you describe doesn't exist. For example, a video encoding program can have 1000 threads for a movie. That's because a movie has a key-frame every 6 second and the next frames are depend on that frame. So 6000 seconds=1000 maximum possible threads. Cannot have 2000 threads even if "God" wants to. An office program cannot have more than two threads for the same reason. You have a program with if/else, first goes the one and only then the other. You have two equations, you cannot run them in parallel because the outcome of the first is a variable of the second, so you must have the first finished. Programming language has nothing to do with paralelization. And those helpers cannot do magically the job.
                                I don't see why you would be limited to 1 tread per key-frame. It should be possible to work on multiple parts of a frame simultaneously, you could for example spawn a tread per block, with a block size of 16x16 that would give you 8160 treads per key-frame. Probably not optimal in some ways but a lot more then 1.

                                Comment

                                Working...
                                X