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

["Ludovic Courtès" <ludovic.courtes@inria.fr>]

Hello!

Mathieu Othacehe <othacehe@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’.