[Truffle] Changes to DispatchNodes

[Chris Seaton]

Those nodes look optimal to me. A single reference comparison guard in each
- that's what you want to see.

The only suggestion would be to have two
interfaces AbstractCachedUnboxedDispatchNode
and AbstractCachedBoxedDispatchNode. Then you can statically type
your executeDispatch to either take Object or SObject and avoid the unsafe
cast.

I'm surprised that you are still seeing overhead from method calls and
needing to specialise early, but you are implementing a different language
to me so I'm sure you have different bottlenecks.

I'd add the extra note of caution that any future Truffle tooling like
profilers, debuggers and so on may expect a Truffle CallTarget boundary for
guest language methods to be able to automatically 'read' your guest
language.

Chris


On 12 March 2014 14:08, Stefan Marr <java at stefan-marr.de> wrote:

> Hi Chris:
> [cc list]
>
> As discussed, I changed the message dispatch of TruffleSOM a bit to
> simplify it and avoid another bunch of tests/branches at runtime.
>
> Now, I got a chain of dispatch nodes, where the first nodes (if available)
> do just a check for the Java class.
> [Note, I am using another strategy for boxed and unboxed objects, and I
> have ‘builtin’ classes which have Java class representations. So, this part
> covers already a lot of room.]
>
> After those simple cases [1], I have a special check node (introduced when
> necessary) that makes sure that for all following nodes, the receiver is
> guaranteed to be a SObject, which got a getSOMClass(.) method [2].
> In case that check fails, I continue on a branch to an
> UninitializedDispatch node, and do the usual thing to introduce a new
> cached node.
>
> If it succeeds, I go on with the cache entries that are proper SObjects
> and the check does only read the class field and does a reference
> comparison [3]. The chain is terminated as usual with a Uninitialized node.
>
> The change gives up to 30% improvement on the various benchmarks.
> Especially the more complex ones seem to benefit from the simple tests.
> Things like Dispatch, which really just measures the method dispatch (and
> looping) overhead, doesn’t benefit at all. Probably because in those cases
> the optimizer is still ok with it. [Just guessing]
>
> The original motivation for the change was to see whether overall simpler
> and faster dispatch would avoid the need for early primitive specialization
> that avoids message sends and inline caching altogether, and well. No, it
> doesn’t. Fibonacci benefits with a 64% speedup from the early
> specialization, and even Richards and DeltaBlue still get 5% faster. So, it
> still seems to be better to avoid the dispatch altogether when possible.
> So, I am still thinking of changing TruffleDSL for my case to make that
> nicer.
>
> Best regards
> Stefan
>
> [1]
> https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/dispatch/CachedDispatchSimpleCheckNode.java
> [2]
> https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/dispatch/SObjectCheckDispatchNode.java
> [3]
> https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/dispatch/CachedDispatchSObjectCheckNode.java
>
>
>
> --
> Stefan Marr
> INRIA Lille - Nord Europe
> http://stefan-marr.de/research/
>
>
>
>