OpenMP vs Threading

Can you decompose your problem in a manner best suited for OpenMP? If yes, then use that.

The alternative (threads) is not an alternative, but technology. It's like comparing Series X BMW vs. cars, which is better? A BMW is obviously a car as well.

You can use threads to simulate concurrency, how exactly however depends on the approach you choose.

Designing a concurrent engine ad-hoc isn't possible. You can obviously use threads, and then just lock as needed, but you'll be sorely disappointed. Instead, you'll first need to design your engine in a concurrent manner, then find which implementation suits which part.

Search gamasutra for "concurrency". There's a large number of articles discussing delicate design aspects, and they cover everything from various extremes such as Erlang, to various pitfalls, as well as coding techniques.

Thanks for your reply, I don't know if it has anything to do with my post, but thanks.

Quote:

Original post by TheMac Thanks for your reply, I don't know if it has anything to do with my post, but thanks.

Yes it has. Because AFAIK OpenMP cannot be used as a full featured threading library. The compiler will split marked blocks of code into multiple processes. If everything you need is peforming millions of unrelated matrix multiplications, then you mark the loop as splittable and the compiler will generate multithreading code. As far as I know you cannot do really a lot more than this.
If you need to handke complex tasks (shared memory, synronization, locks and so on) you may want to give a look to boost:thread. It is easy to use, cross platform and powerful.

Quote:

Original post by TheMac Thanks for your reply, I don't know if it has anything to do with my post, but thanks.

Yes, it has.

The problem you're trying to solve is that of concurrency. The answers there simply aren't that simple as "library X is the best". Here's Herb Sutter's take on it, pointing out certain problems that the entire software industry is facing right now, and scratching their heads over it.

Things really aren't that simple.

I'm not looking for a library to use, more of when to use my own threading, and when to use OpenMP. It looks like I should never use OpenMP if I what to everything out of the CPUs as possible.

Thanks.

Quote:

I'm trying to find out what are the advantages with openmp over manually creating and managing threads other then the being easier to code.

That's the biggie right there :) Parallelization is tricky enough that any help is welcome.

Quote:

So far this is what I have: the overhead with openmp is greater then using pthreads, or windows api threading, but I don't know by how much.

Various publications have shown that anything that can easily be mapped to OpenMP's constructs incurs no measurable overhead vs. manual threading.

Quote:

If I use openmp, I don't know how to keep the threads it uses open and ready to be used again. Instead I'm guessing it creates new threads everytime its called.

No worries, it manages a thread pool.

Quote:

As far as I know you cannot do really a lot more than this.

There are also parallel sections (for task-parallel coding) and manual locks. A task queue is coming in OpenMP 3.0.

Quote:

It looks like I should never use OpenMP if I what to everything out of the CPUs as possible.

hehehe. OpenMP is to threads as HLLs are to assembly language. In the latter case, you can only see big gains if the language is incapable of expressing certain hardware concepts (e.g. carry flag, certain details of bulk memory transfers, etc.). The correct question is that which Antheus has already put forward: does the OpenMP abstraction adequately cover what you're trying to do? If so, it would be folly to use manual threading.

Quote:

Original post by TheMac what are the advantages with openmp over manually creating and managing threads other then the being easier to code.

It would be likely that the compiler is able able to optimize more than manual threading.
(Although I cannot proof)

The scheduling algorithms are most likely better than the ones created by mere humans. (Depends on the skill of the openmp-user ofc)

Most openmp codes are easier to read, since to problem has to be decomposed cleanly, where the threading programmer, uses global variables, and other nasty stuff to make it work.

OpenMP makes it easy to go data parrallel.

Some questions you should consider.
- What parts of your multi-threaded engine will benefit from parralisation?
- Functional or data parrallel?
- What is the targeted arhictecture?
- What sort of scalability are you thinking of?
- 'best path for me', is this commerical or to learn/for fun?
- Why did you choose OpenMP?

It doesnt really answer you questions but parrallel computing is all about tradeoffs and its imperitive you know why your making certain decisions.

And to find out, you can try both and compare speedup ;-)

This is the kind of feed back I'm looking for. Thanks guys for your input, I think I'll go with OpenMP for now and if I can making my own code faster I will code my own threading helper.

Thanks!