On Tuesday, 6 March 2018 at 18:41:15 UTC, H. S. Teoh wrote:
The fix itself may be straightforward, but how to do it without
breaking tons of existing code and provoking user backlash is
the tricky part.
[snip]
Ah, I see what you're saying. People may be depending on the
extra accuracy for
On Tue, Mar 06, 2018 at 06:05:59PM +, jmh530 via Digitalmars-d-learn wrote:
> On Tuesday, 6 March 2018 at 17:51:54 UTC, H. S. Teoh wrote:
> > [snip]
> >
> > I'm not advocating for getting *rid* of 80-bit float support, but
> > only to make it *optional* rather than the default, as currently
>
On Tuesday, 6 March 2018 at 17:51:54 UTC, H. S. Teoh wrote:
[snip]
I'm not advocating for getting *rid* of 80-bit float support,
but only to make it *optional* rather than the default, as
currently done in std.math.
T
Aren't there two issues: 1) std.math functions that cast to real
to pe
On Tue, Mar 06, 2018 at 08:12:57AM +0100, Robert M. Münch via
Digitalmars-d-learn wrote:
> On 2018-03-05 20:11:06 +, H. S. Teoh said:
>
> > Walter has been adamant that we should always compute std.math.*
> > functions with the `real` type, which on x86 maps to the non-IEEE
> > 80-bit floats.
On Tuesday, 6 March 2018 at 08:20:05 UTC, J-S Caux wrote:
On Tuesday, 6 March 2018 at 07:12:57 UTC, Robert M. Münch wrote:
On 2018-03-05 20:11:06 +, H. S. Teoh said:
[snip]
Now, with Uknown's trick of using the C math functions, I can
reconsider. It's a bit of a "patch" but at least it wor
On Tuesday, 6 March 2018 at 07:12:57 UTC, Robert M. Münch wrote:
On 2018-03-05 20:11:06 +, H. S. Teoh said:
Walter has been adamant that we should always compute
std.math.*
functions with the `real` type, which on x86 maps to the
non-IEEE 80-bit
floats. However, 80-bit floats have been de
On Monday, 5 March 2018 at 20:11:06 UTC, H. S. Teoh wrote:
Walter has been adamant that we should always compute
std.math.* functions with the `real` type
T
I don't understand why atan(float) returns real and atan(double)
return real too. If I'm working with float, why does it return a
real?
On 2018-03-05 20:11:06 +, H. S. Teoh said:
Walter has been adamant that we should always compute std.math.*
functions with the `real` type, which on x86 maps to the non-IEEE 80-bit
floats. However, 80-bit floats have been deprecated for a while now,
Hi, do you have a reference for this? I
On Monday, 5 March 2018 at 06:01:27 UTC, J-S Caux wrote:
So the codes are trivial, simply some check of raw speed:
double x = 0.0;
for (int a = 0; a < 10; ++a) x += atan(1.0/(1.0 +
sqrt(1.0 + a)));
for C++ and
double x = 0.0;
for (int a = 0; a < 1_000_000_000; ++a) x += atan
On Monday, 5 March 2018 at 21:05:19 UTC, bachmeier wrote:
I wonder if Ilya has worked on any of this for Mir.
Mir has sin and cos, but that's it. It looks like they use llvm
intrinsics on LDC and then fall back to phobos' implementation.
On Monday, 5 March 2018 at 20:11:06 UTC, H. S. Teoh wrote:
Walter has been adamant that we should always compute
std.math.* functions with the `real` type, which on x86 maps to
the non-IEEE 80-bit floats. However, 80-bit floats have been
deprecated for a while now, and pretty much nobody care
On Mon, Mar 05, 2018 at 06:39:21PM +, J-S Caux via Digitalmars-d-learn
wrote:
[...]
> I've tested these two very basic representative codes:
> https://www.dropbox.com/s/b5o4i8h43qh1saf/test.cc?dl=0
> https://www.dropbox.com/s/zsaikhdoyun3olk/test.d?dl=0
>
> Results:
>
> C++:
> g++ (Apple LLV
On Monday, 5 March 2018 at 18:39:21 UTC, J-S Caux wrote:
But now comes the question: can the D fundamental maths
functions be propped up to be as fast as the C ones?
Probably, if someone takes the time to look at the bottlenecks.
On Monday, 5 March 2018 at 09:48:49 UTC, Uknown wrote:
Depending on your platform, the size of `double` could be
different between C++ and D. Could you check that the size and
precision are indeed the same?
Also, benchmark method is just as important as benchmark code.
Did you use DMD or LDC a
On Monday, 5 March 2018 at 06:01:27 UTC, J-S Caux wrote:
On Monday, 5 March 2018 at 05:40:09 UTC, rikki cattermole wrote:
On 05/03/2018 6:35 PM, J-S Caux wrote:
I'm considering shifting a large existing C++ codebase into D
(it's a scientific code making much use of functions like
atan, log etc
On Monday, 5 March 2018 at 05:35:28 UTC, J-S Caux wrote:
I'm considering shifting a large existing C++ codebase into D
(it's a scientific code making much use of functions like atan,
log etc).
I've compared the raw speed of atan between C++ (Apple LLVM
version 7.3.0 (clang-703.0.29)) and D (d
On Monday, 5 March 2018 at 06:01:27 UTC, J-S Caux wrote:
On Monday, 5 March 2018 at 05:40:09 UTC, rikki cattermole wrote:
On 05/03/2018 6:35 PM, J-S Caux wrote:
I'm considering shifting a large existing C++ codebase into D
(it's a scientific code making much use of functions like
atan, log etc
On Monday, 5 March 2018 at 05:40:09 UTC, rikki cattermole wrote:
atan should work out to only be a few instructions (inline
assembly) from what I've looked at in the source.
Also you should post the code you used for each.
Should be 3-4 instructions. Load input to the FPU (Optional?
Depends
On 05/03/2018 7:01 PM, J-S Caux wrote:
On Monday, 5 March 2018 at 05:40:09 UTC, rikki cattermole wrote:
On 05/03/2018 6:35 PM, J-S Caux wrote:
I'm considering shifting a large existing C++ codebase into D (it's a
scientific code making much use of functions like atan, log etc).
I've compared
On Monday, 5 March 2018 at 05:40:09 UTC, rikki cattermole wrote:
On 05/03/2018 6:35 PM, J-S Caux wrote:
I'm considering shifting a large existing C++ codebase into D
(it's a scientific code making much use of functions like
atan, log etc).
I've compared the raw speed of atan between C++ (Appl
On 05/03/2018 6:35 PM, J-S Caux wrote:
I'm considering shifting a large existing C++ codebase into D (it's a
scientific code making much use of functions like atan, log etc).
I've compared the raw speed of atan between C++ (Apple LLVM version
7.3.0 (clang-703.0.29)) and D (dmd v2.079.0, also l
I'm considering shifting a large existing C++ codebase into D
(it's a scientific code making much use of functions like atan,
log etc).
I've compared the raw speed of atan between C++ (Apple LLVM
version 7.3.0 (clang-703.0.29)) and D (dmd v2.079.0, also ldc2
1.7.0) by doing long loops of such
22 matches
Mail list logo
