[Insight-developers] Empty FixedArray destructor: Performance hit using gcc (times 2) : -malign-double

[Luis Ibanez]

Hi Tom,


Trying to understand why this alignment happens, we have reduced
the test to minimalistic implementation of FixedArray:



class MyArray
{
public:
   MyArray() {};
   ~MyArray() {};
   double operator[](unsigned int k)
     {
     return foo[k];
     }
   double foo[2];
};



With this implementation we have reproduced your observation
that:


   a) When the destructor exists, an array of MyArray(s) is
      allocated in a 4byte boundary

   b) When the destructor does not exists, an array of
      MyArray(s) is allocated in a 8byte boundary


Then, by Googling about it we found this GCC flag:

               -malign-double

When compiling with this flag, your test is always aligned
to 8 bytes, regardless of whether the destructor is present
or not.



"Optimization in GCC"
January 26th, 2005 by M. Tim Jones
http://www.linuxjournal.com/article/7269


<quote>
Alignment Optimizations

In the second optimization level, we saw that a number of alignment
optimizations were introduced that had the effect of increasing
performance but also increasing the size of the resulting image. Three
additional alignment optimizations specific to this architecture are
available. The -malign-int option allows types to be aligned on 32-bit
boundaries. If you're running on a 16-bit aligned target, -mno-align-int
can be used. The -malign-double controls whether doubles, long doubles
and long-longs are aligned on two-word boundaries (disabled with
-mno-align-double). Aligning doubles provides better performance on
Pentium architectures at the expense of additional memory.

Stacks also can be aligned by using the option
-mpreferred-stack-boundary. The developer specifies a power of two for
alignment. For example, if the developer specified
-mpreferred-stack-boundary=4, the stack would be aligned on a 16-byte
boundary (the default). On the Pentium and Pentium Pro targets, stack
doubles should be aligned on 8-byte boundaries, but the Pentium III
performs better with 16-byte alignment.
</quote>



The conundrum, is that for structures that contain combinations of
doubles and other types, then there will be a larger memory consumption.


Consider for example a structure such as:

      class A
      {
      private:
         char    foor;
         double  bar;
      };


with the flag -mno-align-double (the default) this will use 12 bytes,
versus 16 bytes that will be used when -malign-double is set.
(measured with sizeof(A)).


We still have not answered the fundamental question:

    Why is that the presence of a non-virtual destructor
    changes the alignment ?



     Luis


------------------------
Tom Vercauteren wrote:
> Hi,
> 
> Thanks for your tests, it's great to have see such reactivity!
> 
> Below is another test that will show the performance hit. You don't
> need to recompile ITK to use it. What we did was to run a simple loop
> on an C array of FixedArray. Then we hack around to get an 8 byte
> aligned C array of FixedArray and run the loop again.
> 
> In this case, the performance hit is clearly not as large as the one
> we get in the real world case but is still large enough to be
> conclusive.
> 
>    Initial alignment: 4
>    Initial execution time: 920ms
>    New alignment: 0
>    Execution time: 880ms
> 
> Let me know what it gives on your setup.
> 
> If the destructor is not implemented you would get ( Initial
> alignment: 0 ) and the same timing results.
> 
> Tom
> 
> 
> 
> #include <iostream>
> #include <itkFixedArray.h>
> 
> int main()
> {
>    // Define the number of elements in the array
>    const unsigned int nelements = 10000000;
> 
>    // Define the number of runs used for timing
>    const unsigned int nrun = 10;
> 
>    // Declare a simple timer
>    clock_t t;
> 
>    typedef itk::FixedArray<double,2> ArrayType;
> 
>    // Declare an array of nelements FixedArray
>    // and add a small margin to play with pointers
>    // but not map outside the allocated memory
>    ArrayType * vec = new ArrayType[nelements+8];
> 
>    // Fill it up with zeros
>    memset(vec,0,(nelements+8)*sizeof(ArrayType));
> 
> 
> 
> 
>    // Display the alignment of the array
>    std::cout << "Initial alignment: " << (((int)vec)& 7) << "\n";
> 
>    // Start a simple experiment
>    t = clock();
>    double acc1 = 0.0;
>    for (unsigned int i=0;i<nrun;++i)
>    {
>       for (unsigned int j=0;j<nelements;++j)
>       {
>          acc1+=vec[j][0];
>       }
>    }
> 
>    // Get the final timing and display it
>    t=clock() - t;
> 
>    std::cout << "Initial execution time: "
>              << (t*1000.0) / CLOCKS_PER_SEC << "ms\n";
> 
> 
> 
> 
> 
>    // We now emulate an 8 bytes aligned array
> 
>    // Cast the pointer to char to play with bytes
>    char * p = reinterpret_cast<char*>( vec );
> 
>    // Move the char pointer until is aligned on 8 bytes
>    while (((int)p)%8) ++p;
> 
>    // Cast the 8 bytes aligned pointer back to the original type
>    ArrayType * vec2 = reinterpret_cast<ArrayType*>( p );
> 
>    // Make sure the new pointer is well aligned by
>    // displaying the alignment
>    std::cout << "New alignment: " << (((int)vec2)& 7) << "\n";
> 
>    // Start the simple experiment on the 8 byte aligned array
>    t = clock();
>    double acc2 = 0.0;
>    for (unsigned int i=0;i<nrun;++i)
>    {
>       for (unsigned int j=0;j<nelements;++j)
>       {
>          acc2+=vec2[j][0];
>       }
>    }
> 
>    // Get the final timing and display it
>    t=clock() - t;
> 
>    std::cout << "Execution time: "
>              << (t*1000.0) / CLOCKS_PER_SEC << "ms\n";
> 
> 
> 
> 
>    // Free up the memory
>    delete [] vec;
> 
>    // Make sure we do something with the sums otherwise everything
>    // could be optimized away by the compiler
>    return acc1+acc2;
> }
> 
> 
> 
> On Thu, Jun 5, 2008 at 5:04 PM, Gert Wollny <gert at die.upm.es> wrote:
> 
>>Am Donnerstag, den 05.06.2008, 10:24 -0400 schrieb Luis Ibanez:
>>
>>>Hi Gert,
>>>
>>>Thanks for the quick report !
>>>
>>>It makes sense that -g flag will prevent the method
>>>from being optimized away.
>>>
>>>If you have a chance,
>>>could you please test what happens when no -g is
>>>used, and the optimization flag is set to -O3 ?
>>
>>It was not be optimized away, and valgrind/kcachegrind tells me  the
>>destructor is located in libITKCommon.so.
>>
>>Actually, with -O3 the whole loop was optimized away. This is wired, to
>>say the least, because, if the compiler doesn't see the implementation
>>of the constructor and the destructor and uses the explicitly
>>instanciated one, it can not know whether there is done something
>>essential in one of the both, like changing a global variable.
>>
>>I've added some code to force the loop (attached).
>>
>>BTW: I think -g doesn't change the optimizers at all (with g++).
>>
>>Best
>>
>>Gert
>>
>>
>>
>>
>>
> 
>