Richard Shaw <hobbes1069@xxxxxxxxx> writes: >> tl;dr: there was a proposal to make "x86_64" in Fedora mean "must support >> at least AVX2" and it met with a lot of backlash. Yes, that's the wrong approach to performance engineering. > Now that you mention it that does tickle some brain cells... > > So it seems what's really needed is a method to support software with > optimizations above the baseline without leaving other people behind. It's certainly true that you should be able to use optimizations above the Fedora-defined ones, without reviewers jumping on you for enabling vectorization and unrolling of numerical code. > The only way I can think of to do that that would be to have optional > "enhanced" repos available that people can enable if their system supports > it. The hard part would be keeping it in sync with the main repo. It would > have to be a parallel build process and similar to the current process if > one fails the build is a NOGO across the board. The way to support different micro-architectures is clearly how things like OpenBLAS (or BLIS, if it accepted changes for other architectures) do it, with dispatch on the micro-architecture in the performance-critical parts. Those BLASs do it explicitly (but as far as I know you need to do something like read /proc/cpuinfo on arm32 and s390). Anyhow, if no-one's going to do that, or assemble different variants with target attributes, adding the target_clones function attribute to generic code for the performance-critical routines is likely to be profitable. See the GCC info node on function attributes. (In my experience GCC vectorizes a lot better than people often claim, so you get decent SIMD generated for multiple micro-architectures.) For example, I added target_clones to the plain C GEMM micro-kernel in BLIS and got ~60% of the performance of the hand-crafted code for DGEMM on Haswell. (GEMM is the basis of matrix-matrix linear algebra, if you're not familiar with it.) _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
