Worst Phobos documentation evar!

[Walter Bright via Digitalmars-d]

On 1/2/2015 2:05 AM, Manu via Digitalmars-d wrote:
>> I don't believe in the utility of a customizable float implementation. There
>> is one, but it is pretty much useless. For example, halffloat cannot be
>> implemented using it.
>
> Why?

The same reason I don't see a point to a 17 bit integer type.

> This:
>    @uda(Arg) void function(Arg)()
>    {
>    }
>
> I need to be able to supply a template arg to a UDA. The runtime cpuid
> branching tech depends on it, and thus the whole API design depends on
> it.
>
> So, yeah they're all coming back to me now slowly :)
> There were a number of things I was blocked on. If I can't prove that
> my API approach works, then it needs to completely change.
> These things were blocking me from proving the design actually works.
>
> Can this one be addressed?

template function(Arg)
{
     @uda(Arg) void function() { ... }
}


> Well, it kinda does. Swapping register types is one of the biggest
> performance hazards there is.
> Use of SIMD opcodes will generate use of xmm regs. As much as I preach
> best practise is to commit 100% to SIMD, people will inevitably find
> themselves moving float data into SIMD regs. x64 should actually be
> the most tolerant of that sort of code, because float data *should*
> already be in xmm regs, but I think in our case we're going to see
> some pretty ordinary simd benchmarks whenever floats appear. The
> register swapping will very probably result in code that is slower
> than just issuing sequential float ops.

The best thing to do is make the library work, and then we go about making it 
faster.

The thing is,


M: Implement feature X and then I can deliver fantastic library A 2 years later.
W: Ok, but I've got to first implement Y because it's blocking delivery of 
fantastic library B today.


M: Implement feature X and then I can deliver fantastic library A tomorrow!
W: Ok, it's at the top of the queue!