https://bugzilla.redhat.com/show_bug.cgi?id=1389016
--- Comment #11 from Dave Love <d.l...@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 _______________________________________________ package-review mailing list -- package-review@lists.fedoraproject.org To unsubscribe send an email to package-review-le...@lists.fedoraproject.org
