Page 6 of 8 FirstFirst ... 45678 LastLast
Results 51 to 60 of 72

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

  1. #51
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    389

    Default

    Quote 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.

  2. #52
    Join Date
    Apr 2011
    Posts
    310

    Default

    Quote 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.

  3. #53

    Default

    Quote 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.

  4. #54
    Join Date
    Jun 2006
    Location
    Denver
    Posts
    54

    Default

    Quote 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?

  5. #55
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    389

    Default

    Quote 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.

  6. #56

    Default

    Quote 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

  7. #57
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    389

    Default

    Quote Originally Posted by RahulSundaram View Post
    Doesn't say why it isn't implemented.

  8. #58

    Default

    Quote 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.

  9. #59
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    389

    Default

    Quote 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:
    Quote 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.

  10. #60
    Join Date
    Sep 2011
    Posts
    680

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •