[cctbxbb] Removal of Boost.Thread support

[Phzwart]

Hi Jeffrey,

You can now include Cuda code in the cctbx as well. You can call your Cuda routines from a c++ function that has python bindings generated by boost.python.

There should be some example code available on how to do this. A -- enable-cuda during config is required.



P

Sent from my iPad

On Aug 15, 2012, at 7:21, Jeffrey Van Voorst <vanv0059 at umn.edu> wrote:

> 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
>> cctbxbb at phenix-online.org
>> 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
> _______________________________________________
> cctbxbb mailing list
> cctbxbb at phenix-online.org
> http://phenix-online.org/mailman/listinfo/cctbxbb