Re: gcc-3.4.0: mt_allocator crashes due to alignment problems on SPARC targets when sizeof(type) <= 2

[Brad Spencer <spencer at infointeractive dot com>]

On Tue, May 04, 2004 at 06:42:43PM -0500, B. Kosnik wrote:
> 
> >I will provide further feedback on i386-pc-solaris2.8 when I get there
> >:), and I may be able to try sparc64-sun-solaris2.8, too.
> 
> Ok, thanks.
> 
> I'm really looking for real-world performance feedback. If you have any, I'd be interested.

I don't do too much measurement of small-scale operations like memory
allocation within full-sized applications, but I can at least offer
the results from my relatively naive allocator speed test that I use
to make sure everything is roughly performing correctly.

The simple test takes objects of size 8, 128, and 1024 both with and
without operator new() mapped to the mt_allocator and randomly
allocates and deallocates up to 1, 8, 64, 1024, 8192 and 1048576 of
them. 

The numbers in the table are the number of times faster the
mt_allocator-based operator new() is relative to the default operator
new() on a sparc-sun-solaris2.8 Sun Netra-T1 (a relatively slow box).

                          Number of slots
Size        1       8       64      1024    8192    1048576
----        ------- ------- ------- ------- ------- -------
8 bytes     4.27259 2.40072 2.47618 2.51368 2.28899 2.33543
128 bytes   4.07367 2.99436 2.8585  3.06182 2.73997 2.29598 
1024 bytes  1.06566 0.99703 0.99104 1.06024 1.17302 1.19914

If I set GLIBCXX_FORCE_NEW, then I should see values very close to
1.0.  Strangely, this isn't the case for 1024-byte objects which seem
to not only be about the same speed as mt_allocator, but are actually
_faster_ using mt_allocator's "forced new" than when they just call
new directly.  I can't explain this yet.  The GLIBCXX_FORCE_NEW values
for the same test:

                          Number of slots
Size        1       8       64      1024    8192    1048576
----        ------- ------- ------- ------- ------- -------
8 bytes     0.86418 0.89329 0.84365 0.90939 0.89484 0.94090
128 bytes   0.87358 0.93001 0.94089 0.93079 0.97717 0.96576
1024 bytes  1.13391 1.03313 1.02558 1.09105 1.11196 1.19894

-- 
------------------------------------------------------------------
Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
Systems Architect | InfoInterActive Corp. | A Canadian AOL Company