Announcement

Collapse
No announcement yet.

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

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

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