Oh, and cygwin is a special beast. For Gerald -- nobody is going to run
SEBOMD on Cygwin. So if it doesn't work there, I vote for just throwing in
some preprocessor-protected bomb code that simply exits with a helpful
error and refuses to run on that platform.
It's nice to support Cygwin (and will eventually help us to natively
support Windows -- which is actually pretty close to being a reality), but
in some cases the reward just does not justify the required effort.
All the best,
Jason
On Thu, Mar 10, 2016 at 9:23 PM, Jason Swails <jason.swails.gmail.com>
wrote:
> It's been a long time since I've done benchmarks between GNU, Intel, and
> LLVM compilers (at the time, GCC didn't go past 4.8, I think). But here's
> what I remember:
>
> DragonEgg + gfortran was indistinguishable from gfortran in terms of
> performance (DragonEgg+gfortran compiles in ~1/2 the time, though, which is
> why I've exclusively used DragonEgg when compiling Amber for the past
> several years).
>
> Performance for GCC 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, and 4.8 was
> basically unchanged for both pmemd and cpptraj using the standard
> config.h-provided compiler flags (I have all GCCs from 4.1 through 4.9 and
> 5.2 on my Gentoo box). It could be that the gfortran developers focused
> heavily on Fortran performance for the 5.x series, but I actually suspect
> that's not too much the case.
>
> The Intel Fortran compiler was notably faster, especially with MKL for
> certain things that used it. The improvements were more pronounced than
> Dan's report below on my machine (AMD FX-6100 hex-core).
>
> For C++ performance, g++ was the slowest (by a considerable margin),
> clang++ was faster, and icpc was a little faster still (but not a lot).
> But that's application-dependent. For OpenMM, Robert McGibbon did some
> benchmarks comparing clang++, g++, and icpc and actually showed that
> clang++ was, by a considerable margin, the best compiler (for heavily
> optimized code vectorized with compiler intrinsics) -- here is the report:
> http://bit.ly/1Maw6Ps
>
> But performance is not the only reason to like a compiler. GCC 4.9 and
> up, and clang (for quite a bit longer) gives significantly improved
> compile-time analysis on the code (and clang gives quite good run-time
> error-checking as well: http://bit.ly/1RaY2nB
>
> In any case, I have very frequently taken advantage of multiple compilers
> to find bugs and fix them. For instance, what might be a heisenbug in
> gcc/gfortran may segfault in icc/ifort and vice-versa. Anyone that's done
> a lot of debugging knows that segfaults are *way* easier to debug. There
> have also been instances where a Heisenbug with one compiler doesn't even
> show up in another -- same thing with different MPI libraries; I've fixed
> bugs that OpenMPI exposed that mpich2 effectively masked.
>
> So I think we should have 3 categories of compilers:
>
> 1. Those we test regularly (certain versions of GCC, Intel, and
> clang/LLVM) and know to work well on any systems we use
> 2. Those that don't support the language features we rely on and so are
> expressly unsupported (GCC 4.1.2 and earlier), and compiler families we
> never test
> 3. Everything else. It *should* work, but is not thoroughly tested (which
> is why we have regression tests that users can run).
>
> It would be good to document which are in category 1 somewhere, but I
> think striving to support as many compilers as possible is, on the whole,
> good for Amber.
>
> All the best,
> Jason
>
> On Thu, Mar 10, 2016 at 3:05 PM, Daniel Roe <daniel.r.roe.gmail.com>
> wrote:
>
>> Benchmarks for my local machine (intel core i7-2600 3.4 GHz), x86_64.
>> Current GIT master (8685600c1b3862670b1de0549776a687c1520aea).
>> $AMBERHOME/benchmarks/dhfr
>>
>> GNU: 5.3.1
>> ./configure gnu
>> sander: 0.49 ns/day
>> pmemd: 1.13 ns/day
>>
>> Intel: 14.0.0
>> ./configure intel
>> sander: 0.55 ns/day
>> pmemd: 1.42 ns/day
>>
>> About 1.1-1.2x - not as large as the speedup that Ross saw but still not
>> bad.
>>
>> I'll look at some cpptraj benchmarks in a bit.
>>
>> -Dan
>>
>> On Thu, Mar 10, 2016 at 12:53 PM, Gerald Monard
>> <Gerald.Monard.univ-lorraine.fr> wrote:
>> >
>> >
>> > On 03/10/2016 06:03 PM, David A Case wrote:
>> >> Could you say how much faster (for some example)? (Aside: you can use
>> MKL
>> >> + gnu compilers, if that makes any difference).
>> >>
>> >> ...thx...dac
>> >
>> > I'll try to provide some benchmarks for next week.
>> > Best,
>> >
>> > Gerald.
>> >
>> >
>> > --
>> >
>> ____________________________________________________________________________
>> >
>> > Prof. Gerald MONARD
>> > SRSMC, Université de Lorraine, CNRS
>> > Boulevard des Aiguillettes B.P. 70239
>> > F-54506 Vandoeuvre-les-Nancy, FRANCE
>> >
>> > e-mail : Gerald.Monard.univ-lorraine.fr
>> > tel. : +33 (0)383.684.381
>> > fax : +33 (0)383.684.371
>> > web : http://www.monard.info
>> >
>> >
>> ____________________________________________________________________________
>> >
>> >
>> > _______________________________________________
>> > AMBER-Developers mailing list
>> > AMBER-Developers.ambermd.org
>> > http://lists.ambermd.org/mailman/listinfo/amber-developers
>>
>>
>>
>> --
>> -------------------------
>> Daniel R. Roe, PhD
>> Department of Medicinal Chemistry
>> University of Utah
>> 30 South 2000 East, Room 307
>> Salt Lake City, UT 84112-5820
>> http://home.chpc.utah.edu/~cheatham/
>> (801) 587-9652
>> (801) 585-6208 (Fax)
>>
>> _______________________________________________
>> AMBER-Developers mailing list
>> AMBER-Developers.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>
>
>
>
> --
> Jason M. Swails
> BioMaPS,
> Rutgers University
> Postdoctoral Researcher
>
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Mar 10 2016 - 18:30:04 PST
