<rekado>I don’t know if it should be in *this* post, but I feel that it should be discussed at some point.
<rekado>because so far we’ve been happy to ignore the CPU
<rekado>“tacking ever more powerful SIMD extensions [+on]to their CPUs”
<rekado>hmm, looks like “tack sth to sth” also works
<rekado>the duplication here is amusing: “it is up to each package using them to figure out what to do in terms of performance portability.¶In practice, users of these C++ header-only libraries often do not do anything to achieve performance portability.”
<rekado>I don’t know if this was for comical effect; if it wasn’t then the echo of “do ... performance portability.” at least draws attention to itself.
<rekado>“passing the wrong name to -march could result [-to][+in] obscure compilation errors”
<rekado>hmm, the link to Spack will probably not be received well
<rekado>the link points to something embarassing, but I think this post can do without pointing
<rekado>a clarification request about how grafts are used here:
<rekado>the illustration makes it seem like opencv is “the same” in both cases
<rekado>but really it’s a new thing — with all references to the old VTK replaced
<rekado>I think it’s fine the way the post explains it, but I was taken aback a little and thought I had misunderstood how grafts work.
<rekado>“opencv … instead is relinked against the optimized VTK variant.” — I never conceptualized this as relinking, though it most certainly is.
<rekado>ah, there we go: “ When --tune is used, from Guix’s viewpoint, it is just an alternate, but well-defined dependency graph that gets built”
<rekado>maybe that paragraph could be moved up, and the paragraph on substitutes would be the last.
<rekado>I find the very last paragraph a little weak. It seems to take a step back to FMV from the very beginning.
<rekado>I think that’s a bit out of place for the conclusion
<rekado>the paragraph above it works fine as a conclusion, though it may be just a little short
<rekado>final thoughts: it’s a great description of this feature. I think it’s very cool how it was implemented — certainly nicer than a convention to move disabling of tuning to separate build phases so they can be removed more easily, or any such tricks.
<rekado>I found myself nodding along, so the problems are well-motivated, and the solution strikes a very comfortable balance. It made me want to try this out and find bioinfo packages to mark as tunable :)
***Noisytoot_ is now known as Noisytoot
<rekado>I don’t understand how to build tensorflow with bazel
<rekado>bazel prints confusing output and eventually fails
<rekado>there are no instructions on how to build from source