NONMEM Users Network Archive

Hosted by Cognigen

RE: NONMEM memory vs. run time

From: Elassaiss - Schaap, J. <jeroen.elassaiss>
Date: Mon, 8 Sep 2008 20:27:07 +0200

Nick,
 
Now I spot it indeed. And I certainly will give it a go, as I have never
seen this big/small difference - actually hoped you would have an answer
ready.

Swapfile time: depends on other applications running, memory demands and
the actual memory access. During my PhD I have had to program against
swap-file behaviour often enough, so I wouldn't be surprised by 5
seconds. On the other hand, that was several years ago ....

Jeroen

________________________________

From: Nick Holford [mailto:n.holford
Sent: Monday, 08 September, 2008 20:14
To: Elassaiss - Schaap, J. (Jeroen)
Cc: nmusers
Subject: Re: [NMusers] NONMEM memory vs. run time


Jeroen,

The executable building was explicitly excluded (please read my previous
email carefully). I cannot say how long it takes to create a swapfile
but I would be surprised if it took 5 seconds.

If you want to know if these results scale with model runtime and other
variables such as available RAM then I suggest you try it on your
datasets. I did this a long time ago and made it easy with WFN to build
and switch between different sizes of NONMEM according to the problem.
That way I dont need to waste time running test problems :-)

Nick

Elassaiss - Schaap, J. (Jeroen) wrote:

        Nick,
        
        Interesting observations. I however wouldn't be surprised if the
        additional 4-5 seconds would be due to I/O activities (swapfile,
        executable building etc.) rather than calculations. How do these
        differences scale with model runtime, i.e. for models than run
hours
        rather than minutes, does the big/small nonmem difference
increase from
        seconds to minutes?
        
        Best regards,
        Jeroen
        
        J. Elassaiss-Schaap
        Scientist PK/PD
        Clinical Pharmacology and Kinetics
        Schering-Plough
        PO Box 20, 5340 BH Oss, Netherlands
        Phone: + 31 412 66 9320
        Fax: + 31 412 66 2506
        e-mail: jeroen.elassaiss
        
        
        
        -----Original Message-----
        From: owner-nmusers
[mailto:owner-nmusers
        On Behalf Of Nick Holford
        Sent: Monday, 08 September, 2008 17:12
        To: nmusers
        Subject: Re: [NMusers] NONMEM memory vs. run time
        
        Leonid, Darin,
        
        Here are some experimental results rather than theoretical
predictions.
        I ran a problem (ADVAN6) with two 'sizes' of NONMEM created with
NMQUAL
        using Wings for NONMEM. The 'std' size is the default NONMEM
        configuration. The '570' size is close to the 'big' version
provided
        with NMQUAL. I ran the problems with an Intel core duo processor
with 1
        Gb RAM compiled with Intel Fortran version 10.1024. I used
NONMEM VI 2.0
        
        installed with NMQUAL-6.3.2 and Windows XP.
         
        I tried each size of problem two times. Run times exclude
NM-TRAN and
        the compile/link step. You will see that the bigger NONMEM size
took 5%
        longer to complete. There were no page faults visible with the
Task
        Manager using either size.
        std =Mem Usage 51.1 M byte VM Size 97.1 Mbyte
Runtimes: 80.88
        sec/ 81.82 sec
        570=Mem Usage 199.8 M byte VM Size 1107.9 Mbyte Runtimes:
84.10
        sec/ 87.22 sec
        
        These results are similar to those I have observed before. The
bigger
        versions of NONMEM run more slowly. This is why I prefer to
match the
        NONMEM size to the problem size. For smaller problems (fewer
parameter,
        fewer obs/subject) I use the std size. For bigger problems WFN
allows a
        choice to increase either parameters, obs/subject or both.
        
        Nick
        
        Darin Perusich wrote:
          

                The increase in memory consumption doesn't impact
runtime positively
                or negatively, unless of course your system doesn't have
enough
                physical memory to accommodate the increase. NONMEM's
memory footprint
                    

        
          

                is directly related to the buffer values in the SIZES
file, as you
                increase the values the memory footprint increases to
accommodate.
                
                In the end processor speed is really the only thing that
positively or
                    

        
          

                negatively effects NONMEM runtime.
                
                Leonid Gibiansky wrote:
                    

                        Dear All,
                        I noticed that the Nonmem installed with NMQUAL
"big nm6" defaults
                        instead of the standard ones results in
approximately 10-times
                              

        increase
          

                        in the memory required to run Nonmem (on my
recent problem, from 12
                              

        MB
          

                        to 140 MB). I am wondering whether anybody
checked how this
                              

        influences
          

                        the run time. Is it better (in terms of the run
time) to use standard
                        sizes, or "big" is OK if you have enough RAM?
                        Thanks!
                        Leonid
                        
                              

        
          


--
Nick Holford, Dept Pharmacology & Clinical Pharmacology
University of Auckland, 85 Park Rd, Private Bag 92019, Auckland, New
Zealand
n.holford
http://www.fmhs.auckland.ac.nz/sms/pharmacology/holford


This message and any attachments are solely for the intended recipient. =
If you are not the intended recipient, disclosure, copying, use or =
distribution of the information included in this message is prohibited =
--- Please immediately and permanently delete.
Received on Mon Sep 08 2008 - 14:27:07 EDT

The NONMEM Users Network is maintained by ICON plc. Requests to subscribe to the network should be sent to: nmusers-request@iconplc.com.

Once subscribed, you may contribute to the discussion by emailing: nmusers@globomaxnm.com.