GNU bug report logs - #74253
[PATCH] transformations: Add multituned-package.

Previous Next

Full log

Message #14 received at 74253 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludovic.courtes <at> inria.fr>
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: Josselin Poiret <dev <at> jpoiret.xyz>,
 Simon Tournier <zimon.toutoune <at> gmail.com>, Mathieu Othacehe <othacehe <at> gnu.org>,
 Tobias Geerinckx-Rice <me <at> tobias.gr>, Christopher Baines <guix <at> cbaines.net>,
 74253 <at> debbugs.gnu.org
Subject: Re: [bug#74253] [PATCH] transformations: Add multituned-package.
Date: Mon, 25 Nov 2024 10:13:38 +0100

Hello,

Efraim Flashner <efraim <at> flashner.co.il> skribis:

> On Tue, Nov 12, 2024 at 11:31:57AM +0100, Ludovic Courtès wrote:

[...]

>> Should that be a package transformation though?  Could we instead have a
>> build system trick or the ‘multituned-package’ procedure exposed so
>> build the package several times and fill in lib/glibc-hwcaps?
>
> I figured (guix transformations) worked well since it was using an
> existing transformation to generate the different variants.
>
> I'm not sure what you mean by a build system trick, like build the
> package multiple times in one like with x265?

Yes, that sort of thing, or basically what you have here but provided as
a build phase.

Now, it’s probably easier to implement it the way you did than as a
build phase, because how exactly to rebuild a package with the right
optimizations is very dependent on details about its build system.

> This exposes the multituned-package procedure (looks like I mistyped in
> the commit message) which takes a package and can be just added on top
> of an existing package definition, like hidden-package can.

Yes, but I think the key ideal with hwcaps is that, contrary to what
‘--tune’ does, we’d provide several optimized versions upfront.  In that
sense, we’d statically choose to “multi-tune” certain packages.

>> That way, packagers would explicitly choose this technique for select
>> packages, which would then no longer need the ‘tunable?’ property.
>
> Something like a flag in the build-system like #:tests? is? Or like a
> package property?

Either that, or write (define p' (multituned-package p)) etc.

The key point being: packagers would be the one deciding that.

So hmm, maybe the way forward is to keep the ‘multituned-package’, but
just not expose it as a package transformation.  Also, we might want to
move tuning support to (guix cpu-tuning) or similar, which is the module
that packagers would import (rather than (guix transformations)).

WDYT?

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.