[Bug 276789] math/openblas: Update to 0.3.26

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276789

--- 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 optimization
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 = 1 and another one for a current host you are building OpenBLAS
on (when DYNAMIC_ARCH = 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 only
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 supports
numerous CPU models with the different instructions sets. But the "bottom line"
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 buggy
implementation of an optimized code or due to some other reasons (higher power
consumption, or suboptimal performance or performance testing) so it's better
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. 
So you wouldn't be able to compile a SANDYBRIDGE optimized code if you enable
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 somehow
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.