[TruffleDSL] Splitting and Cost of Generic Nodes
Christian Humer
christian.humer at gmail.com
Sat May 31 00:10:54 UTC 2014
Hi,
> > 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?
>
> Well, removing the condition (isMaxSingleCall) [see 1] solves all the
> issues for me.
> After that, I do not have any benchmark (I am aware of) that gives trouble
> with splitting enabled.
> That’s why I am asking. To me, that condition just doesn’t seem very
> useful, and I would like to understand in which cases it might be useful.
Well, splitting has some implications also on inlining. The more you split
the more context sensitive (the better) your inlining decisions are. We
have already improved on that by using a more leaf based inlining approach.
Still they are not independent and most likely causing my current
regressions. Also just counting the polymorphism of nodes may not be good
enough.
So what I want to say is that I do not really like to remove this branch at
the moment.
If you want, I can offer you to make it temporary configurable with a
runtime flag.
- Christian Humer
On Fri, May 30, 2014 at 10:45 PM, Stefan Marr <java at stefan-marr.de> wrote:
> Hi Christian:
>
> On 30 May 2014, at 22:39, Christian Humer <christian.humer at gmail.com>
> wrote:
>
> > 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?
>
> Well, removing the condition (isMaxSingleCall) [see 1] solves all the
> issues for me.
> After that, I do not have any benchmark (I am aware of) that gives trouble
> with splitting enabled.
> That’s why I am asking. To me, that condition just doesn’t seem very
> useful, and I would like to understand in which cases it might be useful.
>
> > @Generic is the wrong name for this annotation. In the next iteration of
> the DSL this annotation is going to be renamed to @Fallback.
>
> Ok, I see. Well, I did remove all uses of @Generic already, after I saw
> the consequence for splitting.
>
> Thanks
> Stefan
>
>
> [1]
> https://github.com/smarr/graal/commit/caa1fc084623f4e6ae3087dec9da81ce859aa906
>
>
> --
> Stefan Marr
> INRIA Lille - Nord Europe
> http://stefan-marr.de/research/
>
>
>
>
More information about the graal-dev
mailing list