Hi,
On Mon, Feb 01, 2010 at 10:12:33PM -0500, Volodymyr Babin wrote:
> > 1. Is anyone still familiar with the Large File support in Linux? My
> > questions are about the flags
> >
> > -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> >
> > added by configure. Specifically:
> >
> > a. Aren't these only needed for x86 (32-bit) compiles? Do we need them
> > for x86-64 (em64t)?
> > b. My Googling seems to indicate that only the first flag is required, not
> > the second one; might this be true? Does anyone have a test of this
> > functionality?
>
> I am not familiar, but googling/looking into /usr/include/features.h
> makes me think that both flags may have effect on libc on both 32 and
> 64 bit platforms. These #defines seem to activate different libc features,
> and, assuming that both are needed, I would keep both flags set.
> (64-bit offset and functions that take off_t argument [fseeko, ftello]).
> It is possible that in some cases one flag implies the other, but I
> did not see this clearly stated anywhere.
I dont remember the details on this; so I would err on the same side as
Volodymyr - keep it as is.
A test case would be welcome, but coverage of that test on many platforms
would be needed...
> > 2. Do we really need the "-ip -O3 -xHost" flags for optimized ifort
> > compiles?
> > Is this better/worse/the same as "-fast" (used for pmemd)? Does sander
> > need
> > anything more than -O3? Is there a good compromise between "fastest of
> > all
> > 2^N possible combinations of flags on this particular machine" and
> > "something
> > that sacrifices a few percent in performance but which is likely to both
> > work
> > now and continue working after Intel puts out its next release"?
See the am dev thread
Subject: Re: [AMBER-Developers] SSE2 / SSE3 settings no longer used for ifort?
To reiterate my comments; yes let's try -fast; the main argument against
it was slow the compilation of sander since make -j8 apparently wont work;
imo a simple configuration and better user support has an astronomically
higher precedence than parallel make.
scott
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue Feb 02 2010 - 13:30:02 PST