OIIO's texture cache isn't "lock free", but it is concurrent. Multiple threads
can access the cache at the same time, and the vast majority of time, a thread
will not actually block waiting for another thread.
So the question is, if we did a tricky re-implementation of the cache to be
technically lock-free, would we gain appreciable performance versus our current
concurrent (though not lock-free) implementation, and do so without introducing
any new bugs? (True lock-free programming is notoriously subtle stuff.)
I'm not sure it's easy to tell if it's worth the effort, without doing all the
work and then benchmarking the results. But one way to guess is to look at the
current stats -- which do try to keep track of the total amount of time that
threads wait on the locks -- and if it's not an appreciable part of runtime, we
can confidently say that there is not much gain expected from a rewrite of the
cache.
So is this just of academic interest, or have you seen statistics from
production use that indicate an actual performance bottleneck here?
-- lg
> On Aug 17, 2017, at 9:02 AM, Negroove <[email protected]> wrote:
>
> PBRT published a lock-free implementation of texture cache, which seems very
> interesting:
>
> http://pbrt.org/texcache.pdf
>
> Is it possible to have similar optimizations in OpenImageIO?
>
> Regards,
> Elvic
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
