std.math performance (SSE vs. real)

[Iain Buclaw via Digitalmars-d]

On 29 Jun 2014 05:48, "H. S. Teoh via Digitalmars-d" <
digitalmars-d at puremagic.com> wrote:
>
> On Sat, Jun 28, 2014 at 08:41:24PM -0700, Andrei Alexandrescu via
Digitalmars-d wrote:
> > On 6/28/14, 6:02 PM, Tofu Ninja wrote:
> [...]
> > >I think this thread needs to refocus on the main point, getting
> > >math overloads for float and double and how to mitigate any
> > >problems that might arise from that.
> >
> > Yes please. -- Andrei
>
> Let's see the PR!
>

I've already raised one (already linked in this thread).

More to come!

> And while we're on the topic, what about working on making std.math
> CTFE-able? So far, CTFE simply doesn't support fundamental
> floating-point operations like isInfinity, isNaN, signbit, to name a
> few, because CTFE does not allow accessing the bit representation of
> floating-point values.

As it stands, as soon as the above mentioned PR for Phobos is merged, isNaN
and isInfinite on float and double types will be CTFE-able. However that
depends on whether or not float->int painting will be replaced with a union.

> This is a big disappointment for me -- it defeats
> the power of CTFE by making it unusable if you want to use it to
> generate pre-calculated tables of values.
>
> Perhaps we can introduce some intrinsics for implementing these
> functions so that they work both in CTFE and at runtime?
>
>         https://issues.dlang.org/show_bug.cgi?id=3749
>

CTFE support for accessing basic types in unions - as in painting between
all kinds of scalar types, with special support for static arrays (via
vectors) should be all that is required.

Once CTFE supports that, it won't be difficult to get std.math to be
CTFE-certified. :)

> Thanks to Iain's hard work on std.math, now we have software
> implementations for all(?) the basic math functions, so in theory they
> should be CTFE-able -- except that some functions require access to the
> floating-point bit representation, which CTFE doesn't support. All it
> takes is to these primitives, and std.math will be completely CTFE-able
> -- a big step forward IMHO.
>

The original goal was making std.math non-asm implementations *genuinely*
pure/nothrow/@safe for GDC x86, and for other ports like ARM, SPARC so LDC
benefits also.

Andrei was the one who sold me on the idea if making them CTFE-able.
However,  I stopped just short of that goal because of this missing feature
of DMD - though I did implement it in GDC as proof of concept that it is
possible (code not actually published anywhere)

There should be a bug report somewhere that I outlined the exact steps in.

Regards
Iain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140629/68219bc2/attachment.html>