[Pixman] 0.18.0 schedule

[Siarhei Siamashka]

On Tuesday 02 March 2010, Soeren Sandmann wrote:
> Koen Kooi <k.kooi at student.utwente.nl> writes:
> > > * The fast path cache:
> > >
> > >        
> > > http://cgit.freedesktop.org/~sandmann/pixman/log/?h=fast-path-cache
> >
> > I had a quick look at it and I noticed this:
> >
> > #define N_CACHED_FAST_PATHS 8
> >
> > How was that number established and what is the impact of
> > increasing/decreasing it?
>
> The impact of increasing the size is that cache misses will take
> somewhat longer, and that the per-thread memory overhead will be
> larger. Decreasing it means the probability of a cache hit goes down.
>
> There is no deep reasoning behind the number 8 - it may well be that
> it should be larger (or smaller, though I'd be surprised). I'd be
> interested in experimental results.

One can think about fast path cache in the same way as the current fast path
table, with the difference that only really used fast path functions will
be there (and all the ABGR entries will affect performance much less). For
this to work well, fast path cache should be large enough. But keeping the
fast path entries sorted introduces an overhead of it own and does not scale
well too.

Some variations can be tried:
1. Use a linked list instead of array (moving elements forward upon usage
will have a fixed cost)
2. Use something like round-robin replacement and treat cache like a ring 
buffer (fast addition of new data, but mostly unsorted order).
3. Implement something similar to N-way set associative CPU cache.

-- 
Best regards,
Siarhei Siamashka