[osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Tim Moore]

Hi Robert,

On Thu, Jun 21, 2018 at 9:35 AM, Robert Osfield <robert.osfield at gmail.com>
wrote:

> 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.
>
> This is not the way shared_ptr is implemented, at least in gcc. The shared
pointer contains a pointer to the object as well as to the control block.
You could argue that this makes a shared_ptr twice the size of an
osg::ref_ptr, but I really can't speculate on the overall effect on memory
usage.

> 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.
>
What's the measured gain?

>
> 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
>
Agreed :)

> 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.
>
>
> Of course I trust your judgement, but I struggled mightily with weak
pointer thread safety back in the day and am happy to be able to make it
someone else's problem now. I am very happy that VulkanSceneGraph is coming
on the scene!

Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20180621/54aa4055/attachment.html>