Hi,

As you may know I am currently optimizing template-related code inside of DMD.
Inside DMD code quality is quite high, there is little low hanging fruit.

However there is one thing that suspiciously often shows up the on profilers display.
Those are indirect class which have a high number of L2(!) i-cache misses.

These calls don't do a lot of work. They are needed either for downcasts or to verify the dynamic type of an AST-Node.
Even without the i-cache related stalls the call overhead alone is something to think about.

For template-heavy code matching template parameters is one of the most frequently operations.
Since Template Parameters can be types expressions or symbols the dynamic-types are heavily queried.

First experiments suggest that a speedup of around 12% is possible if the types where accessible directly.

Since dmd uses visitors for many things now the benefit of virtual methods is highly reduced.

Please share your thoughts.

Cheers,
Stefan

On 2016-09-11 23:48, Stefan Koch wrote:
> Hi,
>
> As you may know I am currently optimizing template-related code inside
> of DMD.
> Inside DMD code quality is quite high, there is little low hanging fruit.
>
> However there is one thing that suspiciously often shows up the on
> profilers display.
> Those are indirect class which have a high number of L2(!) i-cache misses.
>
> These calls don't do a lot of work. They are needed either for downcasts
> or to verify the dynamic type of an AST-Node.
> Even without the i-cache related stalls the call overhead alone is
> something to think about.
>
> For template-heavy code matching template parameters is one of the most
> frequently operations.
> Since Template Parameters can be types expressions or symbols the
> dynamic-types are heavily queried.
>
> First experiments suggest that a speedup of around 12% is possible if
> the types where accessible directly.
>
> Since dmd uses visitors for many things now the benefit of virtual
> methods is highly reduced.
>
> Please share your thoughts.

What about using an enum in the base class that indicates the runtime type? The Expression class is already using this technique. Add it to Declaration and Statement as well, or even to RootObject.

-- 
/Jacob Carlborg

On Sunday, 11 September 2016 at 21:48:56 UTC, Stefan Koch wrote:
> Those are indirect class
I meant indirect calls!

@Jacob

Yes that is my indented solution.
Having a type-field in root-object.

On Monday, 12 September 2016 at 08:03:45 UTC, Stefan Koch wrote:
> On Sunday, 11 September 2016 at 21:48:56 UTC, Stefan Koch wrote:
>> Those are indirect class
> I meant indirect calls!
>
> @Jacob
>
> Yes that is my indented solution.
> Having a type-field in root-object.

A Small update on this.
When dmd is complied with ldc this problem seems to lessen.

However much of dmd's code especially in dtemplate could be simpified if it could just switch on a value. instead of doing method calls and null checks.

On 2016-09-13 23:01, Stefan Koch wrote:

> However much of dmd's code especially in dtemplate could be simpified if
> it could just switch on a value. instead of doing method calls and null
> checks.

At least to me, it would be very useful for debugging purpose as well.

-- 
/Jacob Carlborg

On Tuesday, 13 September 2016 at 21:01:34 UTC, Stefan Koch wrote:
> On Monday, 12 September 2016 at 08:03:45 UTC, Stefan Koch wrote:
>> On Sunday, 11 September 2016 at 21:48:56 UTC, Stefan Koch wrote:
>>> Those are indirect class
>> I meant indirect calls!
>>
>> @Jacob
>>
>> Yes that is my indented solution.
>> Having a type-field in root-object.
>
> A Small update on this.
> When dmd is complied with ldc this problem seems to lessen.

Try PGO with LDC 1.1.0-beta.
https://johanengelen.github.io/ldc/2016/04/13/PGO-in-LDC-virtual-calls.html