***efraim_ is now known as efraim
***zimoun` is now known as zimoun
<rekado>“The author remembers advice heard at the beginning of their career in HPC and until today” <rekado>this sounds a bit clunky because “beginning” and “until today” are lumped in with “remember” <rekado>maybe a few more words here could separate the two concepts <rekado>e.g. “— advice still given today —” instead of “and until today” <rekado>“all the software stack” —> “the complete software stack” <rekado>a similar conflation of past and present: “automated software deployment as pioneered by Debian […] or, more recently, with container images” <rekado>it’s the “pioneered” that bleeds into the second part of the sentence <rekado>a random thought re reproducibility: when the most efficient implementation is selected then we don’t run the “same” code and we can get different results. This can be a surprising outcome. <rekado>(in the case of our openblas package we also have the problem that we can only build more efficient code when the CPU of the build machine has support for these newer instruction sets) <rekado>(so the binary differs *and* the runtime behavior may differ) *rekado takes a break, will read the rest after dinner <civodul>rekado: yay, thanks for the useful suggestions already! <civodul>re "not running the same code", that's true <civodul>in a way, multi-versioned functions could be viewed as "non-deterministic" if we take the CPU out of the picture <civodul>more pragmatically, you could have one version that's buggy and another one that's fine <civodul>though should we discuss it in the post? <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>the link to Nix 2.4 is fine, though <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 *rekado upgrades R packages <rekado>ah: Please downgrade your bazel installation to version 0.26.1 or lower to build TensorFlow <civodul>rekado: cool, thanks for all the comments! <civodul>really great to have high-quality and timely feedback <civodul>the repetition was not for comical effect actually, i suppose it might have been for disambiguation <civodul>re the very last paragraph, i thought about it as an "opening" but yeah, it seems misplaced <civodul>rekado: so even with Bazel there are bumps on the road, bummer <rekado>it won’t let you build if you don’t have the right minor version of Bazel. <rekado>I do think that we should put our efforts into packaging bazel, though. Tensorflow is just too painful to work with. <rekado>fixing dozens of cmake files just is no fun <rekado>I’ll first try to take the bazel binary and build the latest tensorflow in a Guix build environment. <rekado>then see how many hoops we need to jump through to unbundle third party code and build without network <civodul>yeah this probably needs to be incremental <civodul>i suppose we'll have to live with some level of bundling for a while