https://issues.dlang.org/show_bug.cgi?id=18627
--- Comment #13 from Iain Buclaw <[email protected]> --- (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. --
