Re: Cache strategy

[Martin Nordholts <enselic@xxxxxxxxx>]

Øyvind Kolås wrote:
> On Mon, Jun 15, 2009 at 8:12 PM, Patrik Östman<pa.ostman@xxxxxxxxx> wrote:
>   
>> node 1  to node 2. Are there any significant changes of cache
>> handling done between 0.0.20 and 0.0.22 or are there a
>> setting that must be turned on to get 'per node caches'
>> functionality?
>>     
>
> The caching policies and mechanisms in GEGL are still basic and rough.
> At the moment the GeglOperationClass has a boolean no_cache member
> that is checked. Which operation subclasses automatically do cache
> have changed lately since the memory consumption of caching every
> single node probably outweighs the benefits of caches for every single
> node. In particular I think point operations now explicitly do not
> cache their results.
>
> Ive entertained the idea to use special nodes to indicate caches, but
> that would to some extent muddle the graph. Perhaps a better solution
> is to allow turning the caches on dynamically on demand and not only
> define such hints in the class, the existing implementation should be
> possible to bend in both ways.
>
>   

I've been thinking a while lately what the overall model would be for a 
redesign of the caching strategy used in GEGL. First of all, I don't 
think explicit cache nodes would solve that many problems. We would 
still need a way to propagate invalidation of nodes through the graph to 
invalidate the cache, and that logic still needs to be on the lowest 
node level. Furthermore, as you say, only allowing caching in explicit 
cache nodes will be very cumbersome if one needs to do clever on-demand 
caching in parts of the graph, and that will be needed in an interactive 
application with a large graph such as GIMP. For example, when you 
interactively apply geometric transforms on a layer, you will want to 
have caching right before the compositor op that composes the 
transformed layer onto the projection. You will not want to have caches 
on the compositor ops all the time though because it would cause a giant 
memory overhead.

One caching strategy that I think we will come pretty far with is to 
handle caching in a wrapper function to GeglOperation::process(). That 
is, the GeglEvalVisitor would not call GeglOperation::process() directly 
but instead something like GeglOperation::do_process(). This method 
would contain common logic for caching. If caching is turned off, it 
would simply call GeglOperation::process() and not do much more. If 
caching is turned on, it would not bother calling 
GeglOperation::process() and instead just return what it has cached. 
This strategy would also collect caching to a common place instead of 
spreading it across the GeglEvalVisitor and the GeglNeedVisitor (former 
GeglCrVisitor).

The wrapper function GeglOperation::do_process() would also be a natural 
place to have logic for turning off the "visibility" or "activeness" of 
a node. When a node is invisible/inactive, it acts as a gegl:nop and 
just passes its input directly to its output. That will allow us to 
easily implement toggling the visibility of traditional layers, and also 
toggling the "visibility" of layer effects such as a blur or emboss.

Another thing worth mentioning is that caches on every node doesn't 
scale well to concurrent evaluation of the graph since the evaluators 
would need to all the time synchronize usage of the caches, preventing 
nice scaling of performance as you use more CPU cores/CPUs.

  / Martin
_______________________________________________
Gegl-developer mailing list
Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer