How can we make it easier to experiment with the compiler?

[Bruce Carneal]

On Monday, 24 May 2021 at 10:47:16 UTC, Johan Engelen wrote:
>
[...]
> My standpoint on the original topic of "make it easier to 
> experiment with the compiler": I disagree with making the code 
> more stable. If anything, we should be refactoring much more 
> aggressively, changing function names etc.

Yes. It's easier to understand shallow trees with modest leaves 
than arbitrary graphs with 1000+ LOC "leaves".  Getting there 
will take some work.  Fortunately, it looks like much of that 
work can be done "bottom up" i.e. incrementally.

When simplifying code readability is a commonly applied metric. 
How long does it take for an intelligent but "outside" developer 
to understand the code?  Another useful metric is the degree of 
dynamic dependence: could this code run in parallel?  If not, why 
not?

Examining the ability to run in parallel can also be done "bottom 
up", and is at least as valuable for simplification/correctness 
as it is for parallel speedup potential.  That said, a 
taskification that followed our, sometimes extreme, code 
expansion contours could yield speedups that coarser approaches 
to multi-threading do not.  It could also bring vibe style sanity 
in place of manually managed asynchrony where the dependencies 
are carried in your head.

When looking to foster task independence, building around 
dependency graphs which are immutable/committed in the interior 
and expanding/mutating/synchronizing at the frontier, is one way 
to go. (__traits compiles is interesting in this context...)  The 
SDC people will have other ideas/experience to share if 
taskification becomes a thing.

Finally, my thanks again to the current front end crew and the 
LDC/dcompute crew.  The tool chain may not be perfect but, boy, 
it's way better than falling back to C++/CUDA.