https://bugzilla.redhat.com/show_bug.cgi?id=1389016
--- Comment #9 from Dave Love <d.love(a)liverpool.ac.uk> ---
(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