multithreading: OpenMP or Boost::Thread?

(L) [2007/09/13] [cignox1] [multithreading: OpenMP or Boost::Thread?] Wayback!

Hi all, I would like to have your opinion about which one should I use when I will come to the point to add multithreading to my raytracer. I've tried Boost::Thread and I've found it simple to use, but from the examples I've read it seems that OpenMP is even easier. I would like to hear pros and cons. Note that I don't care too much about performances since my RT will not be real time.

Thank you!

(L) [2007/09/13] [Michael77] [multithreading: OpenMP or Boost::Thread?] Wayback!

Well, OpenMP requires a compiler that supports it ( for example, the Visual Studio 2005 express edition does support it but doesn´t come with the required header files and libs).

Boost on the other hand is still pretty low level, requiring much more thinking on how to do thing right.

I would recommend to have a look at threading building blocks which is some sort of template library for threads that takes of a lot of work from you. I haven´t used it in a raytracer yet but from what I have seen so far it seems to be the most easiest approach especially if number of cores increases.

P.S.: Here you can find threading building blocks: [LINK http://osstbb.intel.com/index.php] It is free ( GPL with runtime exception) and should support the common compiler (Intel, GCC, MSVC8).[/url]

(L) [2007/09/13] [greenhybrid] [multithreading: OpenMP or Boost::Thread?] Wayback!

My choice (even if not investigated at all, yet) is OpenMP, because it is a standard-definition, implemented by the compiler, not an implementation, where you go an indirect way through some classes and objects... hmmmpf, I hope you get what I mean [SMILEY Neutral]

Point 2a is that I understood the boost-license so that it grants royalty freeness to its users, as well as YOU have to grant royalty-freeness to YOUR users (i.e. those that use your programs) if you use boost::*, but I am probably wrong here...

Point 2b is that the boost-license is incompatible to the GPL (actually, this is the major-reason why I do not use boost::spirit but instead the infernal bison/flex-combo for a small compiler.)

pre-edit: IMHO, OpenMP is also for C
_________________
[LINK http://greenhybrid.net/ greenhybrid.net]

Real Men code Software Graphics.

(L) [2007/09/13] [cignox1] [multithreading: OpenMP or Boost::Thread?] Wayback!

Thank you both. I will give a look to threading building blocks, but I suppose that OpenMp will be the best chioce. Thank you again!

(L) [2007/09/13] [Lynx] [multithreading: OpenMP or Boost::Thread?] Wayback!

greenhybrid, i really don't know which license you read, boost.org says it is pretty similar to the BSD or MIT license (and it indeed is...), if not even less restrictive, pretty much like "do whatever the f*** you want as long as you keep the lincense with derived code" (that is, if you decide to publish derived code at all)

In fact, their goal is to produce reference implementations suitable for future C++ standards, isn't it?

And the license only covers the boost software, i really don't see any restriction when distributing code or executables that merely use boost, i can't find any obligation...or what is it that i overlooked?

(L) [2007/09/13] [jogshy] [multithreading: OpenMP or Boost::Thread?] Wayback!

OMP is very good, easy and multiplatform but:

1) You cannot set the thread priority.

2) Requires compiler support.

3) You cannot control too much the thread launch manually...OpenMP is good for parallel computing, not for heterogeneous multithreaded programming.

System threads(pthreads, windows threads) seems to be more flexible. I usually don't like Boost because occupies too much and can be obscure to program. For license doubts see [LINK http://www.boost.org/more/license_info.html]

About the Intel thread blocks API I didn't touch it yet so cannot tell you... I seriously doubt would be optimized for AMD processors...

On the other hand, Intel is preparing a new parallel language called "Ct", some people say it's for the upcoming Larrabee CPU/GPU:

[LINK http://download.intel.com/pressroom/kits/research/Flexible_Parallel_Programming_Ct.pdf]
_________________
I know I ask too much... but i'm on panic mode and there is no panic button to press [SMILEY stick out tongue]

(L) [2007/09/13] [cignox1] [multithreading: OpenMP or Boost::Thread?] Wayback!

Hi again, thank you for your help. I must say that I don't know Boost except than for the threading api, wich is (or at least appear to be) reasonably easy to manage. It require the app to be heavily designed with multithreading in mind (not necessarily a bad thing though).

I won't use OS dependant features for the engine core if I can avoid this and since I wasn't able to find an open source, portable basic plug in management system (basically loading dynamic libraries) to make the RT expandable, I would like to stay away from other OS dependant libs.

All in all, I still think that OpenMP is the best option. Any more thoughts?

P.S. I will definitely give a look to that Ct thing. IIRC Larrabee is planned for 2009, so this is my chance to be already ready when a new technology comes out.

(L) [2007/09/13] [Zakalwe] [multithreading: OpenMP or Boost::Thread?] Wayback!

OMP is fine for simple things like loops. It's not very helpful in the case of finely grained locking. For things like that I use pthreads. Linux has exemplary support for pthreads throught NPTL and it's VERY fast.

(L) [2007/09/16] [phkahler] [multithreading: OpenMP or Boost::Thread?] Wayback!

Just tried OMP a couple weeks ago. Simplest thing in the world. OTOH I had designed my ray tracer for parallel execution since way back. No data in the scene is written during rendering, and everything for a given ray/pixel is stored in a "ray" object. I just need to have one ray object per thread and it will just work. So when I got the dual core and tried OMP, all I had to do is make an array of rays, add "#pragma omp for" ahead of a loop, move a few local variables inside the loop so there will be one per thread, add a call to omp_get_thread_num() or whatever to get the ray number/thread num to use inside the loop. Add -fopenmp to the compiler flags and link gomp.

Wow, that sounds like a lot of steps for something that I generally think of as "adding a pragma". But it was all very easy. I'm running Fedora 7 and it puts both cores at about 90% load.
_________________
--Paul

The OctTree Guy

(L) [2007/09/16] [lycium] [multithreading: OpenMP or Boost::Thread?] Wayback!

curiously, it's omp_get_num_procs() - i tried the threads one and it returned 1 instead of 2 on my dualcore (?!).

welcome to the forums paul, i remember your realtime ray tracing programs from back when, still have a few of them ;)

(L) [2007/09/16] [calamari] [multithreading: OpenMP or Boost::Thread?] Wayback!

omp_get_num_procs() returns the number of cores, omp_get_num_threads() returns the number of currently running threads (so it's one if you're not inside a omp pragma block). omp_get_thread_num() returns the ID of the current thread. So that behaviour described by greenhybrid is by design [SMILEY Smile].

(L) [2007/09/16] [lycium] [multithreading: OpenMP or Boost::Thread?] Wayback!

i definitely wouldn't send a non-bug report to gcc team about msvc, especially before reading the spec ;)

[LINK http://www.openmp.org/drupal/mp-documents/cspec20_bars.pdf]

multithreading: OpenMP or Boost::Thread? back