| |
| Posted by Timon Gehr in reply to Abdulhaq | PermalinkReply |
|
Timon Gehr
Posted in reply to Abdulhaq
| 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.
|