Date: Mon, 05 Feb 2024 03:52:21 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 276789] math/openblas: Update to 0.3.26 Message-ID: <bug-276789-7788-aB0COqTeLS@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-276789-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-276789-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276789 --- Comment #7 from Artyom Davidov <ard_1@mail.ru> --- (In reply to Daniel Engberg from comment #6) It is true that OpenBLAS tries to figure out the most appropriate optimizat= ion options by itself but you should consider some things before trying to "enhance" some things in it or patch it somehow or make some changes to it's build process. 1. There are globally two build paths in the OpenBLAS - one for the DYNAMIC_ARCH =3D 1 and another one for a current host you are building Open= BLAS on (when DYNAMIC_ARCH =3D 1 isn't set) 2. When DYNAMIC_ARCH is unset, then OpenBLAS auto-detects the current CPU = type of a build host and compiles it's library with the code that is optimized o= nly for the CPU of the build host. This leads to a smaller library size, and a faster compilation time. The drawback of a such approach is that the library code will not work on a CPU with a different instructions set or it will perform suboptimal on a newer CPUs (ie with a larger cache sizes). 3. When DYNAMIC_ARCH is set to 1 then OpenBLAS builds all the available CPU modules (except "older" ones) but it will optimize it's common code to the = CPU it is being compiled on. This leads to an increased compilation times and a resulting library size increase significantly. But the resulting code suppo= rts numerous CPU models with the different instructions sets. But the "bottom l= ine" of the common code optimizations is still tied to the host you are building OpenBLAS on. 4. The "upper bound" for the optimizations of the both build paths (with and without DYNAMIC_ARCH) are controlled with the three AVX options. Though the actual behavior is a bit different when DYNAMIC_ARCH is set to disabled, we= can assume this for the sake of simplicity. 5. The "lower bound" of optimizations for the build path with a DYNAMIC_ARCH set to enabled could be controlled with the TARGET OpenBLAS Makefile.rules option. It could (or should) be set to a lowest possible target CPU arch you are planning to run that OpenBLAS library on. 6. The behavior of the TARGET option when DYNAMIC_ARCH is unset is a bit different - it allows you to compile an OpenBLAS library for a specific CPU target family only. Considering an AVX options: Sometimes it is necessary to disable AVX512 or AVX2 instructions due to bug= gy implementation of an optimized code or due to some other reasons (higher po= wer consumption, or suboptimal performance or performance testing) so it's bett= er to leave all those three PORTOPTIONS in the ports Makefile. Another thing to consider is that when the DYNAMIC_ARCH is set to enabled, = an AVX options not only control the "upper bounds" of optimizations but and a "lower bounds" too. You can check the summary section of the build logs attached to this bug to get familiar with this behavior.=20 So you wouldn't be able to compile a SANDYBRIDGE optimized code if you enab= le all AVX options all together or disable them at all. But you can accomplish this using TARGET option, but since there is no mapping of FreeBSD CPUTYPE make.conf option to an OpenBLAS TARGET Makefile.rules options it is not a trivial task to do. To summarize all of the above - there is no need to patch OpenBLAS or someh= ow manually interfere with it's build process - there are existing knobs in a Makefile.rules file that could be used to get the needed compilation (and optimization) results. And setting those options via Makefile.rules is the = way that is expected to be used by the OpenBLAS developers. Considering the post-patch section in the current ports Makefile - if there= is a better way to make changes to an OpenBLAS Makefile.rules file, I guess it= can be modified to use it. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-276789-7788-aB0COqTeLS>