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

Quirin Schroll qs.il.paperinik at gmail.com
Tue Aug 13 11:02:07 UTC 2024


On Monday, 12 August 2024 at 11:06:15 UTC, IchorDev wrote:
> On Monday, 12 August 2024 at 10:22:52 UTC, Quirin Schroll wrote:
>> On almost all non-embedded CPUs, doing non-vector calculations 
>> in `float` is more costly than doing them in `double` or 
>> `real` because for single-arguments, the floats are converted 
>> to `double` or `real`. I consider `float` to be a type used 
>> for storing values in arrays that don’t need the precision and 
>> save me half the RAM.
>
> I don’t care. Only one family of CPU architectures supports 
> ‘extended precision’ floats (because it’s a waste of time), so 
> I would like to know a way to always perform calculations with 
> double precision for better cross-platform consistency. Imagine 
> trying to implement JRE without being able to do native double 
> precision maths.

I honestly don’t know how JRE did implement `double` operations 
on e.g. the Intel 80486, but if I try using `gcc -mfpmath=387 
-O3` and add some `double` values, intermediate results are 
stored and loaded again. Very inefficient. If I use `long 
double`, that does not happen.

The assertion that only one CPU family supports extended floats 
is objectively wrong. You probably meant the x86 with its 80-bit 
format, which is still noteworthy, as x86 is very, very common. 
However, at least the POWER9 family supports 128-bit IEEE-754 
quad quadruple-precision floats. IIUC, RISC-V also supports them.


More information about the Digitalmars-d mailing list