[Dune] [Dune-Commit] dune-geometry r57 - trunk/dune/geometry/genericgeometry

[Carsten Gräser]

Hi Martin,

Am 02.04.2012 14:39, schrieb Martin Nolte:
> Hi Carsten,
> 
> you are right that there might be no gain due to padding. However, using
> a bit field allows more optimization to the compiler.
> 
> Notice also that your measurements were made on a fixed architecture
> with a fixed compiler. But C++ is a language standard and there are
> multiple possible implementations of the language. To my knowledge, the
> standard allows a bool to be as large as an integer, which could be 8
> byte on some 64 bit architectures.
> 
> Anyway, my comment should have read 'potentially decrease memory
> consumption', because, as far as I understand, the alignment of
> bitfields is not specified and the compiler might still use, e.g., 8
> byte for each of the bool values. However, real world compilers will
> hardly ever do this.
This is of course implementation dependent. However it seems to be
not uncommon to use linux on x86/x86-64 or architectures with even
stricter alignment rules.

> But maybe you could enlighten me on the point of your comment? Do you
> want me to revert the patch? Do you just want to ask for caution? Did
> you want me to explain? Or did you want me to give the short answer 'in
> general, no'?

I just wanted to understand the purpose of this patch since the memory
reduction will in many cases not happen. 'allows more optimization'
seems to answer this question.

Thanks and best regards,
Carsten

> 
> Best,
> 
> Martin
> 
> 
> P.S.: Speaking about bit fields: I'm not even sure that the base64
> encoding of the VTK writer is guaranteed to produce the 'right' output
> on every standard-conforming compiler. But then, I don't know how
> paraview reads the data, either, so maybe there simply cannot be any
> problem.
> 
> 
> 
> On 04/02/2012 01:54 PM, Carsten Gräser wrote:
>> Hi Martin,
>>
>> Am 02.04.2012 11:45, schrieb mnolte at dune-project.org:
>>> Author: mnolte
>>> Date: 2012-04-02 11:45:06 +0200 (Mon, 02 Apr 2012)
>>> New Revision: 57
>>>
>>> Modified:
>>>     trunk/dune/geometry/genericgeometry/cachedmapping.hh
>>> Log:
>>> use a bitfield (slightly reduces memory consumption)
>> are you sure that this really reduces memory consumption?
>> If you have more members than just the bitfield you might
>> get padding due to alignment rules. In the attached example
>> struct A containing only a bitfield has the expected size
>> of one byte while all the others have 12 byte (x86, gcc-4.6.1).
>>
>> Best,
>> Carsten
>>
>> struct A
>> {
>>      bool a_:1;
>>      bool b_:1;
>>      bool c_:1;
>> };
>>
>> struct B
>> {
>>      double x_;
>>      bool a_:1;
>>      bool b_:1;
>>      bool c_:1;
>> };
>>
>> struct C
>> {
>>      double x_;
>>      bool a_;
>> };
>>
>> struct D
>> {
>>      double x_;
>>      bool a_;
>>      bool b_;
>>      bool c_;
>>      bool d_;
>> };
>>
>>
>>>
>>>
>>> Modified: trunk/dune/geometry/genericgeometry/cachedmapping.hh
>>> ===================================================================
>>> --- trunk/dune/geometry/genericgeometry/cachedmapping.hh   
>>> 2012-04-01 08:52:17 UTC (rev 56)
>>> +++ trunk/dune/geometry/genericgeometry/cachedmapping.hh   
>>> 2012-04-02 09:45:06 UTC (rev 57)
>>> @@ -41,10 +41,6 @@
>>>
>>>         typedef typename GeometryTraits::Caching Caching;
>>>
>>> -      typename Traits::JacobianTransposedType jacobianTransposed;
>>> -      typename Traits::JacobianType jacobianInverseTransposed;
>>> -      typename Traits::FieldType integrationElement;
>>> -
>>>         CachedStorage ()
>>>         : affine( false ),
>>>           jacobianTransposedComputed( false ),
>>> @@ -52,11 +48,15 @@
>>>           integrationElementComputed( false )
>>>         {}
>>>
>>> -      bool affine;
>>> +      typename Traits::JacobianTransposedType jacobianTransposed;
>>> +      typename Traits::JacobianType jacobianInverseTransposed;
>>> +      typename Traits::FieldType integrationElement;
>>>
>>> -      bool jacobianTransposedComputed;        // = affine, if
>>> jacobian transposed was computed
>>> -      bool jacobianInverseTransposedComputed; // = affine, if
>>> jacobian inverse transposed was computed
>>> -      bool integrationElementComputed;        // = affine, if
>>> integration element was computed
>>> +      bool affine : 1;
>>> +
>>> +      bool jacobianTransposedComputed : 1;        // = affine, if
>>> jacobian transposed was computed
>>> +      bool jacobianInverseTransposedComputed : 1; // = affine, if
>>> jacobian inverse transposed was computed
>>> +      bool integrationElementComputed : 1;        // = affine, if
>>> integration element was computed
>>>       };

-- 
----------------------------------------------------------------------
Dr. Carsten Gräser       | phone: +49-30 / 838-75349
Freie Universität Berlin | fax  : +49-30 / 838-54977
Institut für Mathematik  | email: graeser at math.fu-berlin.de
Arnimallee 6             |
14195 Berlin, Germany    | URL  : http://page.mi.fu-berlin.de/graeser
----------------------------------------------------------------------