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!