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

[Christian Dietz]

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?

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
>