Hi, "Dr. Arne Babenhauserheide" <arne_...@web.de> skribis:
> The attached patch adds a guile@3.0.9t package that enables CPU > architecture tuning for Guile and for a specialized libgc. > > It creates new packages to avoid causing rebuilds. Marking a package as tunable does not involve any rebuilds, by design: https://hpc.guix.info/blog/2022/01/tuning-packages-for-a-cpu-micro-architecture/ Thus there’s no need to create package variants. > The results of a benchmark are still not fully conclusive: regular Guile > seems to be slightly slower in the Geometric mean of all tests, but > there are benchmarks where a tuned Guile is slower. > > Note that this is tuning for znver3 while I actually have znver4, but > support for the correct compile-target will only arrive with GCC 13. [...] > Guile tuned has a slowdown of 1.03512801239189 > Guile regular has a slowdown of 1.0504373210343294 > > This suggests that the regular Guile is 1.48% slower than tuned Guile. > > Since I have no errorbars, I cannot say whether this is significant. As far as I know, there’s no reason why Guile’s C code would benefit from ISA extensions (we’re mostly talking about vector instructions like those of AVX). The only part in libguile that’s performance-critical is the VM engine—but I don’t see how that code could benefit from vector instructions. Likewise, I doubt libgc build with ‘-march=znver3’ has any chance of being any faster; most likely, the generated code is close to the baseline. For these reasons, I’m reluctant to this patch. Tuning should be done only on packages where it makes sense, typically linear algebra code, image/video processing, and so on. WDYT? Ludo’.
