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

[Stefanos Baziotis]

I'm moving forward with the D implementations of the C parts that 
the D Runtime
uses. A not-so-small description of the project. I hope it will
be descriptive enough to clear things up for people, as I 
probably did
not do a good job in the previous public discussions about this 
project.

     The goal of this project is to remove the dependency of the D 
Runtime
     from the C Standard Library. Currently, the D Runtime uses a 
small part
     of the C Standard Library. That is:
         a) The string.h family of functions: memcpy(), memmove(), 
etc.
         b) The standard allocator functions: malloc(), free(), 
etc.

     Those don't justify the dependency on the C Standard Library, 
as a very
     small part of it is utilized. However, there are problems 
coming with it:
         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.

     So, this project will provide alternative implementations of 
this functions,
     dependent only in the D Runtime. We hope that in the process, 
we will
     leverage D features that C doesn't have:
         1) Type-safety and memory safety (bounds-checking etc.)
         2) Templates to branch to an optimal implementation at 
compile-time.
         3) Inlining, as the branching in C happens at runtime.
         4) Compile-Time Function Execution (CTFE) and 
introspection (type info).

     Important clarifications:
         1) It will not use the C Standard Library.
         2) C Standard Library will be still available.
         3) We target the D Runtime and not the user (although, of 
course the
         users will be able to use it).
         4) We will provide a different interface from the C 
implementations,
         with the prospect to be more idiomatic D.
         5) Same or better performance with libc is not a hard 
constraint. We
         might succeed to reach it, but we might not. The hard 
constraint is that
         it will at least be close.

This month
==========

Implementation of string.h family:
     -- Week 1-2: Handling mis-alignment in memcpy().
     -- Week 3: memmove()
     -- Week 4: memset()

As a starting point, I reached the same performance with libc 
memcpy for (big) aligned data (hopefully, the implementation will 
be part of the memcpyD in some time).
Now, along with Mike Franklin's previous work, memcpyD() is 
faster than libc memcpy for small data (less than 32768) and as 
fast for big data.

Next month
==========
Mike Franklin initially proposed the idea that it we may be able 
to do
something better than implementing malloc() and free() again, 
just in D.
So, we decided that the best option is to integrate the 
std.experimental.allocator
to D Runtime. That involves creating an allocator of its building 
blocks
and removing the dependency in Phobos.

Week 1: Create a basic allocator using std.experimental.allocator 
interface
Week 2: Replace malloc(), free(), realloc() in D runtime
Week 3: Re-iterate until we have good benchmarks.
Week 4: Remove Phobos dependencies from the allocator.

Blockers
========
Not any major one.