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

[Sven Claussner <scl gplus gmail com>]

Hi,

these are interesting thoughts and I'm glad to read about mathematics 
and computer science that goes beyond the day-to-day topics.

On  1.2.2016 at 10:35 PM Daniel Rogers wrote:

> Given these equivalencies, you can reasonably ask, can we use a
> different IR? Can we transform one IR to another? Can we use a different
> interpreter? The answer to all of these is yes, trivially.
>
> So. Can we transform a gegl graph to a llvm IR? Can we then pass that
> LLVM IR to llvm to produce the machine code equivalent of our gegl graph?
To my understanding much of this is already covered by the existing
GEGL graph language to C/OpenCL to binary code transformations.
One interesting application of IR transformation would IMHO be graph
optimization the same way query execution graphs in database systems are
optimized. So, if we have a graph of many GEGL ops the commutative ops
could be reordered to increase computation speed:
(Color Tool, Crop) --> (Crop, Color Tool)

Equivalent or inverse ops could be merged into one single op:
(Brightness + 10, Brightness -2) --> Brightness +8
or other ops working on a convolution matrix.

This might not work for all ops, e.g.
(Blur, Crop) --> (Crop, Blur)
would not work, because the Blur op processes adjacent pixels which get
lost by cropping (if we don't leave the Blur radius as extra border for
cropping).


> To your second question: the gegl tree is executed a lot. At least once
> for every tile in the output. This is especially true if gegl is used
> interactively and the same tree is evaluated thousands or millions of
> time with different inputs. Thus you would be trading an upfront cost of
> building the compiled graph with reduced runtime per tile, and reduced
> total runtime.
OK, I agree here.

> A really interesting follow up is just what other kinds of IR and
> runtimes can we use? Gegl to jvm bytecode? Gegl to Cg? Gegl to an asic?
> (FPGA, DSP, etc)?
Interesting brainstorming thoughts, too. Considering them I think the
OpenCL approach is the most flexible one, that could possibly also be
used to access DSP's computing power.

Greetings

Sven