A sidepoint from GPU development - and directly related to Geoff's earlier point.
Perhaps multicore awareness is the way to go... In the most reductionist of approaches -- you could launch n threads (instead of one) and have each generate a conformer each since these are really independent processes. This way the time enhancement would be close (but not quite) 1/n. I'd imagine you would still do some aggregation at the end of conformer generation (e.g. cluster results and remove very similar conformers)... My rationale for this is that everyone has a multi core processor (and if you don't, throw away that piece of historical junk), but not everyone has a CUDA/OpenCL enabled video card. Even in the terms of re architecture needed -- it is ""easier"" to move the code into threads than having to rewrite it as a kernel for the GPU. Just a thought. - Jean-Paul Ebejer Early Stage Researcher On 12 July 2012 18:29, ovalerio <omar.valerio-min...@ichec.ie> wrote: > Hi Chris, > > > On 12.07.2012 13:16, Geoff Hutchison wrote: >>> >>> I've just seen a demo of the impact of running applications on the GPU >>> and it does seem for some operations you can get striking performance gains. >>> Would it be worth considering porting openbabel to OpenCL? >> >> >> Much like muti-threading, it's not clear how some operations in Open >> Babel would work in OpenCL. > > > As Geoff points out they are couple of factors to consider in this regard. > Sometimes making algorithmic changes can boost performance even more than > going the GPU way. In my case however, I'm interested in optimization > through parallel approaches. That's why I'm researching on GPU and I will be > very glad to hear whatever ideas you might have. > > >> >> That said, there are certain types of code which make clear sense as >> multi-threaded and/or OpenCL, for example the force fields and >> conformer generation code, or the charge assignment. There's actually >> a student in Ireland sponsored by Noel who's investigating this as we >> speak. (You may have seen some posts from Omar already.) >> > > I have look at force fields and conformer generation codes since they are > both related. When you are doing conformational search you also need to > asses the energy of the conformer to decide if you are going to keep it. > Improving forcefields calculation should also improve performance for > conformer generation. > > Conformer generation also looks promising, Attached you can find a plot of > the time spent generating conformers for several different drug like > molecules using Confab [1]. I used the optimized Borodina set that you can > get from Confab's article [2]. As you can appreciate from the plot as the > number of conformers involved increases, execution times for conformational > search increases noticeably. I will be happy if I can shave those numbers by > a half factor offloading some operations to the GPU. > > Cheers, > -- > Omar > > [1] Confab - http://confab.googlecode.com/ > [2] Confab Article (Borodina Optimized Set) - > http://www.jcheminf.com/content/3/1/8 > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > OpenBabel-discuss mailing list > OpenBabel-discuss@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openbabel-discuss > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ OpenBabel-discuss mailing list OpenBabel-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
