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.
