Re: [Gegl-developer] VIPS and GEGL performance and memory usage comparison

[Øyvind Kolås <pippin gimp org>]

On Mon, Feb 1, 2016 at 10:35 PM, Daniel Rogers <daniel phasevelocity org> wrote:
> > >   * Anyone can do dynamic compilation nowadays with llvm.  Imagine
> > >
> > >     taking the gegl dynamic tree, and compiling it into a single LLVM
> > >     dynamically compiled function.
> >
> > What exactly do you mean? How is this supposed to work and where is the
> > performance advantage if done at runtime?
>
> To your first question. I made that statement as a counterpoint to vips
> turning a convolution kernel into a set of sse3 instructions and executing
> them.
>
> I believe, though haven't proven rigorously, that a gegl graph is
> homomorphic to a parse tree of an expression language over images.

For a subset of operation this might work, but not for generic ops -
that possibly use shared libraries rather than arithmetic in their
implementation, an approach that might work out for some of the subset
and permit reusing existing infrastructure in GEGL is to recombine the
cores of OpenCL point filters/composers and submit one image
processing kernel for OpenCL compilation - which for many(/most?)
OpenCL implementations would end up using LLVM in the background.

This is however different from my complaint of the benchmark
comparison - where VIPS is using a 3x3 convolution kernel, and the
GEGL code uses gegl:unsharp-mask which is : gegl:gaussian blur + a
point composer .. which in turn is a horizontal blur, and a vertical
blur + a point composer. Comparing a 3x3 area op with a composite much
more general purpose sharpening filter that can do (and already for
the parameters provided) would do larger input area as well as by its
nature have more temporary buffers is not a proper apples to oranges
comparison. Adding a gegl:3x3-convolution (or adapting
gegl:convolution-matrix to detect the extent of the kernel) might make
GEGL perform closer to VIPS on this benchmark which caters well to
VIPS features. I do however not think we should add "hard-coded" 3x3
sharpen/blur ops in GEGL.

/pippin