Re: Investigating a reproducibility failure

Hi Simon, > We are far from OpenBLAS. :-) That's fine with me. The more distance between me and OpenBLAS, the happier I am ;-) > On Wed, 16 Feb 2022 at 14:04, Konrad Hinsen > wrote: > >> Making scientific computations bit-for-bit reproducible is the moral >> equivalent of keeping a detailed

Re: Investigating a reproducibility failure

Hi Konrad, We agree on the main points in the scope of Guix. :-) We probably disagree on some specific points about epistemology or epistemic justification; I am not sure to understand enough these terms to put them here. :-) We are far from OpenBLAS. :-) On Wed, 16 Feb 2022 at 14:04, Konrad

Re: Investigating a reproducibility failure

Hi Bengt and Simon, zimoun writes: > Note that some people are calling for bit-to-bit scientific > reproduction. I am not. Because the meaning of “same” or “equal” I am. Not as a goal in itself, because in the larger scientific context it's robust replicability that matters, not bit-for-bit

Re: Investigating a reproducibility failure

Hi, On Tue, 15 Feb 2022 at 15:10, Bengt Richter wrote: > I suspect what you really want to reproduce is not verbatim > code, but the abstract computation that it implements, > typically a digitally simulated experiment? [...] > Maybe the above pi computation could be a start on some kind > of

Re: Investigating a reproducibility failure

Hi, On +2022-02-05 15:12:28 +0100, Ludovic Courtès wrote: > Konrad Hinsen skribis: > > > There is obviously a trade-off between reproducibility and performance > > here. > I suspect what you really want to reproduce is not verbatim code, but the abstract computation that it implements,

Re: Investigating a reproducibility failure

Hi Ludo, > Konrad Hinsen skribis: > >> To see the failure, do >> >>guix time-machine \ >> --commit=7357b3d7a52eb5db1674012c50d308d792741c48 \ >> -- build openblas > > For the record, there’s still a substitute available for this one: ... > That doesn’t solve the fact that OpenBLAS

Re: Investigating a reproducibility failure

Konrad Hinsen skribis: > There is obviously a trade-off between reproducibility and performance > here. I tried hard to dispel that belief: you do not have to trade one for the other. Yes, in some cases scientific software might lack the engineering work that allows for portable performance;

Re: Investigating a reproducibility failure

Hi! Konrad Hinsen skribis: > To see the failure, do > >guix time-machine \ > --commit=7357b3d7a52eb5db1674012c50d308d792741c48 \ > -- build openblas For the record, there’s still a substitute available for this one: --8<---cut here---start->8---

Re: Investigating a reproducibility failure

Hi Ricardo and Simon, Ricardo Wurmus writes: > The case of OpenBLAS is an anomaly in that this mechanism seems to > produce different binaries dependent on where it is built. When I first Thanks a lot for those explanations, I hadn't realized how peculiar OpenBLAS is! > Your problem is that

Re: Investigating a reproducibility failure

Hi Konrad, On Thu, 03 Feb 2022 at 10:16, Konrad Hinsen wrote: >> CPU detection is a bottomless can of worms. > > That sounds very credible. But what can we do about this? Well, I do not know what could be done about this. Today, the picture for OpenBLAS@0.3.6 build looks like: * Fail

Re: Investigating a reproducibility failure

Hi Konrad, >> CPU detection is a bottomless can of worms. > > That sounds very credible. But what can we do about this? > > There is obviously a trade-off between reproducibility and performance > here. Can we support both, in a way that users can understand and manage? So far our default

Re: Investigating a reproducibility failure

Hi Ricardo and Simon, Thanks for your insight! I didn't even know about lscpu. The output for my laptop is shown below. I tried building on a virtual machine, and that works fine. > CPU detection is a bottomless can of worms. That sounds very credible. But what can we do about this? There is

Re: Investigating a reproducibility failure

Ricardo Wurmus writes: > Konrad Hinsen writes: > >> Konrad Hinsen writes: >> >>> To see the failure, do >>> >>>guix time-machine \ >>> --commit=7357b3d7a52eb5db1674012c50d308d792741c48 \ >>> -- build openblas >>> >>> The build log is attached, the first error is >> >> Oops... Two

Re: Investigating a reproducibility failure

Hi Konrad, What is the output of 'lscpu'? For instance, on machine A running on Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz, OpenBLAS for commit 87e7faa2ae641d8302efc8b90f1e45f43f67f6da builds. On machine B running Intel(R) Core(TM) i7-10700K CPU @ 3.80GHz, OpenBLAS for the same commit fails.

Re: Investigating a reproducibility failure

Konrad Hinsen writes: > Konrad Hinsen writes: > >> To see the failure, do >> >>guix time-machine \ >> --commit=7357b3d7a52eb5db1674012c50d308d792741c48 \ >> -- build openblas >> >> The build log is attached, the first error is > > Oops... Two mistakes ! First, I forgot the

Re: Investigating a reproducibility failure

Hi Konrad, I get the same error as you. And for more versions than the only one your tested. For instance, for these commits, * substitutes and rebuilds 923dcc3597 Fri Jan 14 12:59:33 2022 +0100 gnu: iverilog: Update to 11.0. 79ca578182 Thu Nov 11 21:52:08 2021 -0500 gnu: fpc: Fix build.

Re: Investigating a reproducibility failure

Konrad Hinsen writes: > To see the failure, do > >guix time-machine \ > --commit=7357b3d7a52eb5db1674012c50d308d792741c48 \ > -- build openblas > > The build log is attached, the first error is Oops... Two mistakes ! First, I forgot the attachment, so here it comes, Second, I didn't