Comments on: More reasons why OpenMP is the way to go for parallel programming http://www.thinkingparallel.com/2006/08/15/more-reasons-why-openmp-is-the-way-to-go-for-parallel-programming/ A Blog on Parallel Programming and Concurrency by Michael Suess Wed, 09 Jul 2008 02:28:24 +0000 http://wordpress.org/?v=2.5 By: Jakob Engblom http://www.thinkingparallel.com/2006/08/15/more-reasons-why-openmp-is-the-way-to-go-for-parallel-programming/#comment-33551 Jakob Engblom Wed, 28 Nov 2007 07:11:28 +0000 http://www.thinkingparallel.com/2006/08/15/more-reasons-why-openmp-is-the-way-to-go-for-parallel-programming/#comment-33551 I just started reading about OpenMP in a recent Intel book on parallel programming (for Intel hyperthreaded and multicore machines), and was kind of shocked to realize that the compiler doesn't check for data dependences and data that is shared between threads that could pose a race condition problem. To me, this sounds like "automatic" is a bit too strongly worded; as a programmer, you still have some seriously hard thinking to do before your serial loop actually parallelizes in the right way. In principle, the compiler should be able to detect dangerous conditions, it has been done in Fortran for a long time. And warn when it cannot understand things (with some pointers and structs you can throw off any C compiler's understanding of your code). There are systems that do this better than OpenMP, like SieveC from CodePlay (helped by somewhat modified C semantics, of course). The Intel book is actually not too shabby if you can live with lots of (TM) notices and a very clear slant towards Intel HW and its Windows/Linux software ecosystem. It gives an overview of a range of programming systems (Windows API, .Net, pthreads, OpenMP). see http://www.intel.com/intelpress/sum_mcp.htm I just started reading about OpenMP in a recent Intel book on parallel programming (for Intel hyperthreaded and multicore machines), and was kind of shocked to realize that the compiler doesn’t check for data dependences and data that is shared between threads that could pose a race condition problem. To me, this sounds like “automatic” is a bit too strongly worded; as a programmer, you still have some seriously hard thinking to do before your serial loop actually parallelizes in the right way.

In principle, the compiler should be able to detect dangerous conditions, it has been done in Fortran for a long time. And warn when it cannot understand things (with some pointers and structs you can throw off any C compiler’s understanding of your code). There are systems that do this better than OpenMP, like SieveC from CodePlay (helped by somewhat modified C semantics, of course).

The Intel book is actually not too shabby if you can live with lots of (TM) notices and a very clear slant towards Intel HW and its Windows/Linux software ecosystem. It gives an overview of a range of programming systems (Windows API, .Net, pthreads, OpenMP). see http://www.intel.com/intelpress/sum_mcp.htm

]]> By: Michael Suess http://www.thinkingparallel.com/2006/08/15/more-reasons-why-openmp-is-the-way-to-go-for-parallel-programming/#comment-14 Michael Suess Fri, 18 Aug 2006 15:52:46 +0000 http://www.thinkingparallel.com/2006/08/15/more-reasons-why-openmp-is-the-way-to-go-for-parallel-programming/#comment-14 Parallel aspect oriented programming, thats an interesting idea for sure. The problem I see with it is that parallelisation is usually more than an "aspect" and therefore the aspect-oriented approach may not be "fine-grained" enough to cover it. But since my knowledge of aspect-oriented programming is more than half a year old by now, maybe that problem is solved already... Parallel aspect oriented programming, thats an interesting idea for sure. The problem I see with it is that parallelisation is usually more than an “aspect” and therefore the aspect-oriented approach may not be “fine-grained” enough to cover it. But since my knowledge of aspect-oriented programming is more than half a year old by now, maybe that problem is solved already…

]]> By: Christopher C. Aycock http://www.thinkingparallel.com/2006/08/15/more-reasons-why-openmp-is-the-way-to-go-for-parallel-programming/#comment-13 Christopher C. Aycock Wed, 16 Aug 2006 15:42:04 +0000 http://www.thinkingparallel.com/2006/08/15/more-reasons-why-openmp-is-the-way-to-go-for-parallel-programming/#comment-13 As you point out, the best features of OpenMP are that it's (1) mature, and (2) builds on existing sequential C code. I'd be interested to see a programming construct based on the aspect-oriented paradigm, though I have yet to find one. That is, instead of including compiler directives in the original code, the programmer can simply include details about parallelization in an external file. The other item I'm interested in is better parallelization of math-specific languages like MATLAB or Mathematica. It seems that the industry is definitely moving in this direction with Star-P, as well as packages from both MathWorks and Wolfram. As you point out, the best features of OpenMP are that it’s (1) mature, and (2) builds on existing sequential C code.

I’d be interested to see a programming construct based on the aspect-oriented paradigm, though I have yet to find one. That is, instead of including compiler directives in the original code, the programmer can simply include details about parallelization in an external file.

The other item I’m interested in is better parallelization of math-specific languages like MATLAB or Mathematica. It seems that the industry is definitely moving in this direction with Star-P, as well as packages from both MathWorks and Wolfram.

]]>