From: Axel Kohlmeyer (akohlmey_at_gmail.com)
Date: Wed May 11 2011 - 11:16:29 CDT
jim,
there is one more item that comes to my mind that we discovered
a long time ago when investigating why certain code constructs in
LAMMPS broke with gcc 4.x but not with intel or gcc 3.x.
gcc 4.x assumes that ansi aliasing rules are obeyed and then
enables additional optimizations (that are safe, iff the code is
following the standard). assuming that the NAMD code is standard
compliant, then using the flag "-ansi-alias" with intel compilers
might give you another little performance boost. on LAMMPS with
tabulated potentials it was of the order of 5% (after we fixed the
offending code).
cheers,
axel.
On Wed, May 11, 2011 at 11:53 AM, Jim Phillips <jim_at_ks.uiuc.edu> wrote:
>
> I meant more conservative in the sense of not breaking code, but Axel's
> suggestion is correct. Changing -O3 to -O2 and adding -no-vec improves
> performance on newer compilers without hurting it on the old ones. I also
> bumped -march up from pentiumpro to pentium4 on 32-bit builds to enable some
> explicit SSE2 code. I think ten years is long enough to wait.
>
> -Jim
>
> On Tue, 10 May 2011, Axel Kohlmeyer wrote:
>
>> On Tue, May 10, 2011 at 9:32 PM, Jim Phillips <jim_at_ks.uiuc.edu> wrote:
>>>
>>> I have also observed that the Intel 11.1 compilers produce slower NAMD
>>> builds than the old 9.0 compilers, even for the latest processors. I'm
>>> guessing the compiler is now more conservative in some optimization, but
>>> I
>>> don't know what it is or how to work around it yet.
>>
>> jim, i believe the opposite is the case. the newer intel compilers
>> are optimizing much more aggressively and particularly seem to
>> try utilizing the vector instructions much more aggressively,
>> often seems to be enefficient, since the data they operate on
>> is not properly aligned. i often get faster executables by lowering
>> optimization levels and optimizing for pentium pro (on 32-bit)
>> and pentium 4 instruction set, but using core2 or nehalem heuristics
>> (-march / -mtune).
>>
>> cheers,
>> axel
>>>
>>> You must use the same compiler and version for Charm++ and NAMD or you
>>> are
>>> likely to see errors like those below because of incompatibilities in the
>>> C++ application binary interface (ABI), which is not standardized.
>>>
>>> -Jim
>>>
>>> On Mon, 9 May 2011, TAO WANG wrote:
>>>
>>>> Another question is when I user intel compilers 9.1 to compile
>>>> NAMD_2.8b1,
>>>> I got the following error
>>>> ld: Cpv_iout_obj_: TLS reference in obj/main.o mismatches non-TLS
>>>> reference in obj/common.o
>>>> obj/main.o: could not read symbols: Bad value
>>>>
>>>> But I can not find Cpv_iout_obj in source files
>>>>
>>>> TAO
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------------------------
>>>> Dr. Tao Wang
>>>> Ph.D. @ University of Science and Technology of China, Computational
>>>> Chemistry
>>>>
>>>> Manager
>>>> Dept. of HPC Application Technology
>>>> Shanghai Supercomputer Center
>>>> No.585 Guoshoujing Rd., Pudong, Shanghai 201203, P.R.C.
>>>> Phone: (86)-21-50802779
>>>> Cell: 13601984020
>>>> Fax: (86)-21-50801265
>>>> e-mail: twang_at_ssc.net.cn
>>>> http://www.ssc.net.cn
>>>>
>>>>
>>>> -----邮件原件-----
>>>> 发件人: owner-namd-l_at_ks.uiuc.edu [mailto:owner-namd-l_at_ks.uiuc.edu] 代表 johan
>>>> strumpfer
>>>> 发送时间: 2011年5月6日 22:10
>>>> 收件人: Norman Geist
>>>> 抄送: TAO WANG; Namd Mailing List
>>>> 主题: Re: namd-l: compilation of namd
>>>>
>>>> Hi Tao,
>>>>
>>>> Jim would have to correct me here, but as far as I know there are no
>>>> additional compiler flags specified (i.e. other than those in
>>>> arch/*.arch) for the binaries on the website. According to my
>>>> knowledge version 9.0.30 of the intel compilers were used for those
>>>> builds.
>>>>
>>>> Cheers,
>>>> Johan
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------------------------------
>>>> Johan Strumpfer: johanstr_at_ks.uiuc.edu
>>>> www.ks.uiuc.edu/~johanstr
>>>> Theoretical and Computational Biophysics Group
>>>> 3115 Beckman Institute
>>>> University of Illinois at Urbana-Champaign
>>>> 405 N. Mathews
>>>> Urbana, IL 61801, USA
>>>>
>>>>
>>>> ------------------------------------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> On Fri, May 6, 2011 at 1:16 AM, Norman Geist
>>>> <norman.geist_at_uni-greifswald.de> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> no I don’t know their flags, but I think you could just ask them. I
>>>>> can’t
>>>>> imagine any reason why they shouldn’t tell you. But it’s always better
>>>>> to
>>>>> get a little into the things, to understand what the flags do and where
>>>>> they
>>>>> could have an impact.
>>>>>
>>>>>
>>>>>
>>>>> Best regards
>>>>>
>>>>>
>>>>>
>>>>> Norman Geist.
>>>>>
>>>>>
>>>>>
>>>>> Von: owner-namd-l_at_ks.uiuc.edu [mailto:owner-namd-l_at_ks.uiuc.edu] Im
>>>>> Auftrag
>>>>> von TAO WANG
>>>>> Gesendet: Freitag, 6. Mai 2011 07:57
>>>>> An: 'Norman Geist'
>>>>> Cc: 'Namd Mailing List'
>>>>> Betreff: ??: namd-l: compilation of namd
>>>>>
>>>>>
>>>>>
>>>>> Thank you
>>>>>
>>>>> But, do you know how namd’s guy compile the binary version
>>>>> Linux-x86_64-ibverbs on namd’s website ?
>>>>>
>>>>> What is their compiler flags ?
>>>>>
>>>>> TAO
>>>>>
>>>>>
>>>>>
>>>>> 发件人: owner-namd-l_at_ks.uiuc.edu [mailto:owner-namd-l_at_ks.uiuc.edu] 代表
>>>>> Norman
>>>>> Geist
>>>>> 发送时间: 2011年5月6日 13:46
>>>>> 收件人: 'TAO WANG'
>>>>> 抄送: Namd Mailing List
>>>>> 主题: AW: namd-l: compilation of namd
>>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> well, there are many compiler flags that can increase performance, and
>>>>> also
>>>>> the opposite. You could try the auto optimization levels like –O3 for
>>>>> example, I think the icc must have parameters like this. But to high
>>>>> optimization levels can come with unstable binarys or bad portability.
>>>>> U
>>>>> can
>>>>> also try to fit the compilation to your hardware, but that also
>>>>> restrict
>>>>> portability, if you want to run the same binary on different
>>>>> architectures
>>>>> like amd -> intel, or Xeon -> opteron. But you should really try the
>>>>> optimization flags.
>>>>>
>>>>>
>>>>>
>>>>> Mit freundlichen Grüßen
>>>>>
>>>>>
>>>>>
>>>>> Norman Geist.
>>>>>
>>>>>
>>>>>
>>>>> Von: owner-namd-l_at_ks.uiuc.edu [mailto:owner-namd-l_at_ks.uiuc.edu] Im
>>>>> Auftrag
>>>>> von TAO WANG
>>>>> Gesendet: Freitag, 6. Mai 2011 04:09
>>>>> An: namd-l_at_ks.uiuc.edu
>>>>> Betreff: namd-l: compilation of namd
>>>>>
>>>>>
>>>>>
>>>>> Dear all,
>>>>>
>>>>> I have successfully compiled namd 2.8b1 by the following command
>>>>>
>>>>>
>>>>>
>>>>> ./build charm++ net-linux-x86_64 iccstatic ibverbs ifort
>>>>> --no-build-shared
>>>>> --with-production
>>>>>
>>>>> ./config Linux-x86_64-icc --charm-arch
>>>>> net-linux-x86_64-ibverbs-ifort-iccstatic --cxx icpc
>>>>>
>>>>>
>>>>>
>>>>> And this version run well.
>>>>>
>>>>>
>>>>>
>>>>> Then I download the binary version Linux-x86_64-ibverbs of namd 2.8b1
>>>>>
>>>>>
>>>>>
>>>>> I found this version is faster than my compiled version by 10%
>>>>>
>>>>>
>>>>>
>>>>> My complier is ifort and icc 11.1
>>>>>
>>>>>
>>>>>
>>>>> Is there anyone knows how they compile the binary version
>>>>> Linux-x86_64-ibverbs on namd’s website, so that their version is faster
>>>>> than
>>>>> mine ?
>>>>>
>>>>> Thanks
>>>>>
>>>>> TAO
>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Dr. Axel Kohlmeyer
>> akohlmey_at_gmail.com http://goo.gl/1wk0
>>
>> Institute for Computational Molecular Science
>> Temple University, Philadelphia PA, USA.
>
-- Dr. Axel Kohlmeyer akohlmey_at_gmail.com http://goo.gl/1wk0 Institute for Computational Molecular Science Temple University, Philadelphia PA, USA.
This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:57:06 CST