Re: [AMBER-Developers] reference os+compiler systems

From: Jason Swails <jason.swails.gmail.com>
Date: Thu, 10 Mar 2016 21:23:27 -0500

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
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Mar 10 2016 - 18:30:03 PST
Custom Search