I was expecting them to be aware of https://herbie.uwplse.org/ Herbie but it seems like either they don't know of it or they don't see it as relevant.
My hope for the future is that Herbie's approach can evolve to a point where the person writing the software doesn't directly write FPU operations, any more than you'd manually work out all the best ways to optimise integer arithmetic. You write what you meant and the compiler figures out how to deliver that with FPU instructions. The parameters are more complicated for the second operation, but it's surely tractable.
"I want to calculate function F(x) here, I care about 0 <= x <= 4.0, inside those limits we need +/- 0.1% accuracy, for other values I don't care, and I want you to go as fast as possible within those parameters".
FPChecker and Herbie are complementary. FPChecker runs the dynamic analysis to figure what your code is actually doing under realistic workloads, which gives you the information to make those code improvements via other tools like Herbie.
Part of the issue with saying what you mean in numerical code is that approximately no-one outside a small cadre of experts bothers to do numerical analysis. And unless you're in HPC, very few of those experts are optimizing for the kind of constraints your program has. Gamedevs often care more about reproducibility and performance than characterizing accuracy or stability, for example [0].
This tool is neat because you can take whatever garbage code you're given and dynamically analyze it in-situ as a quick first step that might suffice instead of a much more difficult numerical analysis.
I'm someone who has worked on Herbie. AFAIK we work(ed) with the LLNL guys and they are aware of Herbie! Floating Point research is a very small world.
FPChecker looks very cool. I wish the exponent graph had the option to show base 2 though, so it's slightly easier to map it back to the underlying float representation.
I was expecting them to be aware of https://herbie.uwplse.org/ Herbie but it seems like either they don't know of it or they don't see it as relevant.
My hope for the future is that Herbie's approach can evolve to a point where the person writing the software doesn't directly write FPU operations, any more than you'd manually work out all the best ways to optimise integer arithmetic. You write what you meant and the compiler figures out how to deliver that with FPU instructions. The parameters are more complicated for the second operation, but it's surely tractable.
"I want to calculate function F(x) here, I care about 0 <= x <= 4.0, inside those limits we need +/- 0.1% accuracy, for other values I don't care, and I want you to go as fast as possible within those parameters".
FPChecker and Herbie are complementary. FPChecker runs the dynamic analysis to figure what your code is actually doing under realistic workloads, which gives you the information to make those code improvements via other tools like Herbie.
Part of the issue with saying what you mean in numerical code is that approximately no-one outside a small cadre of experts bothers to do numerical analysis. And unless you're in HPC, very few of those experts are optimizing for the kind of constraints your program has. Gamedevs often care more about reproducibility and performance than characterizing accuracy or stability, for example [0].
This tool is neat because you can take whatever garbage code you're given and dynamically analyze it in-situ as a quick first step that might suffice instead of a much more difficult numerical analysis.
[0] https://jrouwe.github.io/JoltPhysics/#deterministic-simulati...
I'm someone who has worked on Herbie. AFAIK we work(ed) with the LLNL guys and they are aware of Herbie! Floating Point research is a very small world.
That's great news
FPChecker looks very cool. I wish the exponent graph had the option to show base 2 though, so it's slightly easier to map it back to the underlying float representation.
Is there actually video of the talk?