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

[Albert Cardona]

Hi Tobias,

Just to add to the cheer. It is not everyday that one sees 97% improvements on performance. I understand this is preliminary. Looking forward to seeing it applied in real world code.

Albert


> On Sep 23, 2014, at 7:02 PM, Tobias Pietzsch <pietzsch at mpi-cbg.de> 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
>