Dear experts...
We noticed that a NONMEM job (using NONMEM 7.1.2) runs much slower in
Windows 7 loaded on a new HP workstation (z600 with >32GB RAM, Intel, 12
core CPU) when compared to running in Redhat Linux RHEL 5 on a 2 year old
HP workstation (32 GB RAM, Intel 8 core CPU). It takes longer time to reach
complete the first iteration with NONMEM on Windows 7.
Can anyone please suggest possible reasons for runs being slow in Windows?
Thanks,
Santosh
NONMEM 7.1.2 run time in Windows 7
4 messages
3 people
Latest: Mar 12, 2011
Hi Santosh,
One thing you didn't mention was the compiler. If you have an Intel
compiler, things will typically run much faster.
Thanks,
Bill
Quoted reply history
From: [email protected] [mailto:[email protected]]
On Behalf Of Santosh
Sent: Thursday, March 10, 2011 10:01 AM
To: [email protected]
Subject: [NMusers] NONMEM 7.1.2 run time in Windows 7
Dear experts...
We noticed that a NONMEM job (using NONMEM 7.1.2) runs much slower in
Windows 7 loaded on a new HP workstation (z600 with >32GB RAM, Intel, 12
core CPU) when compared to running in Redhat Linux RHEL 5 on a 2 year
old HP workstation (32 GB RAM, Intel 8 core CPU). It takes longer time
to reach complete the first iteration with NONMEM on Windows 7.
Can anyone please suggest possible reasons for runs being slow in
Windows?
Thanks,
Santosh
I wasn't aware that there was a 12 core Intel CPU - maybe you have a dual processor 6 core? If you have a 12 core AMD CPU, you should be aware that this only has 6 floating point cores. In addition, if you use the Intel compiler with AMD CPUs, Intel cleverly disables all optimization, so the CPU seems slow (one of the many antitrust lawsuits AMD currently has against Intel). But, benchmarks and my experience suggest that AMD CPUs are substaintially slower than Intel, and, for us at least, 12 core AMD CPUs aren't really 12 core. 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
Quoted reply history
-------- Original Message --------
Subject: RE: [NMusers] NONMEM 7.1.2 run time in Windows 7
From: "Denney, William S." < [email protected] > ;
Date: Thu, March 10, 2011 10:42 am
To: "Santosh" < [email protected] >, < [email protected] >
Hi Santosh, One thing you didn’t mention was the compiler. If you have an Intel compiler, things will typically run much faster. Thanks, Bill From: [email protected] [ mailto: [email protected] ] On Behalf Of Santosh Sent: Thursday, March 10, 2011 10:01 AM To: [email protected] Subject: [NMusers] NONMEM 7.1.2 run time in Windows 7 Dear experts... We noticed that a NONMEM job (using NONMEM 7.1.2) runs much slower in Windows 7 loaded on a new HP workstation (z600 with >32GB RAM, Intel, 12 core CPU) when compared to running in Redhat Linux RHEL 5 on a 2 year old HP workstation (32 GB RAM, Intel 8 core CPU). It takes longer time to reach complete the first iteration with NONMEM on Windows 7. Can anyone please suggest possible reasons for runs being slow in Windows? Thanks, Santosh
We noticed that gfortran installed on Windows 7 and Linux workstations are
32-bit and 64-bit, respectively. Are there ways to install 64-bit gfortran
Quoted reply history
on Windows 7?
Regards,
Santosh
On Thu, Mar 10, 2011 at 9:42 AM, Santosh <[email protected]> wrote:
> I forgot to mention..
>
> Fortran compiler: gfortran 4.5.0
> The new workstation has dual Intel Xeon 6-core CPUs
>
> Thanks,
> Santosh
>
> On Thu, Mar 10, 2011 at 7:01 AM, Santosh <[email protected]> wrote:
>
>> Dear experts...
>> We noticed that a NONMEM job (using NONMEM 7.1.2) runs much slower in
>> Windows 7 loaded on a new HP workstation (z600 with >24 GB RAM, Intel, 12
>> core CPU) when compared to running in Redhat Linux RHEL 5 on a 2 year old
>> HP workstation (24 GB RAM, Intel dual quad core CPUs). It takes longer time
>> to reach complete the first iteration with NONMEM on Windows 7.
>>
>>
>> Can anyone please suggest possible reasons for runs being slow in Windows?
>>
>>
>> Thanks,
>> Santosh
>>
>
>