[Bug 1389016] Review Request: libxsmm - Library for small matrix-matrix multiplications on Intel x86_64 (e.g. for cp2k)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.redhat.com/show_bug.cgi?id=1389016



--- Comment #11 from Dave Love <d.love@xxxxxxxxxxxxxxx> ---
(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
_______________________________________________
package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]