[Issue 18627] std.complex is a lot slower than builtin complex types at number crunching

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=18627

--- Comment #13 from Iain Buclaw <ibuclaw at gdcproject.org> ---
(In reply to ponce from comment #4)
> RESULTS
> 
> * With ldc 1.8.0 64-bit:
> 
> $ ldc2.exe -O3 -enable-inlining -release divide.d -m64
> $ divide.exe
> 
> With cfloat: 7 secs, 623 ms, 829 ╬╝s, and 9 hnsecs
> With cdouble: 7 secs, 594 ms, 449 ╬╝s, and 8 hnsecs
> With Complex!float: 7 secs, 988 ms, 642 ╬╝s, and 4 hnsecs
> With Complex!double: 15 secs, 501 ms, 128 ╬╝s, and 4 hnsecs
> 
> 
> * With ldc 1.8.0 32-bit:
> 
> $ ldc2.exe -O3 -enable-inlining -release divide.d -m32
> $ divide.exe
> 
> With cfloat: 7 secs, 618 ms, 202 ╬╝s, and 1 hnsec
> With cdouble: 7 secs, 593 ms, 777 ╬╝s, and 2 hnsecs
> With Complex!float: 7 secs, 958 ms, 692 ╬╝s, and 9 hnsecs
> With Complex!double: 15 secs, 414 ms, and 344 ╬╝s
> 
> 
> This show that even with latest LDC you can have a regression.
> 
> I appreciate that std.complex gives more precision in the divide operation,
> it's also something that is _different_ from builtin complex it replaces.

A bug probably should be raised against LDC for not using range reduction (i.e:
Smiths algorithm) in their native complex division implementation.

The slowdown is not a regression, LDC is just using the wrong algorithm by
default (i.e: the "fast" naive version should be generated only when compiling
with `-ffast-math`).

GDC and LDC could coordinate with each other and predefine `version(FastMath)`
when the `-ffast-math` flag is given on the command-line.

--