OSNews

Well, I can't see why not. Because of the nature of your question, I kind of sense you don't know what OpenMP is about.

It's a standardized set of extensions to selected programming languages implemented as compiler pragmas. In theory, your code should be programmed in such a way that compilers that understand those pragmas will generate parallel code automatically, and those who don't will simply ignore such pragmas and generate serial code as usual. You place such pragmas on strategic points on your code and OpenMP will "automagically" emit parallel code to handle those strategic code paths. Things unfortunately aren't so simple, but they usually work pretty well when the data set is easily processed in parallel, for example many classes of graphic and signal processing algorithms, and some classes of physics simulation algos too. And plenty of brute-force algorithms when not implemented naively, but that's almost an oxymoron =P

OpenMP lets you transfer the job of dividing your program into parallel to the compiler, instead of doing it on your own. Some pragmas imply constructs that one might forget to use, like barriers. Which also implies that sometimes those constructs aren't really necessary and OpenMP will produce sub-optimal code compared to hand-tuned threaded code, but that's not what OpenMP is about anyway.

OpenMP is supposed to handle parallelizable data-sets with a somewhat large grain; it seldom does a good job on code that would benefit most of finely-grained parallel tasks.

In a sense, OpenMP babysits the parallel code creation. It really won't do you much good depending on your data set characteristics, and hand-tuned threaded code is probably faster anyway, but for long-term number-crunching on appropriate data sets OpenMP really shines.

For the casual uses, the GCC version of OpenMP will probably use pthreads, and I couldn't really find whether one can use MPI/PVM implementations (which is the one found on many clusters and NUMA boxes), but I find it great already that many programmers will be exposed to OpenMP "APIs" (if they can really be called that); it should at least help those "lazy programmers" writing code they know is parallelizable but don't think it's worth the trouble to re-model their algorithms around threads.


Now, regarding the uniprocessor case: some classes of algorithms can surely benefit from being run "pseudo-parallel", as in many threads being scheduled to run on a given time. For example, branch-and-bound algorithms could be run multithreaded and an eventual bound could be found by a thread earlier than others because it followed a different path; then it broadcasts such information so every thread restart working from that point on. Same thing with other algorithms based on backtracking, depending on the implementation and the goal.

Anyway, parallel code on uniprocessors usually don't hurt, unless shit begin to happen, like cache trashing and consistently following a code path that finishes faster serially than trying to separate cases into threads that execute in some scheduled order. But it's up to the programmer's discretion NOT to attempt parallelization on such cases.

Remember: no magic bullets. No compiler features can make up for sheer lack of competence on the programmer's side. =P


Edit: grammar, and I realized I made lots of assumptions that someone completely unfamiliar with OpenMP won't really understand. So I added a couple sentences to clarify some points, but I'm probably missing stuff, still. Let me know if there are still points you'd like me to clarify even further.

Edit 2: grammar, still =P

Edited 2007-05-16 21:51