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

[Tom Vercauteren]

Hi,

Thanks all for the very interesting discussion and especially to Brad
for providing an explanation!

I guess that unless we find a solution to the explicit instantiation
issue, we'll have to find another way to handle things. Changing the
implementation of ImportImageContainer::AllocateElements could be a
way to go.

As far as the itkFastMarchingExtensionImageFilterTest is concerned,
this seems to be a Borland only problem...

Sorry if I am not to helpful here, but it went way out of my c++ skills :)

Tom

On Sun, Jun 8, 2008 at 4:25 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>
> Tom,
>
>
> The FixedArray destructor was removed yesterday:
>
> http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/Common/itkFixedArray.h?root=Insight&r1=1.40&r2=1.41
> http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/Common/itkFixedArray.txx.diff?cvsroot=Insight&r1=1.22&r2=1.23
>
> So far, the secondary effects seems to appear in
> the builds that have Explicit Intantiation turned ON:
>
> http://www.cdash.org/CDash/viewBuildError.php?buildid=94739
> http://www.cdash.org/CDash/viewBuildError.php?buildid=94689
> http://www.cdash.org/CDash/viewBuildError.php?buildid=94872
>
> Where the destructor is not found at link time...
>
> It also seemed to affect the test for
> itkFastMarchingExtensionImageFilterTest:
> http://www.cdash.org/CDash/testSummary.php?project=2&name=itkFastMarchingExtensionImageFilterTest&date=20080608
>
>
>
>   Luis
>
>
>
> ----------------
> Brad King wrote:
>>
>> Sorry for the delayed response but I've been away from email all
>> afternoon.  Here is what is going on, using Luis's test case from
>> elsewhere in this thread:
>>
>> class MyArray
>> {
>> public:
>>  MyArray() {};
>>  ~MyArray() {};
>>  double operator[](unsigned int k) { return foo[k]; }
>>  double foo[2];
>> };
>>
>> Since double does not *have* to be aligned at 8 bytes on x86 the
>> alignment of this struct is 4 bytes...WITH OR WITHOUT the destructor.
>> Now consider the code
>>
>>  void* x = new MyArray[2];
>>
>> It's the address to which 'x' points that changes when the destructor is
>> added or removed.  The malloc that is done returns an 8-byte aligned
>> memory buffer in both cases.  It's operator new that adjusts it.
>>
>> When the destructor is present GCC needs a place to record the length of
>> the array so that upon deletion it knows how many times the destructor
>> needs to be called.  Their implementation allocates 4 additional bytes
>> of memory and chooses the first 4 bytes of the resulting buffer to store
>> this count so the data are placed starting at 4 bytes past what was
>> returned by malloc, and that value is stored in x.  Then all the doubles
>> get poorly aligned and performance suffers.
>>
>> When the destructor is not present it does not need to do anything at
>> deletion time but free the memory, so no count is needed and the buffer
>> returned by malloc is used directly.  The doubles end up with good
>> alignment.
>>
>> -Brad
>>
>