[ImageJ-devel] imglib2-neon project for runtime bytecode transformation

Tobias Pietzsch pietzsch at mpi-cbg.de
Wed Sep 24 08:51:13 CDT 2014 

Hi Christian,

On 24 Sep 2014, at 11:47, Christian Dietz <christian.dietz at uni-konstanz.de> wrote:

> Hi Tobias,
> 
> I know we talked a lot about these issues and it's great that you found some time to tackle them. So, thank you very much for your effort. I really see the potential. ImageJ-Ops definitively can benefit from this approach indirectly (ImgLib2 using ASM) but also directly (using ASM n ImageJ-Ops). Unfortunately I will not take part at the next hackathon in Madison, but I can easily join you with Skype whenever you want to discuss ASM & Ops.
> 
> Anyway, I'm a bit puzzled concerning the benchmark on SubIntervals. Even the "unoptimized" iteration has a dramatic improvement in run-time using the agent. Is this due to the fact, the ImgLib2 already suffered from the megamorphic call-sites? Or do I misunderstand something?

Yes, exactly.
This is the last of several iterations through the whole benchmark, so the call in the loop has already been made megamorphic.
In the first iteration, you would see for the non-neon version the same performance for
>> normal cursor | array img

and then degrading from there.
So indeed, just the fact that several cursors have “gone through the code” makes the "normal cursor | array img | Optimized” go from 8ms runtime up to 371ms.
(And similar degradation for the other cursors.)

best regards,
Tobias

> 
> Again, thank you for the effort! This seems to be exactly what we need on the ImgLib2 side.
> 
> Christian
> 
> 
> 
> 
> 
> 
> On 24.09.2014 01:02, Tobias Pietzsch wrote:
>> Hi guys,
>> 
>> As a weekend project I have started to look into bytecode modification using the wonderful ASM library (http://asm.ow2.org).
>> I have cleaned up what I have played with and put it on github https://github.com/tpietzsch/neon.
>> 
>> It tackles a long-standing imglib obstacle, namely megamorphic call-sites in certain methods, where the JIT fails to recognise that the runtime target of the polymorphic changes between calls to a method but doesn’t change in the hot inner loop of the method during a single call. I have been talking about ideas to address this for quite some time, most recently here https://github.com/imglib/imglib/issues/71#issuecomment-51227237. Now I went ahead and actually tried to do something about it.
>> 
>> I have applied it to an example in imglib, which is described below. But for anyone not familiar with this particular issue (which is everyone except Christian probably) there
>> is an illustrative example with explanations in the README on github https://github.com/tpietzsch/neon/blob/master/README.md.
>> This does not involve imglib at all and is a clear illustration of the problem (and my solution).
>> 
>> I’m quite happy with how it turned out so far. It certainly has to be applied with care, but I think this can be potentially huge for imglib2. It might open up new possibilities that we have shied away from because of performance reasons, such as internal iteration for IterableIntervals.
>> 
>> Curtis, Johannes and Christian, I would also be interested what you think of this as a potential tool for imagej-ops.
>> I think it is orthogonal to what you do with compile-time code generation currently and therefore might complement it nicely.
>> 
>> I hope you have a look and tell me what you think.
>> I would be especially interested in whether you can think of optimization idioms besides the @Instantiate @ByTypeOf that is implemented right now.
>> It would be cool if we discuss this in the upcoming imglib hackathon.
>> 
>> Okay, everybody except Christian might as well stop reading now.
>> 
>> all the best,
>> Tobias
>> 
>> 
>> 
>> 
>> 
>> PS: the imglib stuff...
>> 
>> For the imglib issue https://github.com/imglib/imglib/issues/71, we played with ways of iterating pixels which can be optimized for certain subintervals of larger images.
>> The optimizations work out nicely when done on their own, but everything really breaks down when a single method is used with differnent Cursor incarnations.
>> This is actually already a potential problem in standard imglib, when Cursors from different Img types are uses in a single method. But adding the new optimized versions
>> only made it more probable that the problem actually occurs.
>> 
>> Here is numbers from a recent test, at a stage where 4 different kinds of cursors are in play:
>> 
>> normal cursor | array img
>> walk through a subinterval
>> 	| Unoptimized 	| Optimized 	| Speedup Time 	| Speedup % 	|
>> Best	|	566	|	371	| 195ms   	| 34.4%   	|
>> 
>> localizing cursor | array img
>> walk through a subinterval
>> 	| Unoptimized 	| Optimized 	| Speedup Time 	| Speedup % 	|
>> Best	|	907	|	584	| 323ms   	| 35.6%   	|
>> 
>> normal cursor | planar img
>> walk through a subinterval
>> 	| Unoptimized 	| Optimized 	| Speedup Time 	| Speedup % 	|
>> Best	|	562	|	373	| 189ms   	| 33.6%   	|
>> 
>> localizing cursor | planar img
>> walk through a subinterval
>> 	| Unoptimized 	| Optimized 	| Speedup Time 	| Speedup % 	|
>> Best	|	928	|	611	| 317ms   	| 34.1%   	|
>> 
>> 
>> With the neon java agent this improves to:
>> 
>> normal cursor | array img
>> walk through a subinterval
>> 	| Unoptimized 	| Optimized 	| Speedup Time 	| Speedup % 	|
>> Best	|	153	|	8	| 145ms   	| 94.7%   	|
>> 
>> localizing cursor | array img
>> walk through a subinterval
>> 	| Unoptimized 	| Optimized 	| Speedup Time 	| Speedup % 	|
>> Best	|	235	|	200	| 35ms   	| 14.8%   	|
>> 
>> normal cursor | planar img
>> walk through a subinterval
>> 	| Unoptimized 	| Optimized 	| Speedup Time 	| Speedup % 	|
>> Best	|	128	|	8	| 120ms   	| 93.7%   	|
>> 
>> localizing cursor | planar img
>> walk through a subinterval
>> 	| Unoptimized 	| Optimized 	| Speedup Time 	| Speedup % 	|
>> Best	|	217	|	208	| 9ms   	| 4.1%   	|
>> 
>> 
>> A speedup of factor ~4 to ~40 can be observed.
>> These two runs were made with exactly the same code, but for the second one, the program was run with the option
>>    java -javaagent:/path/to/neon-1.0.0-SNAPSHOT.jar …
>> 
>> I just pushed the example to https://github.com/imglib/imglib/commit/a9b70d923e9a84c4055acae96f71d05ca4a26344
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20140924/0a672e08/attachment-0001.pgp>

More information about the ImageJ-devel mailing list