Optimizing recursive templates
Bruce Carneal
bcarneal at gmail.com
Thu Sep 24 22:54:59 UTC 2020
On Thursday, 24 September 2020 at 20:53:25 UTC, H. S. Teoh wrote:
> On Thu, Sep 24, 2020 at 07:49:44PM +0000, Stefan Koch via
> Digitalmars-d wrote
>> Hi Guys,
>>
>> I am starting this thread to talk about the feasibility of
>> rewriting recursive templates as iterative internal forms.
>>
>> ...
>
> While this is an interesting subject in its own right, I think
> we're kinda missing the point of template optimization here.
> ...
>
> So I think a more practical approach to this problem is study
> common recursive templates (e.g., comb through Phobos and pick
> up the most commonly-used recursive templates) and identify the
> most common patterns among them that can be replaced with more
> efficient versions. It won't be possible to cover *all* cases
> of recursive templates, but if we can hit the most common
> cases, we can still get a lot of mileage out of it.
>
>
> T
I think the practical approach is to bring type functions online.
This would let us replace our, often disappointed, hopes that
the next set of hacks will finally "fix" templates with actual
trials of an extant system (type functions).
Want to use recursive type functions? Have at it! Want to
iterate? Congratulations! You've single-handidly crushed the
performance of the super-duper template recursion hueristic
optimizer that'll happen any day now!
Kidding aside, while I believe we'll see performance and compiler
convergence benefits from type functions, the bigger benefit
should be a reduction in complexity for a big chunk of our future
meta programming.
Templates are very powerful, a huge improvement over their C++
predecessors. They are are also wildly unconstrained. Their
successful use depends on programmer discipline, on best
practices, on convention. Absent strong, manually applied
constraints, non-trivial templates can lead to problems that are
very difficult to localize, let alone fix.
So, performance? Love it. Simplicity? Love it more, especially
when it yields better performance.
More information about the Digitalmars-d
mailing list