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