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

[David Cole]

Very interesting discussion!! Thanks to all who have contributed.

Now, the question is: will the GCC developers use extra bytes in future
releases to record the length of the array to avoid this sort of performance
hit...? (Matching the alignment that the allocator is careful to return
would be a good feature for 'new'...)

I guess Bill was right: Brad's the man.

:-)


On Fri, Jun 6, 2008 at 5:23 PM, Brad King <brad.king at kitware.com> wrote:

> Bill Lorensen wrote:
> > OK, I am way out of my league here, but the difference may be the way
> > POD ("Plain old Data") types and non-POD types handle memory
> > allocation.
> >
> > See:
> http://www.fnal.gov/docs/working-groups/fpcltf/Pkg/ISOcxx/doc/POD.html
> >
> > It may be, that by having a destructor, the class becomes a non-POD
> > class. Without it, it may be a POD class. The POD-ness rules are
> > complex, at least for me.
> >
> > Perhaps Brad King can shed some light on this. These questions are NOT
> > out of his league.
>
> 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
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20080606/ecddc41c/attachment.htm>