[TruffleDSL] Splitting and Cost of Generic Nodes

[Christian Humer]

Hi Stefan,

Unfortunately splitting has still some major issues (as you recognized).
The current version splits way too much (independent of polymorphism) and
can also have some exponential code duplication problems under bad
conditions. However it should stabilize at some point (may be late). But
this should only be a problem on bigger benchmarks not on micro-benchmarks.
So maybe there is another issue here. Can you point me to such a micro?

I am working on a fix for splitting for a longer time already, but was not
able to finish it for the previous release. I hope that I am able to finish
it for the next Truffle release.

The only workaround at the moment that I can suggest is to disable the
splitting heuristic (-G:-TruffleSplittingEnabled) and to do crucial splits
manually for the moment using the call node API.

@Generic is the wrong name for this annotation. In the next iteration of
the DSL this annotation is going to be renamed to @Fallback. There are not
much use-cases for @Generic besides erronous and unexpected cases because
its representation is inherently slow. The reason for this is that it
always uses the generic case to represent your operation. This means that
not just the handler in the method annotated with @Generic  but also all
specializations are used to represent your operation. You can see the full
behaviour in the generated executeGeneric0 method. This is also why this
node is associated with megamorphic costs. The next iteration is going to
make @Fallback handler faster, but still not fast enough to use it for
important cases.

So the solution I recommend is to use @Specialization instead of @Generic.
Let me know if I can be of specific help with that.


- Christian Humer


On Fri, May 30, 2014 at 9:51 PM, Stefan Marr <java at stefan-marr.de> wrote:

> Hi:
>
> I am debugging splitting issues in TruffleSOM and found two things, I
> would like to ask for comments on.
>
> The first thing is one of the splitting conditions:
>
> OptimizedDirectCallNode.java:191
>   // max one child call and callCount > 2 and kind of small number of nodes
>   if (isMaxSingleCall()) { return true; }
>
> In which cases would it be useful to split such methods?
> For TruffleSOM, this condition causes plenty of issues with
> microbenchmarks, because it leads to unconditional splitting and the
> resulting trees do not stabilize.
> I have the feeling this should be restricted to methods that contain at
> least polymorphic nodes and that seems to be covered by the condition
> afterwards.
>
> The second issue I have is the semantics of @Generic specializations.
> Now, it implies a megamorphic cost for nodes, which has an impact on
> splitting.
> For me, Generic can also be just a field access that reads or stores
> objects, because that is the most generic case, but, does not imply that
> the node ever saw something other than objects.
> So, I wonder whether it would be useful to be able to define a cost
> parameter for the @Generic annotation, in order to be able to influence the
> cost of the resulting nodes?
>
> Thanks
> Stefan
>
> --
> Stefan Marr
> INRIA Lille - Nord Europe
> http://stefan-marr.de/research/
>
>
>
>