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

Previous Next

Full log

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

From: Ludovic Courtès <ludovic.courtes <at> inria.fr>
To: Mathieu Othacehe <othacehe <at> gnu.org>
Cc: 52283 <at> debbugs.gnu.org
Subject: Re: bug#52283: [PATCH 00/10] Tuning packages for CPU
 micro-architectures
Date: Mon, 06 Dec 2021 11:38:42 +0100

Hello!

Mathieu Othacehe <othacehe <at> gnu.org> skribis:

> Wooh, nice addition!

Glad you like it.  :-)

>> +(define-record-type <cpu>
>> +  (cpu architecture family model flags)
>> +  cpu?
>> +  (architecture cpu-architecture)                 ;string, from 'uname'
>> +  (family       cpu-family)                       ;integer
>> +  (model        cpu-model)                        ;integer
>> +  (flags        cpu-flags))                       ;set of strings
>
> When using the "--tune" transformation option with "native", we can
> expect the current-cpu method to fill the <cpu> record correctly.
>
> However, when the user is passing a custom cpu name, it might be
> incorrect. I think we should check the user input against a list of
> valid/supported cpu architectures.
>
> That's something we should also enforce for the system and target
> fields. Currently, this command "guix build -s arch64-linux hello" is
> failing with an unpleasant backtrace, while it could warn that the
> given system is not supported.

Right.  I’m a bit torn because I agree with the usability issue and
solution you propose, but at the same time I know that maintaining a
list of existing CPU names will be tedious and it’ll be annoying for
users if they can’t just specify their CPU name (which they might want
to do precisely when ‘--tune=native’ doesn’t determine the right name
because it doesn’t know about it yet.)

Maybe it’s an acceptable limitation though.

I’ll see how I can tweak the code so that the CPU detection code and the
micro-architecture name validation code can share a single list of
names.

> Maybe the (guix cpu) and (gnu platform) modules should be merged somehow
> to define the supported CPU micro-architectures:
>
> (define armv7-linux
>   (platform
>    (target "arm-linux-gnueabihf")
>    (system "armhf-linux")
>    (linux-architecture "arm")
>    (supported-march '("armv7" "armv7-a" "armv7ve"))
>
> we could then use those platform records in the (gnu ci) module to build
> packages against all the supported micro architectures and remove the
> "%x86-64-micro-architecture" variable you propose to introduce there.

Hmm yeah, but it should be (guix platforms) then…

Maybe that’s a broader refactoring we can keep for later?  I agree it
would be logical but I’m not sure how to nicely factorize things.

Thanks,
Ludo’.

Previous Next

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