std.math performance (SSE vs. real)

[H. S. Teoh via Digitalmars-d]

On Sun, Jun 29, 2014 at 11:33:20PM +0100, Iain Buclaw via Digitalmars-d wrote:
> On 29 June 2014 23:20, H. S. Teoh via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
> > On Sun, Jun 29, 2014 at 08:54:49AM +0100, Iain Buclaw via Digitalmars-d wrote:
> >> 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).
> >
> > Are you talking about #2274? Interesting that your implementation is
> > basically identical to my own idea for fixing std.math -- using
> > unions instead of pointer casting.
> >
> 
> Not really.  The biggest speed up was from adding float+double
> overloads for floor, ceil, isNaN and isInfinity.  Firstly, the use of
> a union itself didn't make much of a dent in the speed up.  Removing
> the slow array copy operation did though.  Secondly, unions are
> required for this particular function (floor) because we need to set
> bits through type-punning, it just wouldn't work casting to a pointer.
[...]

I wasn't referring to the speedup (though that is certainly nice), I was
talking about making things CTFE-able.

What's the status of repainting unions in CTFE? Is there a PR for that
yet, or do we need to implement one?


T

-- 
People tell me that I'm skeptical, but I don't believe it.