[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 #9 from Dave Love <d.love@xxxxxxxxxxxxxxx> ---
(In reply to Hans Pabst from comment #8)
> Thank you all for reviewing/maintaining this package!

Apologies for not referring to it previously.  I hadn't got round to making the
bug report where I just have done before getting back to the review.

Thanks for commenting.

> I was looking at Dave's work/logs since he wrapped it up as a package for
> the first time, and tried to "anticipate" what could be useful for his next
> wrap. Over time this became (but is not limited to):

It's likely I should have paid more attention to your changes...

> * Fairly generic target (by default) when building the library (SSE3) to
> cover a general Linux distribution i.e., critical code is CPUID dispatched.

Unfortunately an SSE2 baseline is necessary for packaging.  (There are actually
AMD Barcelonas -- and older! -- still running here which don't have it, though
they have a variety of sse4a.)

> * Versioned .so files to adhere to standards (major, minor scheme).

I don't know if it's intentional, but the .so links are the wrong way round,
which causes confusion with ldconfig, and I don't think is specific to Fedora:
see the patch for it in the package which I should probably have reported as
well.

> * Warnings during build for "sophisticated" (over-specified) build options,
> which could have inadvertent effects e.g. OMP=1 when building the library.

Should the options be changed, do you think?  I'm still not sure whether OMP=1
is worthwhile.

A problem with the build, which I've just fixed in response to what I'd missed
in fedora-review, is that make install actually builds things, which meant sse3
and openmp were being used inadvertently.  I haven't got round to finding out
why, but have fixed it up in the spec.

> However, this indirect interaction has some limits. Please do not hesitate
> to bring up any issue or annoyance you would like to see fixed
> (https://github.com/hfp/libxsmm/issues). As a side-note, the relatively
> sophisticated GCC build flags are mostly paranoid and present due to "good
> practice". Though, any critical code is either independent of the compiler
> used (JIT) or hand-crafted.

Thanks.  I was assuming there was some highly-optimized C for which they were
important -- life's too short to understand things at the level a packager
probably should...

> As a (likely repeated) comment: the library (under Linux) is agnostic with
> respect to a specific LAPACK/BLAS implementation. Perhaps your (copr)
> dependence on OpenBLAS is just to trigger a presence for *some* BLAS...

Yes, but it's silly to use anything else, and the Makefile looks for openblas
as far as I remember.  I don't understand why rpmlint complains about the
reference to dgemm (?), though.

> I wonder about the item "Large documentation must go in a -doc subpackage.
> Large could be size (~1MB) or number of files." - to me it looks like 3
> files with below 200KB in total.

Thanks.  It was meant to include the samples (which are large).  Is that
worthwhile?  Otherwise, I agree.

> If you don't mind, perhaps you guys can adjust the package description (see
> below for convenience). This is because the functionality now covers deep
> learning primitives, and small JIT generated convolutions as well.

Fine for the description, but the summary is too long for the packaging-defined
limit.  (The current one says x86_64 because ix86 currently doesn't build.) 
How about something like

Small dense or sparse matrix multiplications and convolutions for x86

I don't think the historical reference in the description is useful, but don't
feel strongly about it, and I'd Anglicize a phrase or two.

Thanks, and thanks to Intel for all the free software like this being made
available recently, in contrast to some competitors.  (Just a pity we're
currently missing optimized KNL BLAS.)

I'll wait for any more comments before putting up a new package.

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