<rekado>I read it, but I had a hard time empathizing with the problems proposed in the introduction.
<rekado>things like “will MPI use the high-speed interconnect” – is this something that’s actually addressed by continuous integration / delivery?
<rekado>we can know in advance what software will run on the cluster, but there seems to be a lot of runtime variability that’s platform dependent.
<rekado>building software and running its test suite (if available) on a separate system with different specs does not seem to increase confidence in how the software would behave at runtime, given the modular nature of MPI and scheduling systems
<rekado>I guess I’m confused about how the introduction fits with the rest of the article
<rekado>(I could very well be missing something, other than sleep)
<rekado>I will say, though, that this was a lot more comfortable than doing this by hand
<rekado>another colleague — in a misplaced bout of competitive behavior — attempted to rebuild with different options in the traditional haphazard way and got lost in a forest of state and environment variables.
<civodul>the Spack talk i mentioned says a lot about this
<rekado>there’s real value in building software in predictable environments, and since performance is no longer a good argument for not building binaries elsewhere I guess HPC people need to be told that their systems are not special enough to warrant pouring out the reproducible deployment baby with the compilation bath water.
<civodul>exactly, that's the message i'd like to have
<rekado>at the MDC we only really have the first two classes
<rekado>HPC admins care about little more than the scheduler and the hardware itself; users on the other hand are removed enough from software development to have any opinions one way or another about continuous integration (beyond the question “will it *install*?”)
<civodul>well, it depends on the kind of users i guess
<civodul>folks doing linear algebra care a lot about that