How can we make it easier to experiment with the compiler?
Bruce Carneal
bcarneal at gmail.com
Mon May 24 20:02:39 UTC 2021
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.
More information about the Digitalmars-d
mailing list