https://bugzilla.redhat.com/show_bug.cgi?id=1389016
--- Comment #11 from Dave Love <d.love(a)liverpool.ac.uk> ---
(In reply to Hans Pabst from comment #10)
> Unfortunately an SSE2 baseline is necessary for packaging.
Well, SSE2 is "nothing" wrt 64-bit since it's already part of the 64-bit
ABI.
Yes, that's the point. This is a policy issue for packaging, not anything to
do with practical reality for HPC. (However, there were first generation (?)
opterons online here until a PSU blew recently...)
> There are actually AMD Barcelonas
They support SSE3; no problem!
[Oh, I see it's included in "PNI" if I look at cpuid rather than cpuinfo.]
> I'm still not sure whether OMP=1 is worthwhile.
Sorry my comment might have been misleading. The library warns if you use
OMP=1 since it's meant to be agnostic wrt threading runtime. The OpenMP
compiler flags is automatically applied only for libxsmmext, which is meant
to keep the OpenMP dependency separate. In the early times of LIBXSMM, OMP=1
(when applied) meant to use OpenMP synchronization primitives for the code
registry (instead of OS-level primitives or Pthreads). The warning I was
mentioning is related to the latter.
> Yes, but it's silly to use anything else
There OpenBLAS is the default I am looking for (just learned people would
take it in any case). However, RefLAPACK/BLAS is surprisingly good (I
believe for small matrices it even better than OpenBLAS). But sure, relying
on OpenBLAS makes much sense.
> I don't understand why rpmlint complains about the reference to dgemm (?)
This is a real dependency on the ?gemm_ symbol. Anyhow, this symbol is still
satisfied by any kind BLAS (OpenBLAS, RefLAPACK/BLAS, MKL, ATLAS, etc.)
Yes, I just couldn't see why the warning was emitted when the blas is linked.
> It was meant to include the samples (which are large).
> Is that worthwhile?
No it's not worth. People who want the dev-package would typically need to
copy the sample source code anyways into a writable destination. If the
sample source code would not compile then (or easy to get it to) -- the
impression of the library will be ruined (which is not your problem :-).
Examples from the distributed source are typically included in -doc rpms, or a
separate -examples one, though I don't remember specific policy on that, and
there's only any point if they are useful. However, I don't understand why the
samples are included if they are problematic -- I'm doubtless
mis-understanding.
> Small dense or sparse matrix multiplications and convolutions
for x86
Sure go ahead! I am not on particular words e.g., this NA Digest
(
http://www.netlib.org/na-digest-html/16/v16n38.html; search for LIBXSMM)
says:
"Library for small convolutions (Machine Learning), and small dense or
sparse matrix multiplications." (which leaves out the mighty x86 ;-)
OK. I assumed there was a desire to say "Intel" as much as possible and I
only took that out of the summary to shorten it -- but slightly undo that by
saying x86_64, as the packaging is specific.
> Just a pity we're currently missing optimized KNL BLAS.
I guess the MKL community download is somewhat inconvenient?
It's obviously not usable for Fedora or OK for general use on a cluster. (I
read the conditions, unlike most people...)
As a side-note, LIBXSMM makes some attempt to come up with regular
BLAS
sizes as well (status may be here:
https://github.com/hfp/libxsmm/issues/99#issuecomment-255314392). First
signs are the libxsmm_gemm_omp functions and the "blkgemm" sample code. A
lot of work is still left.
Thanks for the pointer (and the rest); I'll pass it on.
A new srpm may have to wait until Monday now.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component