Tradeoffs to satisfy a wide variety of users - a base system with most
common software easy to try which can then be re-installed for
performance. Flatpacks should help with easy but not performance optimal
installation of many packages. Spack (https://spack.io/) may be a
packaging approach that gives some performance portability - one can get
a compilation recipie so that performance is reasonable good. Easybuild
(https://easybuild.readthedocs.io) is another way to go. Source based
systems such as Gentoo may give better performance if configured correctly.
On 7/23/19 7:00 PM, Dave Love wrote:
I'm afraid this turned into a bit of and essay on more useful things
Fedora could do for portable performance engineering, should anyone
care.
I actually have no interest in Fedora except as a requirement to work on
packaging for research software around EPEL, specifically for HPC and so
performance-oriented. I'm not sure how long it's worth persisting in
view of how difficult it is to contribute now, but these points are
mostly general.
The x86 change is clearly a non-starter, and I'm surprised to see where
it came from, but I don't see anyone mentioning much on rationale
higher-level aspects, apart from some better things to do. Strikingly,
there's no quantification of expected performance benefits. Anyway,
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.)
I've seen lack of support for things that would help, and plenty of
comments from people who clearly haven't work in this area. At least
one sensible portable performance-oriented change has been blocked in
committee (interchangeable BLAS implementations), and what I've seen
from Red Hat and Fedora makes it increasingly hard to justify a RHEL-ish
basis for HPC. However, things could be done for computational
performance where it matters.
SIMD hwcaps have been mentioned, and I'm baffled why they haven't been
implemented generally. That and similar changes are actually more
important for non-x86 architectures less likely to have
dynamically-dispatched SIMD-specific implementations. [The value of
"SIMD" includes things like FMA, and I know not just for floating point.]
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. Other than that, maintainers could look at
function multi-versioning for performance-critical code where that's
possible. It isn't always, specifically not for Fortran, and I'd
probably look at that first if I got back to GCC maintenance.
(Actually, adding FMV to BLIS wasn't effective for some reason I haven't
had time to chase.)
The "Clear Linux" stuff mentioned is unconvincing. The only worked
example I've seen is for FFTW, where it actually has no effect, and I've
seen no numbers. Using FMV outside performance-critical kernels -- just
something GCC says is vectorizable -- is probably not a good idea, and
any changes ought to be contributed explicitly for the source and
support non-x86. (By the way, don't even Intel assume AVX as a
baseline, not AVX2?)
There's already multi-simd support for ATLAS -- though I know no good
reason to ATLAS -- 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.)
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx
