[Dune] MultiLinearGeometry

Sat Oct 13 11:31:19 CEST 2012

Hi Martin,

> as I said, the gcc implementation actually stores two pointers in a
> shared_ptr (my second option). The first is _M_ptr (pointing to the
> object itself), the second is hidden in _M_refcount. The latter actually
> stores a pointer _M_pi to an object of type Sp_counted_base<_Lp>. The
> latter in turn cotains two counters: _M_use_count (number of shared_ptrs
> pointing to it) and _M_weak_count (basically number of weak pointers
> pointing to it).
>
> Note: You cannot store the reference count in a reference counting
> pointer directly (as there are multiple copies of the pointer).
>
you are, of course, correct, and I was wrong.  Still I am not convinced
that this construction leads to a performance loss when, e.g, dereferencing.

> But the real point is that I want to use an allocator to create the
> geometry (no new for me, please). And you're right here: The
> std::shared_ptr (C++11) supports this through allocate_shared. Having
> had a look at gcc's implementation, however, I definitely think that we
> don't want a fallback for this (extremely complex) code.
>
Maybe we can have a fallback implementation that simply uses 'new' to
implement allocate_shared?  That way code would compile on all supported
compilers, only for best performance you need a recent compiler.

> So, I guess I will stick to the current implementation; it is simple and
> does its job. In the long run I would like to get rid of the reference
> counting pointer anyway. But my stomach says that this will require
> further interface changes (or a waste of performance in 3d+).
>
Okay!

Best,
Oliver

