4

Since clang/llvm has no plan to support OpenMP any time soon, and Intel is going far away down the road of TBB library. Is it still worth to implement multi-thread scientific libraries (I am working on ccv: http://github.com/liuliu/ccv) on top of OpenMP? Despite all the criticisms, my experience with OpenMP is quite happy (it is super easy to use, and the performance gain is reasonable). But if it is a dying technology, what's the replacement for easier-multi-thread in C? (not pthread, and TBB is C++ thing). Thanks!

liuliu
  • 721
  • 1
  • 8
  • 19
  • “quite happy”? Have you ever tried exiting prematurely out of an OpenMP critical section? Or using any of a number of other language features that OpenMP doesn’t support even though it would make perfect sense? – Konrad Rudolph Mar 18 '12 at 22:11
  • 1
    Not if you always program things like: for (i = 0; i < 1000; i++) { a[i] = h[b[i]]; } :) – liuliu Mar 18 '12 at 22:47

3 Answers3

3

OpenMP is alive and well, with some efforts going into even extending it to manycore accellerator type things. Incorporating OpenMP sadly isn't high on Clang's priority list, but all existing compiler vendors (Intel, gcc, pgi, etc) are committed to not only existing implementations but the ongoing developments in the standard. I wouldn't worry about it; eventually clang/llvm will come around.

Jonathan Dursi
  • 50,107
  • 9
  • 127
  • 158
1

If you look at the C++11 feature support in clang list you’ll notice that the concurrency support is entirely nonexistent.

So even though the new C++ standard actually offers great features for concurrency and multithreading, we currently can’t really use it if we want to stay platform independent.

So if you have existing OpenMP code, don’t sweat it; clang simply isn’t supported and while that’s a pity, it makes no sense to switch to another technology just because of it. Of course you could use TBB but I’d say that in the light of C++11 concurrency TBB is just a transitional technology anyway.

Personally, I’d be more than happy to see the last of OpenMP but at the moment we’re not there yet.

Konrad Rudolph
  • 530,221
  • 131
  • 937
  • 1,214
0

The new C standard, C11, has its own support for threads, that follows a broken down pthreads model. (C++11 has the same, BTW) This can't replace OpenMP, though, in its simplicity to tackle parallel loops and doing reductions etc.

There is one "new" tool that is worth looking into, _Atomic. Classical thread libraries only give you mutexes to avoid races, which can be quite heavy in cases that there is congestion on some data. _Atomic finally gives a lowlevel language interface to features that processors have in most cases, anyhow, and it allows you to do quick updates of counters or stuff like that between threads without races.

_Atomic and OpenMP should cooperate without problems.

Jens Gustedt
  • 76,821
  • 6
  • 102
  • 177