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

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

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'?

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
>>       };
>>
>>
>>
>>
>> _______________________________________________
>> Dune-Commit mailing list
>> Dune-Commit at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune-commit
>
>

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