Differences in results when using the same function in CTFE and Runtime

[Timon Gehr]

On 8/13/24 13:09, Abdulhaq wrote:
> On Tuesday, 13 August 2024 at 08:33:51 UTC, Timon Gehr wrote:
> 
>>
>> It's annoying anyway, and we should hold programming languages to a 
>> higher standard than that.
>>
>>
>> Well, I think the x87 is a bad design as a compilation target. If you 
>> are targeting that with a compiler whose developers by default do not 
>> care about reproducibility, expect weird behavior. These instructions 
>> are now deprecated, so the calculation should change a bit.
> 
> It's an interesting discussion, but we are where we are, and I think 
> you'd agree that the OP should understand that in the current world of 
> "systems"  programming languages, this behaviour would not be viewed as 
> a "bug".
> ...

Well, I think one thing is where we are now, another question is where 
we should be in the future.

> I'm only being somewhat tongue-in-cheek when I say that his application, 
> viewing fractals, could be considered a kind of "chaos amplifier" that 
> is especially prone to these sorts of issues.
> ...

Not really. I think it is valid to expect reproducible results for 
addition, absolute value, and squaring, no matter how many times you 
repeat them. The reason why this issue happened is that D does not even 
try a little bit, and explicitly just goes ahead and uses the wrong data 
type, namely the 80-bit one only supported by the x87.

> I'm going to guess that the situation we're in is due to preference of 
> speed over reproduceability in the days when computers ran much more 
> slowly than they do now.

Ironically, the x87 design is mostly about getting accurate numerics. It 
is a rather inefficient design. One issue is that it was designed for 
assembly programmers, not C compilers. C language features do not map 
well to it. x87 results are reproducible in assembly as it is clear 
where rounding happens.

It is true that computers used to run more slowly, and the x87 is some 
part of the reason why that was true. There are many reasons why the 
design was ditched, efficiency is one of them.

> Would we choose a different priority these days? I don't know.

The x87 results in both slower code and worse reproducibility when used 
as a target for `float`/`double`/`real` computations.

Ironically, IIRC Kahan was involved in the x87 design, yet algorithms 
attributed to him, like Kahan summation, can actually not be implemented 
correctly using D floating-point types, because of the insane rules 
introduced to support targeting the x87 without changing rounding 
precision or spilling data to the cache and reloading it.

At the same time, "better accuracy" is part of the reason why CTFE uses 
higher floating-point precision, but higher precision does not mean the 
result will be more accurate. Unless arbitrary precision is used, which 
is even slower, it leads to double-rounding issues which can cause the 
result to be less accurate.