Truffle update instructions?

[Stefan Marr]

Hi Thomas:


> On 15 Apr 2015, at 16:10, Thomas Wuerthinger <thomas.wuerthinger at oracle.com> wrote:
> 
> How to interpret the numbers in the table you linked?

Each benchmark is done in two version, the one with >] at the end, should have reached a stable state, based on a predefined constant and a little headroom. So, for those, in the best case, we see peak performance, without any compilation interfering.

The benchmarks with [> at the end are executing exactly once, so, this will include compilation times, and everything else going on.


The raw values in the first columns are just time etc.
The interesting columns for me are the last two. The Change column shows how the runtime differs with the previous run. So, if runtime increases from 100ms to 140ms, it will indicate a 40% change, and is colored red.

The Trend column is the runtime change comparing not the previous but the revision from 10 benchmark runs/pushes ago.

Does that help?

Best regards
Stefan

PS: I think, Andreas tip is going in the right direction. For the benchmark with the worst slowdown I saw that none of the closures (blocks) were eliminated.

> 
> Thanks, thomas
> 
> 
>> On 15 Apr 2015, at 13:25, Stefan Marr <java at stefan-marr.de> wrote:
>> 
>> Hi:
>> 
>> In the non-TruffleDSL related changes of last night was something that fixed some of my TruffleSOM benchmarks.
>> 
>> However, there are still huge slowdowns.
>> Will investigate further.
>> 
>> On the positive side, some of the benchmarks show nice improvements for warmup times.
>> 
>> http://som-speed.stefan-marr.de/changes/?tre=10&rev=975521543086049df4471ae1dde279fdd1e34db2&exe=9&env=1
>> 
>> Best regards
>> Stefan
>> 
>>> On 14 Apr 2015, at 23:00, Stefan Marr <java at stefan-marr.de> wrote:
>>> 
>>> Hi Christian:
>>> 
>>> 
>>>> On 09 Apr 2015, at 22:23, christian.humer at gmail.com wrote:
>>>> 
>>>> […] -G:+PrintTruffleExpansionHistogram […]
>>>> 
>>>> You can also run with -G:+TraceTrufflePerformanceWarnings which may also show you potential problems (Note that this tool also outputs a few false positives).
>>> 
>>> Ok, those two tools point at similar things. The histogram shows that there are remaining calls that are not inlined. And the same is pointed out by the performance warnings.
>>> 
>>> It looks like this:
>>> 
>>> [truffle] perf warn        not inlined Special call to HotSpotMethod<FrameWithoutBoxing.getLong(FrameSlot)> (20|MethodCallTarget)
>>> [truffle] perf warn        not inlined Special call to HotSpotMethod<FrameWithoutBoxing.setLong(FrameSlot, long)> (43|MethodCallTarget)
>>> [truffle] perf warn        not inlined Special call to HotSpotMethod<FrameWithoutBoxing.getArguments()> (102|MethodCallTarget)
>>> [truffle] perf warn        non-leaf type checkcast: Lsom/vmobjects/SObject; (118|CheckCast)
>>> [truffle] perf warn        non-leaf type instanceof: Lsom/vmobjects/SObject; (116|InstanceOf)
>>> 
>>> I also see those calls in IGV.
>>> It looks to me like the basic frame access are not compiled for some reason.
>>> 
>>> Is that about right? Any idea what the cause could be?
>>> 
>>> Thanks
>>> Stefan
>>> 
>>> PS: I updated to the latest Graal version of today.
>>> 
>>> -- 
>>> Stefan Marr
>>> INRIA Lille - Nord Europe
>>> http://stefan-marr.de/research/
>>> 
>>> 
>>> 
>> 
>> -- 
>> Stefan Marr
>> INRIA Lille - Nord Europe
>> http://stefan-marr.de/research/
>> 
>> 
>> 
> 

-- 
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/