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


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

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]