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

                      Working...
                      X