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

[Andrei Alexandrescu]

On 6/3/19 10:17 AM, Stefanos Baziotis wrote:
> On Saturday, 1 June 2019 at 14:29:03 UTC, Stefanos Baziotis wrote:
>> I'll post an update about where my experimentation will be visible.
> 
> https://github.com/baziotis/Dmemcpy
> 
> You can follow this repo for memcpy. In the future, probably
> I will merge all the string.h functions in one repo, but in the development
> stage I think it's better to have them on their own.
> 
> Any feedback is greatly appreciated!

At 512 lines including tests, it seems on the involved side. The 
benchmarks ought to show a hefty improvement to match. Are there 
benchmark results available?

Quoting the rationale from the motivation in another thread:

1) C’s implementations are not type-safe and memory-safe.
2) C’s implementations have accumulated a lot of cruft over the years.
3) Cross-compiling is more difficult as now one should have available 
and configured a C runtime and toolchain apart from the D runtime. This 
makes it difficult for D to create freestanding software.

And then the listed advantages of using D for implementation (renumbered):

4) Type-safety and memory safety (bounds-checking etc.)
5) Templates to branch to an optimal implementation at compile-time.
6) Inlining, as the branching in C happens at runtime.
7) Compile-Time Function Execution (CTFE) and introspection (type info).

My view on formulating motivation is simple: do it like a scientist. 
Argue the facts. If facts are not available, argue fundaments and 
universal principles. If such are not available, the motivation is too weak.

(1) checks the "facts" box but has the obvious comeback "then how about 
a 2-line trusted wrapper over memcpy?" that needs to be explained. 
Related, obviously people who reach for memcpy() are often not looking 
for a safe primitive. a[] = b[] is safe, syntactically simple, and could 
lower to anything including memcpy.

(2) is quite specious and really needs some evidence. Is cruft in memcpy 
really an issue? I looked memcpy() implementations a while ago but 
didn't save bookmarks. Did a google search just now and found 
https://github.com/gcc-mirror/gcc/blob/master/libgcc/memcpy.c, which is 
very far from cruft-ridden. I do remember elaborate implementations of 
memcpy but so are (somewhat ironically) the 512 lines of the proposed 
implementation. I found one here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/lib/memcpy_64.S?id=HEAD

No idea of its level of cruftiness, where it's used etc. The right way 
to argue (2) is to provide links to implementations that people can look 
at and decide without doubt, "yep, crufty".

(3) is... odd. Doesn't every machine ever come with a C implementation 
including a ready-to-link standard library? If not, isn't that a rarity? 
Again, that should be argued preemptively by the motivation section.

(4) brings again the wrapper argument
(5) is nice if and only if confirmed by benchmarks
(6) is also nice under the same conditions as (5)
(7) again... what's wrong with a wrapper that does if (__ctfe)

These considerations are built with memcpy() in mind. With malloc() 
we're looking at a completely different ballgame. Implementing malloc() 
from scratch is a very serious project that needs almost overwhelming 
motivation. The goal of std.experimental.allocator was to offer a 
flexible framework for implementing general and specialized allocators, 
but simply replacing malloc() is more difficult to argue. Also, 
achieving comparable performance will be difficult.