Dave Love wrote:
they'd be rather limited by the compiler options we're
supposed to use,
that don't include vectorization, so you don't even get the benefit you
could from SSE2. (I've been told off in review for turning that on,
though an FPC member has approved it.)
Why don't we enable -ftree-vectorize by default?
However, hwcaps won't help for programs with no separate library
performance component; Gromacs is an example. On a heterogeneous HPC
system you need multiple parallel-installable versions with a convention
for the paths they'll be on.
As I wrote elsewhere in this huge thread: just turn the program into a
library with a dummy main program.
There's already multi-simd support for ATLAS -- though I know no
reason to ATLAS
You mean the atlas-* subpackages that one has to manually install? That's
actually one big reason to NOT use ATLAS, now that we have OpenBLAS that
does it right.
and at least one package (libxsmm) has a minimum requirement of SSE3
without complaint. (I got that down from SSE4 for the benefit of systems
we had, though you wouldn't use them for anything CPU-bound.)
Now you have a complaint. :-)
The baseline is SSE2, so the packages are supposed to support systems with
nothing beyond SSE2. Just waiting until somebody reports the inevitable
SIGILL is not a nice thing to do.
Now, if upstream doesn't support non-SSE3 CPUs, it might be nontrivial to
fix the issue. But in principle, a package that requires SSE3 must be
considered a bug.