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 la
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 H
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 r
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
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,
typicall
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 c
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; bu
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---
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 t
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
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 appro
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 ob
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
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.
Chee
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 attachme
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.
ab0cf
Hi everyone,
Two years ago, I published a supposedly reproducible computation,
explaining how to re-run it at any time using Guix (it's at
https://github.com/khinsen/rescience-ten-year-challenge-paper-3/). Yesterday,
I got an e-mail from someone who tried, and failed. I tried myself, and
failed as
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
18 matches
Mail list logo
