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!
