Why don't we switch to C like floating pointed arithmetic instead of automatic expansion to reals?

Iain Buclaw via Digitalmars-d digitalmars-d at puremagic.com
Sat Aug 6 01:59:50 PDT 2016


On 4 August 2016 at 23:38, Seb via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Thursday, 4 August 2016 at 21:13:23 UTC, Iain Buclaw wrote:
>>
>> On 4 August 2016 at 01:00, Seb via Digitalmars-d
>> <digitalmars-d at puremagic.com> wrote:
>>>
>>> To make matters worse std.math yields different results than
>>> compiler/assembly intrinsics - note that in this example import std.math.pow
>>> adds about 1K instructions to the output assembler, whereas llvm_powf boils
>>> down to the assembly powf. Of course the performance of powf is a lot
>>> better, I measured [3] that e.g. std.math.pow takes ~1.5x as long for both
>>> LDC and DMD. Of course if you need to run this very often, this cost isn't
>>> acceptable.
>>>
>>
>> This could be something specific to your architecture.  I get the same
>> result on from all versions of powf, and from GCC builtins too, regardless
>> of optimization tunings.
>
>
> I can reproduce this on DPaste (also x86_64).
>
> https://dpaste.dzfl.pl/c0ab5131b49d
>
> Behavior with a recent LDC build is similar (as annotated with the
> comments).

When testing the math functions, I chose not to compare results to
what C libraries, or CPU instructions return, but rather compared the
results to Wolfram, which I hope I'm correct in saying is a more
reliable and proven source of scientific maths than libm.

As of the time I ported all pure D (not IASM) implementations of math
functions, the results returned from all unittests using 80-bit reals
were identical with Wolfram given up to the last 2 digits as an
acceptable error with some values.  This was true for all except
inputs that were just inside the domain for the function, in which
case only double precision was guaranteed.  Where applicable, they
were also found to in some cases to be more accurate than the inline
assembler or yl2x implementations version paths that are used if you
compile with DMD or LDC.


More information about the Digitalmars-d mailing list