Hi,

I just recorded a draft for a talk about templates and why they are slow.

I'd be interested in questions and improvement suggestions.

I have uploaded it here :
http://www96.zippyshare.com/v/dlNhyACZ/file.html

On Wednesday, 21 September 2016 at 14:32:25 UTC, Stefan Koch wrote:
> Hi,
>
> I just recorded a draft for a talk about templates and why they are slow.
>
> I'd be interested in questions and improvement suggestions.
>
> I have uploaded it here :
> http://www96.zippyshare.com/v/dlNhyACZ/file.html

Interesting talk. Templates are indeed slow but the reason why I use them over CTFE functions (or why i leave out ctfe in general and just use functions) is that they don't require 20 GB of RAM for some medium-simple tasks (liked Pegged)

Templates could be made faster but I don't really like losing a feature or a possibility for it. imo D is very friendly and easy to learn for newcomers, if a feature is slowing down things a lot but making it a bit easier to learn/use, I would prefer to keep that feature.

On Wednesday, 21 September 2016 at 16:11:04 UTC, WebFreak001 wrote:
>
> Interesting talk. Templates are indeed slow but the reason why I use them over CTFE functions (or why i leave out ctfe in general and just use functions) is that they don't require 20 GB of RAM for some medium-simple tasks (liked Pegged)

That can and is being fixed.
Templates can only be fixed partially and I am not even sure of that.

> Templates could be made faster but I don't really like losing a feature or a possibility for it. imo D is very friendly and easy to learn for newcomers, if a feature is slowing down things a lot but making it a bit easier to learn/use, I would prefer to keep that feature.

I am not suggesting to remove templates.
I just want to raise awareness that they have a rather high cost.
CTFE performance is fixable. Template performance might not.

On Wednesday, 21 September 2016 at 17:14:34 UTC, Stefan Koch wrote:
> That can and is being fixed.
> Templates can only be fixed partially and I am not even sure of that.
>
> I am not suggesting to remove templates.
> I just want to raise awareness that they have a rather high cost.
> CTFE performance is fixable. Template performance might not.

Thinking about templates and CTFE, is part of the performance issue due to immutability? Compare std.meta.Reverse vs std.algorithm.reverse:

template Reverse(TList...)
{
    static if (TList.length <= 1)
        alias Reverse = TList;
    else
        alias Reverse = AliasSeq!(Reverse!(TList[$/2..$]), Reverse!(TList[0..$/2]));
}

void reverse(Range)(Range r) if (isRandomAccessRange!Range && hasLength!Range)
{
    immutable last = r.length-1;
    immutable steps = r.length/2;
    for (size_t i = 0; i < steps; i++)
    {
        r.swapAt(i, last-i);
    }
}

If we are able to get a bytecode CTFE interpretor, it seems like the same technology could be used to "run" templates like Reverse which only serves to compute a "value" rather than declare a new function or type, and perhaps be able to write a function like reverse which uses mutation and apply it to an AliasSeq in a typesafe way.

On Wednesday, 21 September 2016 at 18:34:13 UTC, Michael Coulombe wrote:
> On Wednesday, 21 September 2016 at 17:14:34 UTC, Stefan Koch wrote:
>> That can and is being fixed.
>> Templates can only be fixed partially and I am not even sure of that.
>>
>> I am not suggesting to remove templates.
>> I just want to raise awareness that they have a rather high cost.
>> CTFE performance is fixable. Template performance might not.
>
> Thinking about templates and CTFE, is part of the performance issue due to immutability? Compare std.meta.Reverse vs std.algorithm.reverse:
>
> template Reverse(TList...)
> {
>     static if (TList.length <= 1)
>         alias Reverse = TList;
>     else
>         alias Reverse = AliasSeq!(Reverse!(TList[$/2..$]), Reverse!(TList[0..$/2]));
> }
>
> void reverse(Range)(Range r) if (isRandomAccessRange!Range && hasLength!Range)
> {
>     immutable last = r.length-1;
>     immutable steps = r.length/2;
>     for (size_t i = 0; i < steps; i++)
>     {
>         r.swapAt(i, last-i);
>     }
> }
>
> If we are able to get a bytecode CTFE interpretor, it seems like the same technology could be used to "run" templates like Reverse which only serves to compute a "value" rather than declare a new function or type, and perhaps be able to write a function like reverse which uses mutation and apply it to an AliasSeq in a typesafe way.

This would need to have special compiler support.
We would have to introduce another langauge feature that allows manipulating type-lists without going trough templates.
__traits give D insanely powerful introspection abilities by porviding the ability to do a query on types.
However the languages only way to work with types right now goes trough templates.
We would need something like type-functions that do not relay on template mechanisms.

I am not the right person to do language changes, but I am willing to implement a proposal should I hear of one that could solve this.