Page 4 of 8 FirstFirst ... 23456 ... LastLast
Results 31 to 40 of 72

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

  1. #31
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,105

    Default

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

  2. #32
    Join Date
    Sep 2011
    Posts
    688

    Default

    Quote 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

  3. #33
    Join Date
    Nov 2007
    Posts
    1,353

    Default

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

  4. #34
    Join Date
    Mar 2011
    Posts
    332

    Default

    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. =)

  5. #35
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    513

    Default

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

  6. #36
    Join Date
    Sep 2011
    Posts
    688

    Default

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

  7. #37
    Join Date
    Oct 2012
    Location
    Washington State
    Posts
    460

    Default

    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.

  8. #38
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,791

    Default

    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.

  9. #39
    Join Date
    Sep 2007
    Location
    Connecticut,USA
    Posts
    962

    Default

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

  10. #40
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,105

    Default

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

Posting Permissions

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