Hi Robert, Robert Jones wrote:
- In some ways this is an alternative to Boost thread pools. - Using explicit pragmas is an intermediate step, and ultimately it might be hoped that a compiler would be able to do all this without external direction. - The whole OpenMP notion is too specific for a general library like Boost
I, too, have used OpenMP and noticed significant improvements by using it. It would be nice if Boost supported it. I'm not very knowledgeable in OpenMP or threads -- but I won't let that stop me from giving an opinion. :-) I have never used Boost.thread before, but looking at its documentation now, it looks like its purpose is to allow developers to create multithreaded software from scratch. So, various functions are needed to manage communication between threads, etc. On the other hand, OpenMP's strength is to allow users to take a sequential program and parallelize it by indicating which variables [in a loop, etc.] do not conflict with each other. So, as for point #1, I don't think it is an alternative to threads -- their motivations are slightly different. As for your second point, I don't know what compiler research is nowadays, but I would think it would be difficult to determine automatically if two variables will never conflict. In fact, doing it by hand with OpenMP, I got it wrong once or twice -- poor eyesight + poor variable names. :-) Putting this together, I think OpenMP isn't the same as Boost.threads or even Boost.mpi and I'm not so sure how Boost could fit with OpenMP -- it seems more suitable as pragmas to the compiler. However, I don't mind being proved wrong as something more Boost-like might be more intuitive to users than the #pragmas... Ray