On Fri, Oct 13, 2023 at 08:22:21AM -0600, [email protected] wrote: > > On 2023-10-13 07:16, Marc Espie wrote: > > On Thu, Oct 12, 2023 at 10:01:00AM -0600, [email protected] wrote: > >> > > >> > Not really sure how to test it. If I try running it with no HPL.dat > >> > file present I get a segfault: > >> > >> There is some detailed guidance at > >> > >> https://www.pugetsystems.com/labs/hpc/how-to-run-an-optimized-hpl-linpack-benchmark-on-amd-ryzen-threadripper-2990wx-32-core-performance-1291/ > >> > >> the gist of which is: you need a lot of care in selecting all the > >> relevant software that goes with it, such as Blas, OpenBLAS or the > >> Intel > >> or AMD equivalent substitutes. > > > > Right now, we don't have anything besides blas. > > > > True. There was an effort to port OpenBLAS but that seems to require > a complete changeover from BLAS to OpenBLAS in one go. Nobody > wanted to risk it.
Do you mean to say that having two ports producing different, but equally named, libraries, is not possible in OpenBSD? What's wrong in having an OpenBLAS port available, next to NETLIB BLAS/LAPACK? That some obscure ports on obscure platforms might break? I really don't know any BLAS/LAPACK-using application which cannot use OpenBLAS. Nor I know anyone who uses NETLIB BLAS/LAPACK for serious computational work. Anyway, there is a totally safe way too (used with readline- where ereadline library is produced by the modern readline in ports, and readline name is reserved by the old, system one). Give libraries produced by OpenBLAS different names (and put the headers in a different directory) Surely this would require extra work for using it, but, well, better this than nothing at all. Best, Dima > > > >> Since a port would have no choices in any of these, esp since > >> there is no port of the AMD Blis library, I wonder at the utility > >> of this. > >> > >> I suggest this would provide an opening for critics that "OpenBSD is > >> slow and here is the proof." It's not a relevant complaint but > >> it is a source of noise. > > > > With this kind of mentality, we're never going anywhere. > > > > Benchmarks can be used to figure out where the bottlenecks are, > > possibly > > motivate people to port more stuff to make it go faster. > > > > In the case of hpl, a port can be used for performance regression > testing, possibly for functional regression testing (depending on > use of "rand48"), and for compiler regress tests. > > A port of hpl would not be used by any competitive tester; instead > I believe they would custom-compile it for "best possible speed". > And they would run into "no OpenBLAS, no MKL, no Neon, no etc etc > etc"). > > > > It's also possible to do "fair" comparisons, run it with similar > > parameters > > and identical libraries to figure out what makes us slow (or fast). > > > > > > As far as this specific benchmark is concerned, upstream is positively > > ancient, > > poorly taken care of, and they clearly do not even care about fixing > > obvious > > bad patterns or providing a consistent tarball with correct > > documentation. > > > > It's the same with netlib blas. > > I'm working on github flame/blis port which has a lot of promise > but is weeks or months away (of my testing) to have any confidence > to publish. It appears to be installable concurrently with math/blas > and can be selectively applied on a port-by-port basis (change > -lblas to -lblis). This would solve the "big-bang" problem of > OpenBLAS. > > > > Hence the initial patches, and more to come. > > Looking forward to them! > > > J >
