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

[Johannes Schindelin]

Hi Tobias,

On Tue, 30 Sep 2014, Tobias Pietzsch wrote:

> On 25 Sep 2014, at 19:58, Johannes Schindelin <schindelin at wisc.edu> wrote:
>
> > It is great that you continue our conversation from the hackathon last
> > year in Madison:
> >
> > 	http://fiji.sc/2013-05-03_-_ImgLib2_Hackathon_in_Madison
> >
> > I am very glad that you have returned to this work, with a promising
> > initial foray into a general solution.
>
> I need to make clear that (ex-)neon is not a continuation of our
> hackathon conversation.

I apologize, then. I just thought that your work was intended to address
one of the two major advices I raised at the hackathon (in person, I did
not think of writing it up): 1) ImgLib2 should be made easier to use e.g.
for life scientists and 2) ImgLib2 should pay more attention to being
performant by default.

It does look that your work addresses 2) so I am happy.

> 	It should be clear, that this will never (!) produce something
> 	that runs faster than the optimistically compiled code, that is,
> 	the case where polymorphism was not realized at runtime.

This has not been clear to me, thanks for clarifying.

> [...] in my opinion [replacing algorithms by handcrafted code] is a
> complementary approach. The advantage is potentially higher performance.
> The drawback is that you basically hand-code things. It’s targeted at a
> specific library and/or application. If the library code changes too
> much, it is likely to break.

Oh, but I stressed the point at the hackathon that my demonstration was
intended to show where the performance needs to be, not how to reach it.

In the meantime, it has become even more obvious to me that a generic data
processing framework requires a proper API to allow overriding generic
algorithm implementations with specific, hand-optimized code, and that the
original implementation must not be allowed to prevent the hand-optimized
code from being executed.

> Sorry for being so nit-picky about it

In contrast, I am happy that the conversation about the performance of
data processing in ImageJ2 continues!

> There is overlap between OpenJDK and ASM people. ASM is used in the JDK
> itself (to implement java 8 lambda expressions for example).

Speaking of Java 8: you might want to consider using its Scala-inspired
features instead. This would limit the use for the general audience, but it
would probably benefit greatly individual developers who can afford to switch
to Java 8.

> > [...] If you have a chance to explore OPS in depth before the
> > hackathon, it would be very helpful to expedite later discussion [...]
> > because it provides the necessary infrastructure already, matured over
> > a course of several iterations.
>
> I’ve been following ImageJ-Ops loosely. As I understand it still very
> much in flux and documentation is very sparse. I’m looking forward to
> learn about it in personal discussion at the hackathon. I’ll probably
> not be able to get an in-depth look before.

If you do find some time in the next weeks to look at the Ops tutorials
https://github.com/imagej/imagej-tutorials/tree/master/using-ops and
https://github.com/imagej/imagej-tutorials/tree/master/create-a-new-op
it will help the discussion. Do not worry if you do not find the time: the
issue of ImgLib2 release management is the real topic of the hackathon, and
we will be plenty busy with it.

> Does ImageJ2 use custom ClassLoaders?

By virtue of the legacy ImageJ 1.x's PluginClassLoader loading all the
plugin classes: yes.

Thank you for keeping the conversation going,
Johannes