GNU bug report logs - #52283
[PATCH 00/10] Tuning packages for CPU micro-architectures

Previous Next

Full log

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

From: Ludovic Courtès <ludovic.courtes <at> inria.fr>
To: zimoun <zimon.toutoune <at> gmail.com>
Cc: 52283 <at> debbugs.gnu.org, Thiago Jung Bauermann <bauermann <at> kolabnow.com>
Subject: Re: [bug#52283] [PATCH 02/10] transformations: Add '--tune'.
Date: Fri, 10 Dec 2021 09:49:25 +0100

Hello!

zimoun <zimon.toutoune <at> gmail.com> skribis:

> On Thu, 09 Dec 2021 at 10:19, Ludovic Courtès <ludovic.courtes <at> inria.fr> wrote:
>> zimoun <zimon.toutoune <at> gmail.com> skribis:
>
>>> I imagine the scenario: I develop a new simulation tool, I package it
>>> for Guix, I share it; usually I run "guix shell -D" and do loop over
>>> "make" and "make check", then deploy using "guix build --tune".  My
>>> colleague fetches it and want to run it on another cluster, i.e., they
>>> run "guix build --tune".  The test suite for the generic/baseline is
>>> never run inside a clean environment.  And as we know, this isolated
>>> part allows to detect many common issues; which are often source of
>>> "it works for me, why does it not work for you?". ;-)
>>
>> Sure, we can always come up with such scenarios.
>
> Turning off the test is the general case to cover various use case.
>
> Does it make sense to conditionally turn off?  Say, the default for
> ’tune’ is #f, but it is #t when the requested host micro-architecture is
> the same than the daemon one.  Well, maybe it is overcomplicated for few
> corner cases. :-)

Yeah, there’s currently no way to know whether the build machine would
be able to run that code.  Knowing what machine the daemon runs on is
not enough because there could be offloading.

Ludo’.

Previous Next

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