On 1/1/2015 6:43 AM, Manu via Digitalmars-d wrote:
Make it work in dmd (with my help, of course) and prove the design. Then GDC
will come along.
I can't do anything that isn't supported by the GCC backend; that's
the platform for almost all the cross-compilers, which I really care
about.
I also have a suspicion that anybody who uses SIMD seriously will
probably be building with LDC or GCC because of improved codegen
across the board.
Have to start somewhere.
Half-float is here:
http://digitalmars.com/sargon/halffloat.html
in the Sargon component library :-)
That's probably not the best place for it ;)
What was the controversy blocking it? I don't remember.
I think the root issue was nobody thought it was useful other than you and I.
There is a reasonable issue about "should this really be in the Standard
Library, or an add-on?"
I created Sargon as a place to put things I think would be generally useful, but
have been unable to convince others of.
It would be trivial to use halffloat as a model for building other custom
floating point types.
Isn't there a competing custom float implementation though?
Should they be unified?
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.
That stuff all needs forceinline too to be particularly useful.
I agree, but that does NOT block you from designing and writing the code. It
only blocks the final polish.
I wrote the code years ago. I was at the point of polish where it got
stuck on those issues... and unittest's, and documentation >_<
The last 10% of the work is always 90% of the work. Get it done!
It also may be worthwhile to look through std.algorithm and see what can be
specialized to use simd, such as string searching.
SSE provides some special opcodes for string processing that aren't
really portable, so I don't expect those would be expressed in
std.simd, but they could be used opportunistically in other places.
The main trouble is that they are SSE4.2, which is still sufficiently
new that we can't rely on it's presence on end-user machines. How will
we tell the compiler it is okay to use those opcodes?
GCC/LDC have args to say what SSE level to build for. We need a way to
query the requested SSE level in the code, and we also need that
concept added to DMD.
std.algorithm is portable for the user. It is very accommodating for
specializations, so most definitely it can be specialized for x86 with SIMD.
Some platforms, such as OSX, have a reliable minimum standard. This is why we,
for example, have abandoned 32 bit OSX. For others, a runtime switch based on
CPUID is fine.
So, where it sits is: DMD needs a commandline arg to request an SSE
target level and made available to the code, I need to work out what
to do about GDC, and I need to write the unittest's and docs... which
is probably the biggest block tbh ;)
Otherwise, it still rests in my fork where I left it. Some people have
used it. When it's done I'll extend it to support matrices, and
perhaps some higher-level linear algebra stuff.
The thing is, if you don't do the unittests and docs, you will be throwing away
all the other work you've done. If you do them, there will be a large incentive
to get forceinline working.
Oh yeah, and a massive one that I've discussed with Ethan and I think
he's discussed with you; DMD likes to use the x87 in win64 builds...
that's really no good. We can't be swapping between x87 and xmm regs.
float/double args are passed in xmm according to the ABI, and then
everywhere a float operation is performed, a swap from xmm -> x87 is
emitted, and then back again. It's madness. You're gonna have to let
the x87 go on x64 ;)
That shouldn't affect vector code.
