I dun a DIP, possibly the best DIP ever

[Manu]

On Wed, Apr 22, 2020 at 11:20 PM Steven Schveighoffer via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On 4/22/20 8:04 AM, Manu wrote:
> > We have a compile time problem, and this is basically the cure.
> > Intuitively, people imagine CTFE is expensive (and it kinda is), but
> > really, the reason our compile times are bad is template instantiation.
> >
> > This DIP single-handedly fixes compile-time issues in programs I've
> > written by reducing template instantiations by near-100%, in particular,
> > the expensive ones; recursive instantiations, usually implementing some
> > form of static map.
> >
> > https://github.com/dlang/DIPs/pull/188
> >
> > This is an RFC on a draft, but I'd like to submit it with a reference
> > implementation soon.
> >
> > Stefan Koch has helped me with a reference implementation, which has so
> > far gone surprisingly smoothly, and has shown 50x improvement in compile
> > times in some artificial tests.
>
> Yes please! Where is the reference implementation? I want to try some
> things out.
>

The link is in the DIP.
Most tests we've done are working, except template instantiation expansion
is not yet implemented: ie, Thing!(Tuple, x, y)...
That's got a lot of implementation baggage attached to it in DMD.

> I expect much greater improvements in situations where recursive
> > template expansion reaches a practical threshold due to quadratic
> > resource consumption used by recursive expansions (junk template
> > instantiations, and explosive symbol name lengths).
> > This should also drastically reduce compiler memory consumption in
> > meta-programming heavy applications..
>
> We have a project that I had to completely refactor because the memory
> consumption was so great during compile time, that I ran out of memory
> on a 12GB virtual machine on my 16GB macbook. The refactoring made a
> difference, but now it's back up and I needed to buy a new system with
> 32GB of RAM just to build. I understand Weka had similar issues, I
> wonder if anyone on that team can elaborate whether this might help fix
> those problems.
>
> But I want to see if it actually would fix the problems. It's still a
> good change, but I'm not sure it will be the solution to all these.
>

I expect you won't be able to run practical tests on real code yet without
TemplateInstance expansion.
The problem is that existing code is factored exclusively into
template instantiations, so a trivial experiment will apply to existing
code in that form.

> In addition to that, it's simple, terse, and reduces program logic
> > indirection via 'utility' template definitions, which I find improves
> > readability substantially.
>
> There were some posts on "how do I do this in D" that used C++ parameter
> pack expansion that just weren't possible or horrible to implement in D.
>

Yup. Now they're possible and awesome!

I wonder if your DIP can solve them? I think it can.
>
> e.g.: https://forum.dlang.org/post/ymlqbjblbjxoitoctevl@forum.dlang.org


Yes, it's basically written specifically to solve that problem! :)

I think can be solved just like C++:
>
> int double_int(int val) { return 2 * val; }
>
> T double_int(T val) { return val; }
>
> void double_ints(alias pred, T... args) {
>     pred(double_int(args)...);
> }
>
> That's awesome.
>

Yes, something like that.

In my dconf talk last year, I talked about how D's metaprogramming was
> its crown jewel, and we should prioritize anything that makes this more
> usable/possible. This is the kind of stuff I was talking about. Well done!
>

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20200422/df1e5bee/attachment.htm>