Worst Phobos documentation evar!

[Walter Bright via Digitalmars-d]

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.