🔒 Locked

Multithreading, which one?

Started by lefthandman May 7, 2009 at 9:21 AM 1 replies 950+ views

Original Post

May 7, 2009 at 9:21 AM

Ok, I am trying to get the most out of my current project, and so I decided that rather than optimize on a single core, why not add multiple cores? So with that in mind I looked for ways to do such a thing. It seems to be a necessity to have a library for this because afaik it's not implemented directly with MSVC++. So, after a while I came across the following. OpenMP - This seems to be one of the largest, yet *SHOCK* MSVC++ is running an out of date version! The current version 3.0 isn't supported and it only goes up to 2.5 . Since I want to get familiar with a library, and continue to use it in other projects, this seems suboptimal. I mean of course with the next release, maybe they'll use the current spec, but maybe not... Cilk++ - This looks the most abstracted of the three. It seems to have a semi-large community although it doesn't look like it's being used for real time optimizations. The idea of a scheduler seems clunky. Intel TBB - Sort of like an abstracted OpenMP it seems. I just wonder if this has some intel-induced limitations, or recquires omp 3. In general I'm aiming for the following in the order they appear: Portable (Windows, Mac, Linux) - We never know which'll come out on top... Fast (Real-time) - My preferred area of study. Community (Preferably large) - Small communities make for a cold, unfriendly feeling when developing. In general, my main concern with these are their speed, I'm pretty sure they're all portable.

Kylotan

May 8, 2009 at 8:58 AM

Quote:
Original post by lefthandman
Ok, I am trying to get the most out of my current project, and so I decided that rather than optimize on a single core, why not add multiple cores? So with that in mind I looked for ways to do such a thing. It seems to be a necessity to have a library for this because afaik it's not implemented directly with MSVC++.

Not exactly. Threads are platform specific, but every compiler you can use will have some provision for them. Generally a library just helps to unify the interface so that it becomes platform independent (for the most part). Some of the higher level libraries, like the ones you list, try and layer some sort of task or scheduler system over the top, but I'm not convinced they add much value. Cilk++ especially seems to be aimed at management rather than coders, which doesn't surprise me.

You could also avoid using multiple threads and instead use multiple processes, which is safer and more scalable to distributed systems. But it's not always suitable, depending on what you're doing.

Quote:
In general, my main concern with these are their speed, I'm pretty sure they're all portable.

Given that 99% of multi-threading approaches are little more than wrappers around OS-level primitives, the speed is going to be pretty much identical for all of them. What becomes important in practice is how you use them, as efficiency will come mostly from your synchronisation needs, and there's nothing a library can do to make that faster or slower, just more convenient.

Personally, if I was using C++ I would just use Boost Threads, which is closely aligned with the future C++ threading standard. It's quite low level but with careful use that's not a problem.

lefthandman

May 8, 2009 at 9:18 AM

Thank you Kylotan,
I am trying out Boost.Threads, but wow boost is huge.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.