[GSoC] 'Independency of D from the C Standard Library' progress and update thread

[Stefanos Baziotis]

On Friday, 5 July 2019 at 20:22:30 UTC, Piotrek wrote:
>
> Hi Stefanos,
>
> This is great work. I hope Phobos will move away from clib some 
> day.
>

Hello, thank you! Yes, I hope too. If the D runtime moves away, 
that
will be easier for the rest of D.

> As for the benchmarks.
> I think you can post your results somewhere. Or you did. 
> Unfortunately I cannot find them.

You're right, my mistake, there are no recent benchmarks. I'll 
try to post
today. They're similar to yours.

> I tested Dmemset with dmd (lcd and gdc didn't compile) on 
> i3-3220 at 3.30GHz (Ubuntu).

That's weird. Could you give some more info on how did you 
compile?
Did you use the procedure described in the README?
Meaning, `rdmd run benchmarks gdc` and `rdmd run benchmarks ldc`.
Now I checked and there was a regression which is now fixed. But 
with this
regression, I could compile benchmarks for gdc but not ldc or dmd.

> The strange thing is I get different results when I change the 
> following line in benchamrks.d
> So D version becomes better. Maybe this is related to different 
> binary file after compilation.

That is indeed strange but not too unexpected. A compiler (more 
possible in
the DMD back-end) might decide to do strange things for reasons I 
don't know.
I'll try to re-create similar behavior in mine.

>
> Some other results for "(1..257)" variant:
>
> Are they meaningful for you?
>

They are, thank you! The benchmarks are good.

Just some more info for anyone interested:
Regarding sizes 1-16. With GDC / LDC, in my benchmarks
(and by reading the ASM, I assume in all the benchmarks), it 
reaches parity
with libc (note that for sizes 1-16 the naive version is used,
meaning, a simple for loop). Now, for such small sizes, the 
standard way to go
is a fall-through switch (I can give more info on that if someone 
is interested).
The problem with that is that it's difficult to be optimized 
along with the rest
of the code. Meaning, by the compiler. Or at least, I didn't find 
a way
to do it. And so, I use the naive version which is only slightly 
slower but
doesn't affect bigger sizes.

Another important thing is that +/- 1 GB/s should not be 
considered. The reason
is that at some point I benchmarked libc memset() against libc 
memset() and
there were +/- 1 GB/s differences.

> If you want I can run additional benchmarks for you.

Thanks, I don't want to pressure you. If you have time, I'm 
interested in
some feedback on GDC / LDC (if they compile and / or benchmarks).
My guess is that especially with GDC / LDC (and DMD, but I'm not 
yet sure
for DMD across different hardware), Dmemset can actually replace 
libc memset().

In Dmemmove / Dmemcpy is harder to have a clear winner.

> For details, mabe we can continue on github. On forum we can 
> discuss some fundamentals points.

I'm available to you or anyone to give additional info / 
explanations etc.
on every line of code, decision, alternative implementations, 
possible
improvements etc. You can post here, contact me on Slack or email.
Some of these things will be added on the READMEs in the end, but 
we can
go in more detail.

Best regards,
Stefanos