[Dune] Fwd: Re: MultiLinearGeometry

Fri Oct 12 21:51:17 CEST 2012

-------- Original Message --------
Subject: Re: [Dune] MultiLinearGeometry
Date: Fri, 12 Oct 2012 21:50:59 +0200
From: Martin Nolte <nolte at mathematik.uni-freiburg.de>
To: Oliver Sander <sander at mi.fu-berlin.de>

Hi Oli,

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).

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.

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+).

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

-- 
Dr. Martin Nolte <nolte at mathematik.uni-freiburg.de>

Universität Freiburg                                   phone: +49-761-203-5630
Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany