Re: Optionally using more advanced CPU features

[Pjotr Prins <pjotr.public12@thebird.nl>]

On Sat, Aug 26, 2017 at 11:39:41AM +0800, Ben Woodcroft wrote:
> I was wondering how we should go about optionally building software for
> more advanced CPU features.  Currently, we build software for the lowest
> common feature set among x86_64 CPUs.  That’s good for portability, but
> not so good for performance.
> 
>    In many cases we can set the --with-arch flag when configuring GCC, so
>    that packages built with that GCC are optimised for that architecture
>    by default.
>    We have discussed this in the past,
>    ([1]https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00005.html
>    ) but as you say individual packages sometimes need individual
>    attention.
>    Anyway, to move forward I created a repo so that package recipes can be
>    modified to use a GCC that has been optimised for a particular
>    architecture. I put it out there so that it is more than just a patch
>    on this ML, but I'd be happy to incorporate it into Guix proper if that
>    is desired.
>    [2]https://github.com/wwood/cpu-specific-guix
>    For instance, to build DIAMOND optimised for sandybridge:
> GUILE_LOAD_PATH=/path/to/cpu-specific-guix:$GUILE_LOAD_PATH\
>   guix build -e '(begin (use-modules (cpu-specific-guix) (gnu packages bioinform
> atics))\
>   (cpu-specific-package diamond "sandybridge"))'
> 
>    HTH, ben

Pretty cool. This works for leave-packages. For libraries we'll need
to have something that goes deeper into the graph. Openblas/atlas/GSL
are prime examples that would benefit a wide range of applications.

I am working on GEMMA these days and I will target supercomputing
architectures. Having math libraries that target vectorization
optimizations for gcc and LLVM would be very useful. The current
deployment strategy is 'one-offs' on the GUIX_PACKAGE_PATH.

Just as a note, it makes no sense to optimize all Guix packages. In
fact I prefer we have the non-optimized by default since that is what
everyone is using and is (arguably) well tested. We only have the 1 in
a thousand library we want to specialize/optimize aggressively.

Pj.