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

[Tobias Pietzsch]

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/2908361d/attachment.pgp>