Re: Cache strategy

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

 



On Tue, Jun 16, 2009 at 6:31 AM, Martin Nordholts<enselic@xxxxxxxxx> wrote:
> 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.

The current approach where the common logic in the node/processing
code creates the destination GeglBuffer for the computation is already
well separated. GeglOperation::do_process doesn't beloing inside
GeglOperation but would be a new name for the current (and perhaps
extended) functionality of figuring out how to create the GeglBuffer
for computation.

> 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.

In most instances, this would only incur synchronization of a few
tiles where the chunks/work regions overlaps. Unless you are stupid
and compute with chunk-size~=tile-size the impact of this should be
mostly neglible.

-- 
«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/
_______________________________________________
Gegl-developer mailing list
Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer


[Index of Archives]     [Yosemite News]     [Yosemite Photos]     [gtk]     [GIMP Users]     [KDE]     [Gimp's Home]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux