Worst Phobos documentation evar!

[Manu via Digitalmars-d]

On 1 January 2015 at 19:47, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 12/31/2014 8:46 PM, Manu via Digitalmars-d wrote:
>>
>> Okay, well it's not really useful without a forceinline attribute.
>> std.simd functions need to be pseudo-intrinsics, ie, the cost of a
>> function call will definitely negate the work they perform.
>> Yes, they will (probably) be inlined in release, but debug performance
>> is also important, and I can't have maths code that runs much slower
>> in debug builds because it makes a function call passing structs by
>> value for every single maths opcode in the hottest loops.
>>
>> There were also troubles with GDC; I haven't been able to make it emit
>> the opcode that I want. It reinterprets to emit something else
>> depending on the SSE level argument passed to the compiler. There are
>> attributes to set the 'target' per-function, but that didn't work for
>> some reason, so I need to work out if that can be resolved, otherwise
>> my whole approach (goal of being able to generate multiple SIMD
>> version code paths for runtime selection) won't work (in GCC)...
>>
>> We need to get a quality low-level API out there, that is portable,
>> and fills gaps in the various architectures, then we can focus on
>> high-level wrappers and niceties.
>
>
> 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.


>> I really want to see your half-float module merged. Where did that go?
>> I recall some people were saying it should be conflated with the
>> custom-float stuff, so half-float was just a specialisation of custom
>> float...
>
>
> 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'm not so sure about that... but maybe? I have been needing a 3.7
>> (10bit) float too, maybe that fits in there?
>
>
> 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?


>> 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 >_<


> 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.


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.

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 ;)