Re: [NMusers] GPU port for NONMEM

[Xavier Woot de Trixhe]

Hi,     I have to disagree with your conclusions.     Last year a POC software was implemented in CUDA to check the concept rather than speculate about the subject.     This POC used the SAEM algorithm an a fairly simple PK model: single dose and analytical function.      From this exercise it became clear that:         - The data is a lot less dissimilar than you imply. All the data fits in a 2D csv file which can hardly be qualified as a complex data structure and as every individual has the same number of parameters...           - The computation of IPREDS for analytical models is almost trivial and for ODE's one can start with simpler, less efficient (fixed step) ODE-solvers and is be able to expect an improvement.         - The limited "memory per core" is the memory shared by threads this is used for memory optimization not to keep the whole problem. The main memory on is up to 4 Gigs which far exceeds the "1-2 Gig per NONMEM run" rule of thumb.                   Our POC-soft was close to 30x speed increase compared to our reference (CPU: core i7 940 @2.93 GHz | GPU: nVidia GTX 285 -$500-) without even using within individual parallelisation. Which could in theory result in a total 240x speed-up.     Where we agree is that NONMEM would probably need be rewritten almost from scratch.        So although it could (should) be done; from a programmers p.o.v. the resulting soft would no longer be NONMEM. K. Regards Xavier On 03/16/2011 03:00 AM, Mark Sale - Next Level Solutions wrote: GPU was considered in the work leading up to the upcoming parallel NONMEM.  GPU computing is intended essentially for very simple algorithms applied to a large number of very similar data sets (things like bit shifting everything left, or adding a number to every value of a matrix).  Really not well suited to the NONMEM algorithm (at least the time consuming part, which is the calculation of predictions).  Most GPUs don't have nearly enough memory per core to run NONMEM in the way that it will be parallelized (which basically runs the entire PRED, just on subset of the data). We tried really hard to think of a way to do NONMEM with GPU, even consulted with a GPU computing expert at University of North Carolina, and couldn't come up with a way to do it, and even if the memory requirement could be addressed, would be a significant rewrite of NONMEM code.  But, mainly it wasn't clear to us how the algorithm could be broken up into pieces small enough for GPU computing. But, never say never. Mark Sale MD President, Next Level Solutions, LLC www.NextLevelSolns.com 919-846-9185 A carbon-neutral company See our real time solar energy production at: http://enlighten.enphaseenergy.com/public/systems/aSDz2458 -------- Original Message -------- Subject: [NMusers] GPU port for NONMEM From: "Amr Ragab" <amrra...@gmail.com> Date: Tue, March 15, 2011 9:01 pm To: <nmusers@globomaxnm.com> Hello NMUsers, Wanted to ask what has been done in terms of utilizing the bank of various GPU architecture available. Currently I have access to a few Tesla NVIDIA cards(w/ double precision math). I know PGI has worked out a solution using NVIDIA's CUDA toolkit to create a C++/Fortran complier that uses GPU. Unfortunately NONMEM SETUP7 script doesn't include an install script to utilize PGI's fortran. I managed to get through some Windows trickery for NONMEM to think it opens the intel fortran compiler but instead opens CUDA fortran....but it's not a permanent solution.   That of course would be first step, as the ideal solution would be that the entire NONMEM program would be optimized for GPU. And it looks like there is a performance benefit for large datasets or calling nmfe7 for multiple runs..   Thanks Amr -- Exprimo NV This e-mail is confidential. It is also privileged or otherwise protected by work product immunity or other legal rules. The information is intended to be for use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. You should therefore delete this message from your computer system. If you have received the message in error, please notify us by reply e-mail. The integrity and security of this message cannot be guaranteed on the Internet. Thank you for your co-operation.