[gmx-developers] CFLAGS for ppc, etc. with CMake

Roland Schulz roland at utk.edu
Thu Jul 1 02:27:43 CEST 2010


On Wed, Jun 30, 2010 at 7:13 PM, <hess at sbc.su.se> wrote:

> > On Wed, Jun 30, 2010 at 5:58 PM, Szilárd Páll
> > <szilard.pall at cbr.su.se>wrote:
> >
> >> Hi,
> >>
> >> > -Kieee. Does someone know whether this is required for GROMACS? One
> >> can
> >> also
> >> > gain with GCC by adding -ffast-math. Is this safe?
> >>
> >> When testing/debugging the strange performance hit we experienced a
> >> while ago with gcc 4.3.3/4 - which turned out to be a problem with
> >> expf - I also tried the -ffast-math flag and as far as I remember I
> >> got no relevant performance improvement (tested on x86_64). With some
> >> gcc versions it even seemed to produce a small performance hit,
> >> overall showing -1-2% "improvement".
> >>
> > Yes. I did the same test back then and got 5% improvement for only the
> > solve_pme part. So this agrees with your result.
> > Of course this is not that much, but since it is no work to activate it,
> I
> > think it is still interested.
> >
> > The question is whether it is safe. Thus is there some code which
> requires
> > strict accordance of the IEEE rules? My understanding is that fast-math
> > usually doesn't affect the accuracy. Only if bitwise results are
> important
> > or things are unstable it should be important. I'm not aware of any code
> > like this, but I'm not sure at all. If we have any code like this we
> might
> > consider to activate fast-math only for the solve_pme function.
> >
> > Roland
> >
>
> I don't think we need ieee for anything.
>
> But do you still get 5% on solve pme after I added the SSE exp?
> I also had an SSE 1/x which gave 1 or 2%.
> But solve pme is now so little of the total time that such things
> become irrelevant.
>

Just tested it and I get 30% speed improvement in PME solve with the latest
HEAD version when using -ffast-math. This is with GCC 4.4.2.
And I checked that the new SSE exp function is used.
If you are interested I can run it with profiling to see which code lines
cause the difference.

Roland


>
> Berk
>
> >>
> >> Take these metrics with a grain of salt though as my benchmarking was
> >> focused on a 10-20% performance hit on PME. Moreover it was done ~1.5
> >> months ago so It might be worth to test again.
> >>
> >> --
> >> Szilárd
> >> --
> >> gmx-developers mailing list
> >> gmx-developers at gromacs.org
> >> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> >> Please don't post (un)subscribe requests to the list. Use the
> >> www interface or send it to gmx-developers-request at gromacs.org.
> >>
> >
> >
> >
> > --
> > ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
> > 865-241-1537, ORNL PO BOX 2008 MS6309
> > --
> > gmx-developers mailing list
> > gmx-developers at gromacs.org
> > http://lists.gromacs.org/mailman/listinfo/gmx-developers
> > Please don't post (un)subscribe requests to the list. Use the
> > www interface or send it to gmx-developers-request at gromacs.org.
>
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.
>



-- 
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20100630/8e07de1b/attachment.html>


More information about the gromacs.org_gmx-developers mailing list