On 8/13/12 10:50 PM, Luc Bourhis wrote:
Hi fellow cctbx developers,
I am going to ditch support for Boost.Thread and therefore to remove the SF computation parallelised with Boost.Thread as well. Parallelisation at the C++ level should be done with OpenMP: Boost.Thread was merely an early experimentation that was kept alive for no particularly good reasons. If anybody disagrees with that move, please voice your opinion now.
Best wishes,
Luc J. Bourhis
_______________________________________________ cctbxbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/cctbxbb
I have been lurking on this mailing list for a bit. I am very interested in and have some practical experience with OpenMP and Nvidia CUDA programming. I work on such projects both to make use of modern hardware on typical single user machines, and because, I find it fun. I have found OpenMP to be rather easy to setup and gain good speedup, but it is generally very difficult to get close to the maximum theoretical performance (N cores gives a speedup of N) for relatively short computations (less than 1 second). I have several questions (that I know may not have simple answers): 0) Is there a public roadmap or recent plan of how to proceed? 1) Does the cctbx developers community take kindly to others meddling in the code? 2) For which types of machines would one be trying to tune cctbx's OpenMP code? In general, the tradeoffs are different for machines with a small number of cores versus a massive shared memory platform (1000s of cores). 3) What is the primary motivation? (e.g. have easy to extend code that make use of more cores because they are there? or highly efficient methods that scale very well -- 12 cores should give as close as possible to 12x speedup with respect to 1 core) --Jeff