[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#52283] [PATCH 00/10] Tuning packages for CPU micro-architectures
From: |
Ludovic Courtès |
Subject: |
[bug#52283] [PATCH 00/10] Tuning packages for CPU micro-architectures |
Date: |
Mon, 06 Dec 2021 11:38:42 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
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’.
- [bug#52283] [PATCH 02/10] transformations: Add '--tune'., (continued)
[bug#52283] [PATCH 06/10] gnu: Add xtensor-benchmark., Ludovic Courtès, 2021/12/04
[bug#52283] [PATCH 04/10] gnu: Add eigen-benchmarks., Ludovic Courtès, 2021/12/04
[bug#52283] [PATCH 05/10] gnu: Add xsimd-benchmark., Ludovic Courtès, 2021/12/04
[bug#52283] [PATCH 07/10] gnu: ceres-solver: Mark as tunable., Ludovic Courtès, 2021/12/04
[bug#52283] [PATCH 08/10] gnu: Add ceres-solver-benchmarks., Ludovic Courtès, 2021/12/04
[bug#52283] [PATCH 10/10] gnu: prusa-slicer: Mark as tunable., Ludovic Courtès, 2021/12/04
[bug#52283] [PATCH 09/10] gnu: libfive: Mark as tunable., Ludovic Courtès, 2021/12/04
[bug#52283] [PATCH 00/10] Tuning packages for CPU micro-architectures, Mathieu Othacehe, 2021/12/05
[bug#52283] [PATCH 00/10] Tuning packages for CPU micro-architectures, Ludovic Courtès, 2021/12/06
[bug#52283] [PATCH 00/10] Tuning packages for CPU micro-architectures, Ludovic Courtès, 2021/12/04
[bug#52283] [PATCH 00/10] Tuning packages for CPU micro-architectures, Ludovic Courtès, 2021/12/07