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

2021-04-23 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18627 Iain Buclaw changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|---

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

2021-04-16 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18627 Iain Buclaw changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED

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

2021-03-24 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18627 --- Comment #14 from ponce --- No problem from here, a lot of our complex code is now SIMD. I doubt we'll see a practical problem apart from the transition work. It's easy to recreate the desired division algorithm manually if ever needed. --

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

2021-03-24 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18627 --- Comment #13 from Iain Buclaw --- (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 >

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

2021-03-22 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18627 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

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

2021-02-27 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18627 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #11 from Dlang Bot ---

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

2020-07-05 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18627 --- Comment #10 from Iain Buclaw --- (In reply to ponce from comment #4) > This benchmark is a variation that does only division. > > --- divide.d * With gdc -O2 -frelease -m64 With cfloat: 11 secs, 204 ms, 475 μs, and 2 hnsecs With cdouble: 13

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

2018-03-22 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18627 --- Comment #9 from ponce --- I think at the very least std.complex should contain a function to divide Complex without the additional precision provided by the check with the 2 fabs(). People that want speed could opt-in, and

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

2018-03-20 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18627 --- Comment #8 from ponce --- @Seb: It's not only about DMD, there is a 2x performance regression with Complex!double vs cdouble using LDC. There are probably more I haven't exposed yet. And yes, I use cdouble for designing IIR

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

2018-03-20 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18627 Seb changed: What|Removed |Added CC||greensunn...@gmail.com ---

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

2018-03-20 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18627 --- Comment #6 from ponce --- Conversely complex divide seems faster with DMD with std.complex than builtins. --

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

2018-03-20 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18627 --- Comment #5 from ponce --- Division with DMD 32-bit: With cfloat: 1 minute, 18 secs, 451 ms, 932 ╬╝s, and 9 hnsecs With cdouble: 1 minute, 19 secs, 747 ms, 70 ╬╝s, and 5 hnsecs With Complex!float: 27 secs, 412 ms, 926 ╬╝s, and

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

2018-03-20 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18627 --- Comment #4 from ponce --- This benchmark is a variation that does only division. --- divide.d import std.string; import std.datetime; import std.datetime.stopwatch : benchmark, StopWatch; import std.complex; import

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

2018-03-20 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18627 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org

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

2018-03-18 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18627 --- Comment #2 from ponce --- I've posted there, thanks. --

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

2018-03-18 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18627 greenify changed: What|Removed |Added CC||greeen...@gmail.com ---