<div dir="ltr"><div dir="ltr">On Wed, Apr 22, 2020 at 11:20 PM Steven Schveighoffer via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 4/22/20 8:04 AM, Manu wrote:<br>
> We have a compile time problem, and this is basically the cure.<br>
> Intuitively, people imagine CTFE is expensive (and it kinda is), but <br>
> really, the reason our compile times are bad is template instantiation.<br>
> <br>
> This DIP single-handedly fixes compile-time issues in programs I've <br>
> written by reducing template instantiations by near-100%, in particular, <br>
> the expensive ones; recursive instantiations, usually implementing some <br>
> form of static map.<br>
> <br>
> <a href="https://github.com/dlang/DIPs/pull/188" rel="noreferrer" target="_blank">https://github.com/dlang/DIPs/pull/188</a><br>
> <br>
> This is an RFC on a draft, but I'd like to submit it with a reference <br>
> implementation soon.<br>
> <br>
> Stefan Koch has helped me with a reference implementation, which has so <br>
> far gone surprisingly smoothly, and has shown 50x improvement in compile <br>
> times in some artificial tests.<br>
<br>
Yes please! Where is the reference implementation? I want to try some <br>
things out.<br></blockquote><div><br></div><div>The link is in the DIP.</div><div>Most tests we've done are working, except template instantiation expansion is not yet implemented: ie, Thing!(Tuple, x, y)...</div><div>That's got a lot of implementation baggage attached to it in DMD.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I expect much greater improvements in situations where recursive <br>
> template expansion reaches a practical threshold due to quadratic <br>
> resource consumption used by recursive expansions (junk template <br>
> instantiations, and explosive symbol name lengths).<br>
> This should also drastically reduce compiler memory consumption in <br>
> meta-programming heavy applications..<br>
<br>
We have a project that I had to completely refactor because the memory <br>
consumption was so great during compile time, that I ran out of memory <br>
on a 12GB virtual machine on my 16GB macbook. The refactoring made a <br>
difference, but now it's back up and I needed to buy a new system with <br>
32GB of RAM just to build. I understand Weka had similar issues, I <br>
wonder if anyone on that team can elaborate whether this might help fix <br>
those problems.<br>
<br>
But I want to see if it actually would fix the problems. It's still a <br>
good change, but I'm not sure it will be the solution to all these.<br></blockquote><div><br></div><div>I expect you won't be able to run practical tests on real code yet without TemplateInstance expansion.</div><div>The problem is that existing code is factored exclusively into template instantiations, so a trivial experiment will apply to existing code in that form.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> In addition to that, it's simple, terse, and reduces program logic <br>
> indirection via 'utility' template definitions, which I find improves <br>
> readability substantially.<br>
<br>
There were some posts on "how do I do this in D" that used C++ parameter <br>
pack expansion that just weren't possible or horrible to implement in D.<br></blockquote><div><br></div><div>Yup. Now they're possible and awesome!</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I wonder if your DIP can solve them? I think it can.<br>
<br>
e.g.: <a href="https://forum.dlang.org/post/ymlqbjblbjxoitoctevl@forum.dlang.org" rel="noreferrer" target="_blank">https://forum.dlang.org/post/ymlqbjblbjxoitoctevl@forum.dlang.org</a></blockquote><div><br></div><div>Yes, it's basically written specifically to solve that problem! :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I think can be solved just like C++:<br>
<br>
int double_int(int val) { return 2 * val; }<br>
<br>
T double_int(T val) { return val; }<br>
<br>
void double_ints(alias pred, T... args) {<br>
    pred(double_int(args)...);<br>
}<br>
<br>
That's awesome.<br></blockquote><div><br></div><div>Yes, something like that.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In my dconf talk last year, I talked about how D's metaprogramming was <br>
its crown jewel, and we should prioritize anything that makes this more <br>
usable/possible. This is the kind of stuff I was talking about. Well done!<br></blockquote><div><br></div><div>Thanks!</div></div></div>