On Fri, Dec 21, 2012 at 1:22 AM, Susi Lehtola <span dir="ltr"><<a href="mailto:jussilehtola@fedoraproject.org" target="_blank">jussilehtola@fedoraproject.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, 21 Dec 2012 00:40:34 +0100<br>
"Dominik 'Rathann' Mierzejewski" <<a href="mailto:dominik@greysector.net">dominik@greysector.net</a>> wrote:<br>
> > The default build produces an executable that targets the best<br>
> > instruction set supported by the build host, and the executables<br>
> > will not run if that set is not supported. From the point of view<br>
> > of packaging, that's ugly. Either there needs to be multiple<br>
> > packages, or you will need to choose an instruction set that is<br>
> > conservative enough to always work. -DGMX_CPU_ACCELERATION=None<br>
> > will always work, but will be horribly slow.<br>
> > -DGMX_CPU_ACCELERATION=SSE2 probably runs about as fast as the 4.x<br>
> > series, but is probably faster through our better use of force-only<br>
> > kernels. -DGMX_CPU_ACCELERATION=SSE4.1 is only slightly faster than<br>
> > SSE2. And then there is AVX, which is faster still, but stil having<br>
> > teething issues.<br>
> ><br>
> > I'd suggest having an SSE2 and a None, but it really depends on<br>
> > what the downstream people want.<br>
><br>
> For x86_64, SSE2 is supported by all processors, so it shouldn't be an<br>
> issue, but for x86_32, the binary should run even on an ancient<br>
> Pentium Pro (Fedora x86_32 minimum CPU requirement). Have you<br>
> considered implementing runtime CPU detection?<br>
<br>
</div>IIRC the old assembly kernels had runtime CPU detection.<br></blockquote><div><br></div><div>We do do runtime detection - we fail gracefully when run on hardware not capable of the configure-time instruction set, and issue a warning if better performance would be available for a different configuration.</div>
<div><br></div><div>We have no plans to build "universal" binaries capable of supporting all the available x86-family acceleration paths. High performance of GROMACS on these architectures is a key feature, but with ~200 kernel functions per acceleration path, and currently generic, SSE2, SSE4.1, AVX_128_FMA and AVX_256 acceleration paths supported, things will get ugly fast if we were to try to build universal binaries now and in the future.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't think the current situation is that bad, if there is no<br>
significant speed difference between SSE2 and the most heavily<br>
optimized version.<br></blockquote><div><br></div><div>The differences in performance are quite significant (or we wouldn't bother with it!), but will vary according to hardware details of the actual execution environment. As always, GROMACS pushes the silicon right to the limits, currently via extensive use of compiler SIMD intrinisics on x86.</div>
<div><br></div><div>Frankly, the configuration of the fftw dependency will be more significant than the SSE2->SSE4.1 effect, though. (And we strongly encourage having the fftw package dependency - we do provide an internal fallback for FFTs, but you may as well run GROMACS on your phone as actually use the fallback code!)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm perfectly happy to ship an SSE2 version on x86_64 and a version<br>
without CPU acceleration on other architectures, since everyone who<br>
actually does calculations surely is on x86_64 architecture.<br></blockquote><div><br></div><div>... and anybody doing serious calculations will see our warning that their use of an SSE2-enabled binary is losing performance and then find out that they need to roll their own. That's the usual price of high performance, of course. I expect they'll have to do that for GPU support, anyway.</div>
<div><br></div><div>Mark</div></div>