> Best,
>
> Martin
>
> On 10/12/2012 06:16 PM, Oliver Sander wrote:
>> Hi Martin,
>>
>>> first of all, I'm not an expert on the stl, so there might be a way to
>>> put the reference counter into the object the smart pointer points to.
>>> However, as far as I understand things, the shared_ptr actually points
>>> to a control structure containing (at least) the following:
>>> - a counter of strong references (by shared_ptr),
>>> - a counter of weak references (by weak_ptr),
>>> - a pointer to the real object in memory.
>>
>> A quick test shows that on my machine a std::shared_ptr needs 16 bytes.
>> That's not too bad: you need at least one pointer to the actual
>> object (8 bytes), and the reference counter (4 bytes). I haven't
>> dug in the code deep enough to see what the remaining 4 bytes are.
>>
>>> Unfortunately, this control structure must be allocated somehow, so
>>> there is an additional "new" (again, there might be a way around this
>>> that I don't know of).
>>
>> True. But this is why std::make_shared was invented. It produces
>> a shared_ptr with only single allocation. AFAIK that only c++0x, but
>> dune-common provides a compatibility layer in dune/common/shared_ptr.hh
>>
>>> Moreover, dereferencing a shared_ptr either
>>> dereferences two pointers (the one to the control structure and the
>>> pointer to the real object), or the shared_pointer needs to contain both
>>> pointers.
>>>
>> Not true. Since you hold the shared_ptr by value you have only on pointer
>> to dereference. Copy'n'paste from the stl:
>>
>> operator->() const noexcept
>> {
>> _GLIBCXX_DEBUG_ASSERT(_M_ptr != 0);
>> return _M_ptr;
>> }
>>
>> and _M_ptr is a plain pointer.
>>
>>> In summary: The shared_ptr seems unnecessarily expensive to me if I just
>>> want a simple reference counting pointer (being prepared to store the
>>> reference count on the object itself).
>>>
>>> Puh, a long answer. Maybe someone more into the stl can enlighten me on
>>> where I'm right and where I'm wrong. Until then, I prefer coding it
>>> myself ;-).
>>>
>> Conclusio: you may want to give the stl another chance, and save yourself
>> some coding time & headaches. :-)
>>
>> cheers,
>> Oliver
>>
>>
>>> Best,
>>>
>>> Martin
>>>
>>> On 10/12/2012 05:11 PM, Oliver Sander wrote:
>>>> Hi Martin,
>>>>
>>>>> as the name says, the user data field is for your data. GeometryGrid
>>>>> uses it for the reference count.
>>>>
>>>> just out of curiosity: what's wrong with the stl way of reference
>>>> counting?
>>>>
>>>> best,
>>>> Oliver
>>>>
>>>>> If you specify an empty class, no
>>>>> memory is used (a trick I learned from gcc's std::vector). If you
>>>>> don't
>>>>> need it, just leave it at the default (empty).
>>>>>
>>>>> Best,
>>>>>
>>>>> Martin
>>>>>
>>>>> On 10/12/2012 04:50 PM, Oliver Sander wrote:
>>>>>> Hi Martin,
>>>>>> thanks! I'm looking forward to making UGGrid use that instead of
>>>>>> BasicGeometry.
>>>>>> Can you give a short explanation what the userData is good for?
>>>>>> best,
>>>>>> Oliver
>>>>>>
>>>>>> Am 12.10.2012 16:03, schrieb mnolte at dune-project.org:
>>>>>>> Author: mnolte
>>>>>>> Date: 2012-10-12 16:03:14 +0200 (Fri, 12 Oct 2012)
>>>>>>> New Revision: 1072
>>>>>>>
>>>>>>> Modified:
>>>>>>> recent_changes.wml
>>>>>>> Log:
>>>>>>> announce the new MultiLinearGeometry (see FS#1182)
>>>>>>>
>>>>>>>
>>>>>>> Modified: recent_changes.wml
>>>>>>> ===================================================================
>>>>>>> --- recent_changes.wml 2012-10-09 16:18:26 UTC (rev 1071)
>>>>>>> +++ recent_changes.wml 2012-10-12 14:03:14 UTC (rev 1072)
>>>>>>> @@ -54,6 +54,11 @@
>>>>>>> dimension and codimension. Since such hypercubes have a lot of
>>>>>>> structure, the
>>>>>>> implementation
>>>>>>> is very fast.
>>>>>>> </li>
>>>>>>> +<li>A reimplementation of the generic geometries,
>>>>>>> named<kbd>MultiLinearGeometry</kbd>
>>>>>>> + has been added. It comes without a complicated TMP and abandons
>>>>>>> the
>>>>>>> use of
>>>>>>> dynamic
>>>>>>> + polymorphism in the case of multiple geometry types. Despite these
>>>>>>> simplifications,
>>>>>>> + it shows slightly better performance.
>>>>>>> +</li>
>>>>>>> </ul>
>>>>>>>
>>>>>>> <h3>Deprecated and removed features</h3>
>>>>>>> @@ -91,6 +96,9 @@
>>>>>>> Jacobians to be FieldMatrices anymore. The precise interface
>>>>>>> requirements for
>>>>>>> these matrices
>>>>>>> is still being worked out.
>>>>>>> </li>
>>>>>>> +<li><kbd>GeometryGrid</kbd> now uses the
>>>>>>> new<kbd>MultiLinearGeometry<kbd>
>>>>>>> instead of the
>>>>>>> + generic geometry implementaton.
>>>>>>> +</li>
>>>>>>> </ul>
>>>>>>>
>>>>>>> <h3>Deprecated and removed features</h3>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Dune-Commit mailing list
>>>>>>> Dune-Commit at dune-project.org
>>>>>>> http://lists.dune-project.org/mailman/listinfo/dune-commit
>>>>>>
>>>>>> _______________________________________________
>>>>>> Dune mailing list
>>>>>> Dune at dune-project.org
>>>>>> http://lists.dune-project.org/mailman/listinfo/dune
>>>>>
>>>>
>>>> _______________________________________________
>>>> Dune mailing list
>>>> Dune at dune-project.org
>>>> http://lists.dune-project.org/mailman/listinfo/dune
>>>
>>
>> _______________________________________________
>> Dune mailing list
>> Dune at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune
>