[gmx-developers] Segfault in 2021-beta1 enabling SVE and ArmIE emulator
Erik Lindahl
erik.lindahl at gmail.com
Tue Oct 27 13:52:29 CET 2020
Hi,
Just to follow up, I can explain the logic behind this:
It's not merely a matter of convenience (or history) for picking it at
runtime, but simply that some algorithms will have different efficiencies
depending on the vector length.
For instance, with a SIMD vector length of 4, it might work well to
organize interactions into 4x4 tiles. Some of those interactions might fall
outside the cutoff, but since the cluster is relatively small the wasted
fraction is limited.
If the SIMD vector length is suddenly 16 instead, it would be trivial to
just use exactly the same code, which would then mean the tiles are 16x16
interactions. However, with such gigantic clusters we would now waste a
*much* larger fraction of the calculations.
Instead, we adapt to the SIMD with and use a different algorithm where we
e.g. pack each 4x1 row into 25% of a longer SIMD register so we use the
throughput of wider SIMD without wasting calculations due to more
zero-interactions, but this can require us to use e.g. a different
neighborlist generation setup.
Presently we detect this at compile time. It's theoretically possible to do
at runtime instead, but a bit of work. However, there will always be
algorithms where knowing the SIMD width in the hardware will enable you to
write a more efficient implementation rather than keeping it opaque.
Cheers,
Erik
On Tue, Oct 27, 2020 at 1:32 PM <gilles at rist.or.jp> wrote:
> Guido,
>
> Strictly speaking, SVE gives developers and compilers the opportunity to
> build/generate vector length agnostic (VLA) binaries/libraries
> whose performance almost as good as their fixed vector length
> counterpart. Such VLA programs can run (correctly) on any arm+sve
> processors,
> regardless the vector length that is available at runtime.
>
> Gromacs is highly optimized and assumes the vector length is known at
> cmake time, and this is assumed in several places of the code base.
> So the most straightforward and efficient way of supporting SVE is to
> fix the SVE vector length at cmake time.
>
> FWIW, I made a proof-of-concept of non bonded VLA kernels, and
> performance is not even close to current (fixed vector length)
> non bonded kernels.
>
> Cheers,
>
> Gilles
>
> ----- Original Message -----
> > Hi Gilles,
> >
> > Thanks a lot, I tested again and it is working with ArmIE for a length
> of 512. I will close the Issue in GitLab.
> >
> > SVE allows to set the vector length at run time, is there a particular
> reason for doing this at compile time?
> >
> > Cheers, Guido.
> >
> > -----Original Message-----
> > From: gromacs.org_gmx-developers-bounces at maillist.sys.kth.se [mailto:
> gromacs.org_gmx-developers-bounces at maillist.sys.kth.se] On Behalf Of
> Gilles Gouaillardet
> > Sent: Tuesday, October 27, 2020 10:05 AM
> > To: gmx-developers at gromacs.org
> > Subject: Re: [gmx-developers] Segfault in 2021-beta1 enabling SVE and
> ArmIE emulator
> >
> > Guido,
> >
> >
> > The SVE vector length must be fixed at cmake time, and the default
> value is 512.
> >
> > In your case, you have to pass
> >
> > -DGMX_SIMD_ARM_SVE_LENGTH=256
> >
> > to your cmake command line.
> >
> >
> > Cheers,
> >
> >
> > Gilles
> >
> > On 10/27/2020 5:58 PM, Guido Giuntoli wrote:
> > >
> > > Hi,
> > >
> > > I have run the nonbonded-benchmark using the ArmIE emulator.
> > >
> > > I compiled gmx_d (DOUBLE FP) with GCC 10.2 for SVE by using:
> > >
> > > *CC=gcc-10 CXX=g++-10 \*
> > >
> > > *cmake .. \*
> > >
> > > * -DCMAKE_BUILD_TYPE=Release \*
> > >
> > > *-DCMAKE_C_FLAGS="-march=armv8-a+sve" \*
> > >
> > > *-DCMAKE_CXX_FLAGS="-march=armv8-a+sve" \*
> > >
> > > * -DGMX_MPI=off \*
> > >
> > > * -DGMX_GPU=off \*
> > >
> > > * -DGMX_USE_OPENCL=off \*
> > >
> > > * -DGMX_BUILD_MDRUN_ONLY=off \*
> > >
> > > * -DGMX_DOUBLE=on \*
> > >
> > > * -DGMX_SIMD=ARM_SVE \*
> > >
> > > * -DBUILD_SHARED_LIBS=off \*
> > >
> > > * -DGMX_FFT_LIBRARY=fftw3 \*
> > >
> > > * -DGMX_INSTALL_NBLIB_API=OFF \*
> > >
> > > * -DGMXAPI=OFF \*
> > >
> > > * | tee cmake.log*
> > >
> > > I ran the benchmark with:
> > >
> > > *armie -msve-vector-bits=256 \*
> > >
> > > * gmx_d nonbonded-benchmark \*
> > >
> > > * -size 1 \*
> > >
> > > * -nt 1 \*
> > >
> > > * -simd 4xm \*
> > >
> > > * -coulomb ewald \*
> > >
> > > * -notable \*
> > >
> > > * -combrule geometric \*
> > >
> > > * -nohalflj \*
> > >
> > > * -noenergy \*
> > >
> > > * -noall \*
> > >
> > > * -cutoff 1 \*
> > >
> > > * -iter 5 \*
> > >
> > > * -warmup 0 \*
> > >
> > > * -nocycles*
> > >
> > > I get:
> > >
> > > *armie's SVESigHandler caught signal SIGSEGV from the process being
> > > emulated, passing it to the default signal handler.*
> > >
> > > *Guest process terminated by signal: 15152 Segmentation fault /home/.
> > > /codes/gromacs/gromacs-2021-beta1/build-sve/bin/gmx_d*
> > >
> > > According to the last meeting, I am eager to know if this branch has
> > > passed the regression tests using SVE. BTW, are you using SVE-
> enabled
> > > hardware or emulation for your development/tests?
> > >
> > > *Best regards | Mit freundlichen Grüßen*
> > >
> > > **
> > >
> > > *Guido Giuntoli***
> > >
> > > **
> > >
> > > HUAWEI TECHNOLOGIES Duesseldorf GmbH
> > > Hansaallee 205, 40549 Dusseldorf, Germany, *www.huawei.com*
> > > <http://www.huawei.com/> Registered Office: Düsseldorf, Register
> Court
> > > Düsseldorf, HRB 56063, Managing Director: Li Peng, Li Jian, Shi
> > > Yanli**
> > >
> > > Sitz der Gesellschaft: Düsseldorf, Amtsgericht Düsseldorf, HRB 56063,
> > > Geschäftsführer: Li Peng, Li Jian, Shi Yanli
> > >
> > > *-------------------------------------------------------------------
> --
> > > --------------------------*
> > >
> > > *This e-mail and its attachments contain confidential information
> from
> > > HUAWEI, which is intended only for the person or entity whose
> address
> > > is listed above. Any use of the information contained herein in any
> > > way (including, but not limited to, total or partial disclosure,
> > > reproduction, or dissemination) by persons other than the intended
> > > recipient(s) is prohibited. If you receive this e-mail in error,
> > > please notify the sender by phone or email immediately and delete
> > > it!***
> > >
> > >
> > --
> > Gromacs Developers mailing list
> >
> > * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List
> before posting!
> >
> > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> >
> > * For (un)subscribe requests visit
> > https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org.
> > --
> > Gromacs Developers mailing list
> >
> > * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List
> before posting!
> >
> > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> >
> > * For (un)subscribe requests visit
> > https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org.
> >
> --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org.
>
--
Erik Lindahl <erik.lindahl at dbb.su.se>
Professor of Biophysics, Dept. Biochemistry & Biophysics, Stockholm
University
Science for Life Laboratory, Box 1031, 17121 Solna, Sweden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20201027/cfb7d2f7/attachment-0001.html>
More information about the gromacs.org_gmx-developers
mailing list