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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproject.org