[osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

Hi Tim,

On Thu, 21 Jun 2018 at 08:25, Tim Moore <timoore33 at gmail.com> wrote:

> Before you move on, the big advantage of std::shared_ptr over intrusive
> reference counting is that support for weak pointers is rock solid. In the
> intrusive model, you can't implement thread-safe weak pointers without an
> auxiliary data structure, which complicates the implementation a lot. I
> know that one historic OSG performance win for  osg::ref_ptr  was the
> ability to not do the reference counting if it isn't needed, but with
> atomic increment / decrement implemented everywhere, do you think there is
> really much performance advantage for intrusive counting? Also,
> std::make_shared<>() allocates the shared_ptr control block in the same
> memory allocation as the shared object, so there need not be a memory
> fragmentation hit for using shared_ptr.
>
>>
The big advantage of intrusive reference counting is that the ref_ptr<>
holds a pointer to the actual object that you want to access, it's a single
jump. shared_ptr<> is literary a pointer to a shared pointer (which is a
reference counted object) to a the actual object that you want to access,
it's two pointers, two objects vs one pointer and one object.  Scene graphs
are predominately memory bandwidth limited so this extra level of
indirection is not even close to as efficient as intrusive reference
counting.  The only advantage that shared_ptr<> has is that it works with
any type, but with a scene graph the types are mostly all under our control
there is no cost in complexity of having intrusive reference counting, just
stick it into the base class that most classes use anyway and your job is
done.

So... as my aim where possible is to make the VulkanSceneGraph more
efficient than the OpenSceneGraph I can't just put chains around my ankles
by adopting shared_ptr<>, instead I will acknowledge where the
OpenSceneGraph already does something well and following this approach,
albeit in a modern C++ way.

For the thread safe observer_ptr<> you do need a separate auxiliary object,
just like the OSG, so in my prototyping this is already what I have done.
I already have an vsg::Auxiliary object that is created when required, this
Auxiliary object is for more than just supporting observer_ptr<> though, it
also stores optional extra user data.  Doing this shrinks the base
vsg::Object/Node classes and improves memory utilization, providing a
measurable gain in construction, destruction and traversal of the scene
graph over what can be done with the OSG.

When adopting new features of C++ you have to understand what is happening
under the hood, for software that is performance critical like a scene
graph you have to take the time to make sure there aren't hidden
performance costs are, if there is a cost then you have to be really sure
that this cost is worth the value it provides.  shared_ptr<>/weak_ptr<>
don't cut it for the core scene graph.  There are plenty of other modern
C++ features that are really neat and just make life easier without a cost,
you'll see this sprinkled everywhere in the VulkanSceneGraph.

Cheers,
Robert.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20180621/6494911c/attachment.html>