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 good
> 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.
Kevin Kofler
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
