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

Wed Sep 24 04:24:55 CDT 2014

Hi Steffi,

On 24 Sep 2014, at 02:12, Preibisch, Stephan <preibischs at janelia.hhmi.org> wrote:

> Hi Tobi,
> 
> this does look pretty impressive indeed. As it is modified on runtime, it should even work with new Types and Accessibles that are not part of ImgLib2 but some external program that is based on ImgLib2 and adds for example its own types, or?

Yes, absolutely.

> 
> Did you test if this scales well with larger number of instances? For ImgLib2 it would be something like |accessibles| x |types|, right? In many cases it would not use a lot of the possibilities, but for something like KNIME or ImageJ2 this might actually happen.

I did not do any larger tests yet.

Whether it would be |accessibles| x |types| for imglib depends on how it is used.
Lets assume that you have a function
  <T extends Type<T>> T getMax( Cursor<T> c, T type )
Then it depends on how you annotate it. For
  @Instantiate <T extends Type<T>> T getMax( @ByTypeOf Cursor<T> c, T type )
it would be instantiate it for ArrayCursor and ArrayLocalizingCursor, but ArrayCursor<IntType> and ArrayCursor<FloatType> would share the same instance.
For
  @Instantiate <T extends Type<T>> T getMax( Cursor<T> c, @ByTypeOf T type )
it would be instantiated for IntType and FloatType, but ArrayCursor<IntType> and ArrayLocalizingCursor<IntType> would share the same instance.
For
  @Instantiate <T extends Type<T>> T getMax( @ByTypeOf Cursor<T> c, @ByTypeOf T type )
you would have the full |cursor| x |type| space.

I don’t see this becoming a big problem at the moment.
We should anyway not indiscriminately apply it everywhere, only where we can really show a performance increase.

I see it as more of an issue if we add more of these instantiation idioms, for example for specializing classes. Then the number of instances might multiply through chains of such instantiations. Imagine the above with Cursor classes being generated depending on Type and number of dimensions. And that with Types being generated depending on the underlying Access.

The nice thing is that you only pay for what you actually use.
In any case, it is easy to cap the number of instances that are generated at a fixed number, and use the same instance for every newly occurring type after that.

> 
> Again, looks awesome! And if it turns out to be working in all cases, I agree, this could be a huge game changer.

Cool, thanks!
Tobias

> 
> Cheers,
> Steffi
> ---
> 
> Dr. Stephan Preibisch
> HFSP Fellow
> Robert H. Singer / Eugene Myers lab
> 
> Albert Einstein College of Medicine / HHMI Janelia Farm / MPI-CBG
> 
> email: stephan.preibisch at einstein.yu.edu / preibischs at janelia.hhmi.org / preibisch at mpi-cbg.de
> web: http://www.preibisch.net/
> 
> On Sep 23, 2014, at 19:02 , 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
>> 
> 
> 
> -- 
> -- 
> Please avoid top-posting, and please make sure to reply-to-all!
>  
> Mailing list web interface: http://groups.google.com/group/fiji-devel
> 
> --- 
> You received this message because you are subscribed to the Google Groups "Fiji-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fiji-devel+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20140924/c7772823/attachment.html>
-------------- 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/c7772823/attachment.pgp>