On Sat, Dec 18, 2021 at 07:05:20AM -0700, j...@bitminer.ca wrote: > > > Would it make sense to replace blas with openblas? > > > > IMHO, no. And to qualify my opinion, I don't use it much at all. > > OpenBLAS (which includes LAPACK) is a very highly optimized set of > codes with numerous cpu-specific optimizations for many ISAs. > > Build instructions include "Simply invoking make (or gmake on BSD) > will detect the CPU automatically. To set a specific target CPU, > use make TARGET=xxx, e.g. make TARGET=NEHALEM." > > So, what would be the baseline target for OpenBSD amd64 ports? > Nehalem? Coppermine? Opteron? I'm not trying to be cute, I just > don't know. The default for OpenBLAS appears to be Nehalem. > > And the same question for other instruction-set architectures. > > > On 17 December 2021 13:43:25 Rafael Sadowski <raf...@sizeofvoid.org> > > wrote: > > > On Fri Dec 17, 2021 at 01:03:30PM +0800, Kevin Lo wrote: > > > Hi, > > > > > > Please find attached a port of the openblas. > > > > > > Description: > > > OpenBLAS is an optimized BLAS (Basic Linear Algebra Subprograms) > > > library > > > based on GotoBLAS2 1.13 BSD version. > > > > > > It's loosely based on the one at openbsd-wip [1]. > > > I tested on i386, amd64, arm, arm64, and mips64. > > > > > This is good to test, but since there are a number of dependent > packages, and CPUs, it would be good to have (a) a bulk-build and (b) > some user-experience include before/after tests for various CPUs. Which > is a ton of work, I know. It's too much to ask I think. > > (assumption: OpenBLAS should replace blas/cblas/lapack. But see below.) > > Alternatively, supply instructions for users to build it (and > dependencies) locally and apply a little logging/tracing to create > before/after test data. Few people have useful test cases though. > Also more work, but at least only interested people can try and > there's little risk (*)] for them. > > [(*), if it doesn't work, pkg_delete/pkg_add]. > > (assumption: interested users aren't too familiar with porting and > need some handholding) > > I don't know how many OpenBSD scientific software users there are; > possibly only a fraction are willing to do their own porting to test this. > > Third alternative: as with Python2 vs Python3, put OpenBLAS into it's own > namespace (/usr/local/include/OpenBLAS/ /usr/local/lib/OpenBLAS/) and let > porters gradually adopt it. If nobody does after a few releases, then > it was not as popular as imagined.
My intention was not replace blas and lapack. If porters/users would like to use openblas instead of blas and lapack, feel free to use it, no? > John
