On Friday, 11 May 2018 at 19:01:05 UTC, H. S. Teoh wrote:
This sounds scary. So my (strongly!) pure function that
returns floating-point can return different results when passed
the same parameters, if somebody in between changes
floating-point flags? That doesn't sound good at all.
This is an ugly problem, and I'm not sure what the best solution
would be. The current one is simple to understand and only has a
little surprising behavior (multiple invocations to the same pure
function with the same parameters might yield the same results,
even if floating point flags have changed).
I'd like to hear about any reasonable alternatives. Here are a
few unreasonable ones I thought up:
1. The compiler could have the function store its FPU flag state
somewhere. It would involve adding a preamble to each pure
function:
---
static bool fpeInitialized = false;
static fenv_t fpeEnv;
fenv_t previous;
if (fegetenv(&previous)) assert(0, "failed to get FPU
environment");
scope (exit) if (fesetenv(&previous)) assert(0, "failed to
restore FPU environment");
if (fpeInitialized)
{
fesetenv(&fpeEnv);
}
else
{
fpeEnv = previous;
fpeInitialized = true;
}
---
On my machine, that's an overhead of about 2.5 microseconds per
function call. On top of a trivial pure function, it's a 47×
overhead.
But ignoring the performance cost, is that even vaguely
desirable? Whatever you first call the pure function with, it's
always going to use the same FPU environment. Accidentally call
it inside a static constructor and you set your FPU flags in
main() ? Your intent is silently ignored. And should the FPU
environment be thread-local? If it isn't, I might see different
results if I run the same code in different threads. If it is,
then the compiler might need to use atomic variables or locking,
and that would be horribly slow. Plus a surprising runtime
dependency, probably, that prevents pure functions from working
with -betterC.
2. Pure functions could require you to inform the compiler of
your desired FPU flags. This means the compiler, not the runtime,
needs to know about how to set FPU flags on every supported
architecture. It also means it's a lot harder to use pure
functions, and they're less portable. They will also all have
overhead from setting FPU flags and resetting them after, but it
fixes all the other problems from the first option.
3. You could tell the compiler to watch out for people changing
the FPU environment, and then it won't try to omit duplicate
function calls. This means any function that the compiler is not
going to emit into the same object file, or that might be
overridden in another object file. It eats into the promise that
adding `pure` means your code becomes faster automatically.
