Announcement

Collapse
No announcement yet.

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

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

  • #31
    Originally posted by AJenbo View Post
    It looks like they want to stay away from OpenMP and instead find a solution that works for hundreds of threads, they mention that OpenMP is only good for dozens of threads.
    Link?

    OpenMP is meant to start one thread per cpu, and then keep them in a pool. I'd need more info on what they say doesn't scale, as I see nothing obvious that wouldn't work if I had a 100-core cpu.

    Comment


    • #32
      Originally posted by curaga View Post
      Link?

      OpenMP is meant to start one thread per cpu, and then keep them in a pool. I'd need more info on what they say doesn't scale, as I see nothing obvious that wouldn't work if I had a 100-core cpu.
      https://sites.google.com/site/parall...why-not-openmp

      Comment


      • #33
        Originally posted by DeepDayze View Post
        I'm sure database-based apps can very well use many threads. Also parallelizing code makes use of threads to handle the various concurrent operations going on.
        DB apps are mostly multiprocess. You get more parallelism by spawning more processes. Threading doesnt really come too much into play.

        Comment


        • #34
          C/C++ for hundreds of threads... . I don't think it's outrageous, just use a spawn function assigning data sections to worker threads...

          Edit: worker threads terminate themselves. =)

          Comment


          • #35
            Originally posted by curaga View Post
            By default it's all single-threaded. You have to manually set GOMAXPROCS to make it use more than one thread.

            It may encourage goroutines, but they are not threads.
            Can you explain the difference? They are concurent tasks, and setting GOMAXPROCS to #CPUs is optimal.

            Comment


            • #36
              Originally posted by Drago View Post
              Can you explain the difference? They are concurent tasks, and setting GOMAXPROCS to #CPUs is optimal.
              Every request will only be processed by a single thred. Multiple request have to be revived simultaniously for it to give any performance gains.

              Comment


              • #37
                Hal Finkel is trying to get the Intel guys, Cray Guys, Apple and Google to make sure they target OpenMP 4.

                http://lists.cs.uiuc.edu/pipermail/c...il/029023.html

                Dave,

                [I've copied the cfe-dev list as well.]

                Thanks for sharing this! I think this sounds very interesting. I don't know much about AMP, but I do have users who are also interested in accelerator targeting, and I'd like you to share your thoughts on:

                1. Does your implementation share common functionality with the 'captured statement' work that Intel is currently doing (in order to support Cilk, OpenMP, etc.)? If you're not aware of it, see: http://lists.cs.uiuc.edu/pipermail/c...08/077615.html -- This should end up in trunk soon. I ask because if the current captured statement patches would almost, but not quite, work for you, then it would be interesting to understand why.

                2. What will be necessary to eliminate the two-clang-invocations problem. If we ever grow support for embedded accelerator targeting (through AMP, OpenACC, OpenMP 4+, etc.), it sounds like this will be a common requirement, and if I had to guess, there is common interest in putting the necessary infrastructure in place.

                -Hal
                Hal eludes to the work in several camps and designing to accomodate them all.

                Comment


                • #38
                  A good compiler needs to support existing software. OpenMP is needed. Not sure what Clang has against that. No one said it's a bad idea to not provide a better alternative. What is a bad idea is not supporting a feature that's needed by current software.

                  Comment


                  • #39
                    Originally posted by duby229 View Post
                    DB apps are mostly multiprocess. You get more parallelism by spawning more processes. Threading doesnt really come too much into play.
                    Thanks for the clarification, but can using threads rather than separate processes also be useful for parallel operations?

                    Comment


                    • #40
                      Well that's a crappy explanation, a stub wiki page...

                      To paraphrase that page:

                      "OpenMP gives great gains now and 5+ years into the future, but we want automatic parallelization for future huge systems, we can't be arsed to implement OpenMP".

                      Comment


                      • #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; 04-21-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

                                Working...
                                X