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

[Stefanos Baziotis]

On Friday, 31 May 2019 at 21:01:01 UTC, Stefanos Baziotis wrote:
> The goal of this project is to remove the dependency of the D 
> Runtime from the C Standard Library.

An update regarding the project. There was a lot of turbulance in 
this project, so I'm sorry I did not post earlier.

Previous month
==============

In this month the goals were replacements for memcpy(), memmove() 
and memset(), named
Dmemcpy, Dmemmove and Dmemset. Dmemcpy and Dmemmove is merged in 
one repo [1]
and the Dmemset is this [2]

The goal was to create fast versions of those, targetted to 
x86_64 and DMD.
Because of that and because of Blockers (refer to that later), 
there is some inline ASM in those implementations.
There was an effort for this to be minimized (currently it's only 
on Dmemcpy),
because I got informed that pure D should be the first priority.

In the last week there was an effort to create a test suite and a 
benchmark suite
for these repos. Quoting Mike and Johannes:

# Make sure the implementation works for all kinds of D types 
(basic types, structs, classes, static arrays, and dynamic arrays)
   * Add naive implementations for now to fill the gaps.

// NOTE(stefanos): Meaning, when x86 is not available or in any 
case that my code is not
// able to be compiled for the target, there should a minimial 
pure D fall-back implementation.
// NOTE(stefanos): Classes are not tested, more on that on the 
Blockers.

# Separate benchmarks from tests
Anyone visiting the repository should be able to clone it and do 
something like `run tests` and `run benchmarks`.
   2.  Create a `run.d` file, a `tests.d` file and a 
`benchmarks.d` file
   3.  When the user executes `rdmd run.d tests` it should compile 
the `tests.d` file and execute it producing a test report.
   4.  When the user executes `rdmd run.d benchmarks` it should 
compile `benchmarks.d`, execute it producing a benchmark report.

// NOTE(stefanos): I'm relatively satisfied with Dmemset. 
Dmemmove got better the last 3
// days but it probably still needs review / more work.

#  Use the `tests.d` file to implement a thorough test suite for 
each repository including edge cases.
   * It should test each kind of type (basic types, structs, 
classes, static arrays, and dynamic arrays). // NOTE(stefanos): 
Again, for the classes refer to the Blockers.
   * Where relevant it should include a test of all interesting 
sizes.
   * Where relevant, it should test all variations of alignment up 
to 32.  This includes aligned-src & aligned-dst, unaligned-src & 
unaligned-dst, aligned-src & unaligned-dst, and unaligned-src and 
aligned-dst.  A nested foreach look (e.g.  `foreach (srcOffset, 
alignments) { foreach(dstOffset; alignments) { ... } }`) should 
cover it.

// NOTE(stefanos): This is not done as proposed here. I had my 
own variation
// for alignment testing and this alternative was to be 
considered. My own, and this,
// still need review.

   * For memmove it should test all variations of overlap:  no 
overlap, exact overlap, source leading destination, destination 
leading source, etc...
   * Make sure each repository passes the test suite
   * Make sure the tests are easily comprehendible.  Keep them 
simple so any visitor to the repository can easily verify that 
the test suite is thorough.
   * Be sure the tests cover all implementations.

#  Use the `benchmarks.d` file to create a benchmark suite for 
each repository
   * Benchmark all sizes from at least 0~512 (preferably up to 
1024).  After 1024 exponentially increasing sizes up to at least 
65536.  They do not need to be powers of 2; consider even powers 
of 10 so it is easy to graph on a logarithmic scale.  An average 
of alignments is good for an overview, but the user should also 
be able to pick a single size and see how it performs for all 
variations of alignments.

// NOTE(stefanos): I don't test that many sizes in experimental 
branch since the compile
// time explodes. Meaning to the point that freezes Visual Studio.
// But I should have added a logarithmic scale, that was an 
overlook.

   * Be sure the benchmark is thorough enough to covers all 
implementations.



There is of course a lot to be said about the actual 
implementations and the decisions
taken but I guess the post would be very big, so I decided to 
focus on the final goals
and on the blockers. Please feel free to ask more specific 
questions on the implementations.




[1] https://github.com/baziotis/Dmemmove/tree/experimental - 
experimental branch
[2] https://github.com/baziotis/Dmemset