From: ludo@gnu.org (Ludovic Courtès)
To: Ben Woodcroft <b.woodcroft@uq.edu.au>
Cc: "guix-devel@gnu.org" <guix-devel@gnu.org>
Subject: Re: CPU-specific builds
Date: Wed, 12 Oct 2016 14:22:16 +0200 [thread overview]
Message-ID: <87vawxpxjb.fsf@gnu.org> (raw)
In-Reply-To: <612094dc-bcdb-b9a2-292c-501b897bcf21@uq.edu.au> (Ben Woodcroft's message of "Mon, 10 Oct 2016 23:45:53 +1000")
Ben Woodcroft <b.woodcroft@uq.edu.au> skribis:
> On 02/10/16 23:33, Ludovic Courtès wrote:
[...]
>>> So I'm wondering if there is some way to specify a system more
>>> specific than 'X86_64'? I tried simply adding '--with-arch=haswell' as
>>> a configure argument in gcc-4.9 so that flag became the default for
>>> gcc usage and saw some performance improvements, though I did have to
>>> disable tests in gnutls.
>> Do you have performance figures for some CPU-intensive applications?
>>
>> What software are you most interested in?
> We tend to run software whose runtime is dependent on the input data,
> so it is hard to say. But up to days or weeks of walltime in some
> cases. It takes a lot of power researching climate change..
>
> As an anecdote, adding "-march=haswell" shaved 13% off the runtime of
> diamond, ~20% if the CPUs were contended.
That’s more than I expected. It’d be useful to have a way to specify
this.
>> Ideally, software for which using these CPU extensions makes a
>> significant difference would do what glibc does, which is to provide
>> several implementations of the relevant functions (one for SSE2, one for
>> AVX, etc.) and have the right one be selected at load time via an IFUNC
>> or similar mechanism.
> That sounds useful in some cases, but it is probably too much of a
> stretch for most bioinformatics packages.
Yeah.
> In the end I think I'll just compile the specific packages we are
> specifically interested in. I attached some example code in case
> anyone is interested. But this brought up a few questions:
>
> 1) I also tried using --expression e.g. guix build --expression '(@@
> (my packages cpu-specific) diamond-cpu-specific)' but that fails to
> compile as if the GUIX_PACKAGE_PATH is ignored, is that unexpected?
What error did you get?
> 2) Is something amiss with gcc-toolchain-6? Compiling with it, diamond
> complains of a missing stdlib.h.
Everything’s fine AFAICS. However, note that ‘gnu-build-system’ pulls
in GCC 4.9, glibc, etc. If you add ‘gcc-toolchain’ to the inputs, that
surely conflicts, but I’m unsure which one “wins”; could you check the
‘environment-variables’ file in a build tree?
> (define-public gcc-cpu-specific
> (let ((base gcc-5)) ; gcc-6 does not seem to work.
> (package
> (inherit base)
> (name "gcc-cpu-specific")
> (arguments
> (substitute-keyword-arguments (package-arguments base)
> ((#:configure-flags configure-flags)
> `(append ,configure-flags
> (list (string-append
> "--with-arch=" ,cpu)))))))))
>
> (define-public (cpu-specific-package base-package)
> (package
> (inherit base-package)
> (name (package-name base-package))
> ;; We must set a higher package version so this package is used instead of
> ;; the package in Guix proper.
> (version (string-append (package-version base-package) "-cpu-specific"))
> (inputs
> `(,@(package-inputs base-package)
> ("gcc" ,((@@ (gnu packages commencement)
> gcc-toolchain) gcc-cpu-specific))))))
>
> (define-public diamond-cpu-specific (cpu-specific-package diamond))
> (define-public fasttree-cpu-specific (cpu-specific-package fasttree))
> (define-public blast+-cpu-specific (cpu-specific-package blast+))
> (define-public bwa-cpu-specific (cpu-specific-package bwa))
> (define-public metabat-cpu-specific (cpu-specific-package metabat))
Looks like the right way to start.
We should start thinking about what the ideal interface would look like,
though. At the highest level, I imagine we’d want something like:
guix package --tune=haswell -i diamond
Under the hood that could work by having an arbitrary list of key/value
options passed to build systems, rather than just the system type and
cross-compilation target as is currently the case.
I once proposed something quite similar, but in the context of providing
something equivalent to Gentoo “USE flags”:
https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00177.html
Food for thought…
Ludo’.
prev parent reply other threads:[~2016-10-12 12:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-01 10:43 CPU-specific builds Ben Woodcroft
2016-10-02 13:33 ` Ludovic Courtès
2016-10-03 14:19 ` Eric Bavier
2016-10-10 13:45 ` Ben Woodcroft
2016-10-11 21:20 ` Ludovic Courtès
2016-10-12 12:22 ` Ludovic Courtès [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vawxpxjb.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=b.woodcroft@uq.edu.au \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).