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

[Mike Franklin]

On Monday, 3 June 2019 at 22:45:28 UTC, Andrei Alexandrescu wrote:

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

Stefanos, everything Andrei has said here is correct, but it is 
missing some perspective and does not consider everything we've 
discussed.  Please STAY THE COURSE!  Do not let this post 
discourage you.  The time for questioning the merits of this 
proposal was 2 months ago; not now.  Now that it is a 
full-fledged GSoC project you are tasked to do the best you can.

Andrei, I agree with everything you've said, but there's more to 
take into consideration.  I have a response to some of the items 
you've mentioned, and maybe I'll post that later.

For now allow me to express that I'm quite disappointed that you 
are questioning the merit of this proposal when the time to do so 
was 2 months ago when the GSoC projects were being reviewed, and 
you were supposed to participate.  The GSoC project is well 
underway and Stefanos now needs to see the project through to 
completion regardless of what anyone thinks about it.  Please 
don't undermine this project or diminish the morale of our 
students with such posts.

At the moment we need feedback on the actual memcpy 
implementation, not whether you think this project is a good idea 
or not.

Stefanos, please don't let this post discourage you.  Please STAY 
ON TASK.

Mike