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.
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
