all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ludovic.courtes@inria.fr (Ludovic Courtès)
To: Ricardo Wurmus <rekado@elephly.net>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: Optionally using more advanced CPU features
Date: Tue, 22 Aug 2017 11:21:00 +0200	[thread overview]
Message-ID: <87a82s9cw3.fsf@gnu.org> (raw)
In-Reply-To: <87inhhw1ms.fsf@elephly.net> (Ricardo Wurmus's message of "Mon, 21 Aug 2017 14:23:23 +0200")

Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

> 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.
>
> Enabling CPU features often happens through configure flags, but
> expressing support at that level in our package definitions seems bad.
> How can we make it possible for users to build their software for
> different CPUs?

To some extent, I think this is a compiler/OS/upstream issue.  By that I
mean that the best way to achieve use of extra CPU features is by using
the “IFUNC” feature of GNU ld.so, which is what libc does (it has
variants of strcmp etc. tweaked for various CPU extensions like SSE, and
the right one gets picked up at load time.)  Software like GMP, Nettle,
or MPlayer also does this kind of selection at run time, but using
custom mechanisms.

GCC now has a ‘target_clones’ function attribute, which instructs it to
generate several variants of a function and use IFUNC to pick up the
right one (info "(gcc) Common Function Attributes").  Ideally, upstream
would use this.

When upstream does that, we have portable-yet-efficient “fat” binaries,
and there’s nothing to do on our side.  :-)

> We can cross-compile for other architectures on the command line with
> “--target” and “--system”; can we allow for compilation with special CPU
> features across the graph with “--features”?  Build system abstractions
> or package definitions would then be changed to recognize these features
> and modify the corresponding flags as needed.

I’ve considered this, but designing this would be tricky, and not quite
right IMO.

There’s probably scientific software out there that can benefit from
using the latest SSE/AVX/whatever extension, and yet doesn’t use any of
the tricks above.  When we find such a piece of software, I think we
should investigate and (1) see whether it actually benefits from those
ISA extensions, and (2) see whether it would be feasible to just use
‘target_clones’ or similar on the hot spots.

If it turns out that this approach doesn’t scale or isn’t suitable, then
we can think more about what you suggest.  But before starting such an
endeavor, I would really like to get a better understanding of the
software we’re talking about and the options that we have.

WDYT?

Thanks,
Ludo’.

  reply	other threads:[~2017-08-22  9:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-21 12:23 Optionally using more advanced CPU features Ricardo Wurmus
2017-08-22  9:21 ` Ludovic Courtès [this message]
2017-08-23 13:59   ` Dave Love
2017-08-28 13:48     ` Ludovic Courtès
2017-09-01 10:46       ` Dave Love
2017-09-04 12:38         ` Ludovic Courtès
2017-09-07 15:51         ` Packaging BLIS Ludovic Courtès
2017-09-08 22:36           ` Dave Love
2017-09-11  7:12             ` Ludovic Courtès
2017-08-26  3:39 ` Optionally using more advanced CPU features Ben Woodcroft
2017-08-26  5:14   ` Pjotr Prins
2017-09-04 14:50   ` Ludovic Courtès

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a82s9cw3.fsf@gnu.org \
    --to=ludovic.courtes@inria.fr \
    --cc=guix-devel@gnu.org \
    --cc=rekado@elephly.net \
    /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 external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.