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
_______________________________________________
ImageJ-devel mailing list
ImageJ-devel@imagej.net
http://imagej.net/mailman/listinfo/imagej-devel
