Re: build system option to allow CPU optimizations?

[Ricardo Wurmus <rekado@elephly.net>]

Ludovic Courtès <ludovic.courtes@inria.fr> writes:

> Hi,
>
> zimoun <zimon.toutoune@gmail.com> skribis:
>
>> On Wed, 24 Nov 2021 at 13:10, Ricardo Wurmus 
>> <rekado@elephly.net> wrote:
>>
>>> The build phases that patch out these features would have to 
>>> check 
>>> for that build system option, much like they check the TESTS? 
>>> option before attempting to run tests.
>>
>> Then it could be a transformation.   The idea sounds good to 
>> me.
>
> I’ve been working on it last week with my HPC hat on.
>
> To be clear, I think in may cases, passing ‘-march’ like you 
> suggest is
> the wrong approach; instead software should use (and usually 
> does use)
> function multi-versioning:
>
>   https://hpc.guix.info/blog/2018/01/pre-built-binaries-vs-performance/

It may very well be the wrong approach in principle, but I also 
think that it’s a neat escape hatch for specific use cases. 
Separating reproducibility patching makes the package 
transformation mechanism more powerful and appealing.  Much like 
respecting TESTS? makes it easy for users of modified packages to 
bypass a failing test suite, making patching of Makefiles to 
remove CPU tuning conditional would make for much less complex 
custom package definitions.

> I found one case though where this is not possible: C++ 
> header-only
> libraries such as Eigen contain hand-optimized vectorized 
> routines,
> selected at build time, but we end up compiling Eigen users as 
> the
> x86_64/AArch64 baseline, which is a waste.  (If you do know of 
> other
> problematic cases, I’m interested in taking a look!)
>
> My solution to that is “package multi-versioning” via a 
> transformation
> option.  Hopefully I’ll submit preliminary patches within a week 
> or so!

Oh, exciting!

-- 
Ricardo