This seems more like a use case for static analysis that checked operations to me. The problem IIUC isn't about the usage of high-performance code that is unsafe, but rather that the system was nominally tested, but tested in an imperfect way that didn't cover the failure cases. If you were rewriting this in Rust, it's easy for me to imagine that you would use checked arithmetic at the start until 5 years have passed, then you would decide it's safe and turn off the checks -- all because you had never really tested the obscure cases that only a static analyzer is likely to catch.
-- John On Wednesday, July 13, 2016 at 1:07:59 PM UTC-7, Erik Schnetter wrote: > > We have this code <https://einsteintoolkit.org> that simulates black > holes and other astrophysical systems. It's written in C++ (and a few other > languages). I obviously intend to rewrite it in Julia, but that's not the > point here. > > One of the core functions allows evaluating (interpolating) the value of a > function at any point in the domain. That code was originally written in > 2002, and has been used and optimized and tested extensively. So you'd > think it's reasonably bug-free... > > Today, a colleague ran this code on Blue Waters, using 32,000 nodes, and > with some other parameters set to higher resolutions that before. Given the > subject of the email, you can guess what happened. > > Luckily, a debugging routine was active, and caught an inconsistency (an > inconsistent domain decomposition), alerting us to the problem. > > Would Julia have prevented this? I know that everybody wants speed -- and > if you are using 32,000 nodes, you want a lot of speed -- but the idea of > bugs that only appear when you are pushing the limits makes me > uncomfortable. So, no -- Julia's unchecked integer arithmetic would not > have caught this bug either. > > Score: Julia vs. C++, both zero. > > -erik > > -- > Erik Schnetter <[email protected] <javascript:>> > http://www.perimeterinstitute.ca/personal/eschnetter/ >
