[GSoC] Trying to find a good topic

[Mike Franklin]

On Friday, 29 March 2019 at 15:35:10 UTC, Dan Printzell wrote:

> If you want to you (others are also welcomed) can look through
> my draft to make sure I have not written anything stupid and
> possibly suggest improvements.
>
> https://docs.google.com/document/d/15ba1vC1T7n2vX8kvQVikOj1Ip1-mt-zyiEwd0OYBoQA/edit?usp=sharing

I'm a bit rushed at the moment but this is what I have right now:

I wouldn't put too much emphasis on betterC for the following 
reasons.

1.  To make these templated runtime hooks work in betterC you 
will need to make it templates-all-the-way-down.  That can easily 
turn into a huge PR that turns way too much of druntime into 
templates, and that will significantly reduce the chance of the 
PR being accepted.

2.  Many of the current runtime hooks throw `Exception`s.  
`Exception`s are classes, so they can't be used in betterC.  You 
*might* be able to work around that by replacing them with 
`assert`ions, but then again you need to decide if they should be 
`assert`ions for all builds or just betterC.  If just betterC, 
then you'll have to `version(SupportsExceptions)` and provide two 
different implementations.  I tried that and it turned into a 
headache especially when trying to dynamically create meaningful 
error messages.  I recommend saving yourself the trouble for the 
first round; don't worry about betterC until you get the runtime 
hook working with non-betterC builds.  You can revisit it with a 
followup PR to address betterC, after the non-betterC changes get 
accepted.

3.  This work has the potential to make betterC obsolete.  In 
general, the way betterC works, is it imports druntime, but 
doesn't link to it.  Users can already achieve a similar result 
by building and linking separately especially with the work done 
in 2.079.  Once all runtime hooks are replaced with templates, 
druntime becomes more of an "header-only" library for lack of 
better term.  You may be able to achieve a similar result as 
betterC by simply not using certain features of D.  If that day 
arrives, there will no longer be much of a reason for betterC.

There are other benefits beyond betterC.

1.  Lucia Cojocaru was the first to do some of this work; she did 
`__equals` and `__cmp`, I think.  In her presentation about it at 
DConf2017 (https://www.youtube.com/watch?v=endKC3fDxqs), she 
demonstrated a 30% increase in runtime performance.  It seems, at 
least to me, that we should be able to expect similar results by 
refactoring other runtime hooks.

2.  Once converted to templates, we then have the ability to do 
compile-time microoptimizations base on type, size, alignment, 
and potentially other information available through 
design-by-introspection for additional exploitation.

3.  As mentioned before, the compiler is currently bypassing all 
of D's compiler guarantees for `nothrow`, `@safe`, and `pure`.  
This, IMO, is a bug in the compiler.  After converting runtime 
hooks to templates, the compiler will enforce these constraints, 
having the compiler automatically audit the implementation.  That 
may prove to find and fix bugs we aren't currently aware of, just 
as Walter recently found and fixed a stack corruption bug when 
enabling -dip1000 in Phobos.  The result is a verifiably more 
reliable implementation, one in which future bugs can't even be 
introduced because they won't build.

4.  All the information the implementations need is available at 
compile-time.  There is no reason to utilize runtime type 
information `TypeInfo`.  `TypeInfo` is a class, so the current 
implementation has an intrinsic dependency on classes.  Classes 
have an intrinsic dependency on the GC and other features.  
Replacing the runtime hooks with templates that parameterize on 
type, remove that dependency making the runtime more 
pay-as-you-go for implementations, like, but not limited to, 
bare-metal, that don't want or don't have the resources for the 
runtime overhead of classes and the GC.  There still may be other 
classes that the implementation depends on (e.g. `Exception`s) 
but those dependencies could be refactored in followup PRs to 
completely eliminate the dependency on classes. That will bring 
more of D's features to the aforementioned implementations so 
users.  Users will have a betterD rather than a betterC.

Challenges to overcome.

1.  Because `@safe`, `nothrow`, and `pure` will suddenly be 
enforced, the implementation will have to be refactored to abide 
by the compiler's enforcement of those constraints.  Here are a 
few things I've learned.
   a.  You may be able to use `pureMalloc` and friends 
(https://github.com/dlang/druntime/blob/29f495b5b3571484bcf4d0af2fe211d6b7d86830/src/core/memory.d#L862-L891) to overcome the purity constraint.
   b.  You should be able to use `trusted` to workaround the 
`@safe` constraint.
   c.  You may be able to use `assert`ions instead of throwing 
`Exception`s to workaround the `nothrow` constraint.

I have private e-mails from Walter approving, at least 
superficially, these techniques should you need them to gain 
leverage in the review process.  It's not a guarantee, but it 
sounds promising.

2.  One of the things Lucia and myself have not yet done is to 
measure the impact of converting these runtime hooks to templates 
on compile-time and template bloat.  A more thorough and 
professional approach would be to provide data with each PR with 
such measurements.

That's all I have time for at the moment.  I'll make another pass 
later.

Mike