guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#52283] [PATCH 02/10] transformations: Add '--tune'.


From: zimoun
Subject: [bug#52283] [PATCH 02/10] transformations: Add '--tune'.
Date: Thu, 09 Dec 2021 11:35:33 +0100

Hi,

On Thu, 09 Dec 2021 at 10:19, Ludovic Courtès <ludovic.courtes@inria.fr> wrote:
> zimoun <zimon.toutoune@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. :-)


>>> According to this page, ‘--tune’ won’t be necessary here because Julia
>>> supports function multi-versioning for its “system image”:
>>
>> Yes, but from my understanding, the "baseline" cannot provide an image
>> for all the micro-architectures, but only 'generic'.  Moreover, as you
>> described elsewhere, we cannot know for sure whether the machine that
>> hosts the daemon is able to run code for this specific
>> micro-architecture.
>
> With multi-versioning, the system image (AIUI) provides several versions
> of the relevant code, one for each useful micro-architecture.  Such a
> system image can be used anywhere because the right version of the code
> will be picked up at run-time depending on the host CPU.

Thanks for explaining.  Indeed, the “baseline” could provide an image
for all the micro-architectures; if it is not already the case*.  The
blog post [1] refers to LWN article [2]; which underlines the impact on
the resulting image size, it should be minimal.  Benchmark required for
Julia. :-)

1: <https://hpc.guix.info/blog/2018/01/pre-built-binaries-vs-performance/>
2: <https://lwn.net/Articles/691932/>


Cheers,
simon

*not already the case: «As an example, at the time of this writing, the
following string is used in the creation of the official x86_64 Julia
binaries downloadable from julialang.org:»

    generic;sandybridge,-xsaveopt,clone_all;haswell,-rdrnd,base(1)

<https://docs.julialang.org/en/v1/devdocs/sysimg/>

And I do not know exactly if the current situation for the precompiled
.ji is optimal, another story.  Indeed, this tune transformation is not
useful for Julia. :-) Thanks for the patient explanations.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]