Re: [RFC] allocator reorg

[Benjamin Kosnik <bkoz at redhat dot com>]

This patch is in.

>However, I would like to emphasize the point that there should be an 
>easy way to make the __mt_alloc allocator the default allocator when 
>running on SMP machines. I currently patch stl_alloc.h to typedef 
>__mt_alloc as __alloc.

I also would like a better way to select the default underlying
allocator. One of the goals of the re organization was to put all the
underlying allocators on an even footing, which should make switching
between them easier (from a build/configure) point of view.

After this patch is in, I'll think a bit more about this.

I'd thought that maybe, at configure/build time, a "default_allocator.h"
should be constructed, which would contain the __alloc typedef.

Anyway. Another idea would be to set allocators dynamically on the fly
(either by macros in default_allocator.h) or some other shenanigans. The
problem with this is that there is no equivalence between two classes
with different allocators.

>As you probably know, due to it's global lock the runtime behavior of 
>the (standard) __pool_alloc on Intel SMP machines is next to unusable. I 
>tried to use it with a multithreaded server application on a Quad PIII 
>SMP machine, but it was more efficient to simply switch off 3 of the 4 
>CPUs. If you'd like me to, I can run some tests again and send you the 
>results. It should be noted that parts of the bad performance were due 
>to an inefficient capacity strategy in the basic_string implementation, 
>see my other today mail on a solution for that.
>
>With __mt_alloc, performance was linear and stable.

Switching the default allocator to __mt_allocator should be discussed,
but let's get it in first, ok?

>In my perception, the standard library itself should decide which 
>allocator suits best to its runtime environment, if there is no explicit 
>declaration by the programmer. Therefore, I do not really like the 
>GLIBCPP_FORCE_NEW switch (or an extension to MT_ALLOC), as it leaves the 
>allocator decision to the user of an application, not even to the 
>programmer. This may be the worst scenario.

Well, GLIBCPP_FORCE_NEW is really for debugging purposes. Something like
this is really necessary.

>The linux pthread lib uses something like the following code to 
>determine if it runs on an SMP kernel. I have no idea how portable the 
>sysctl() call is, the parsing of the version string as last resort 
>definitely isn't portable. However, with something like this the 
>libstdc++ could find out if it runs on SMP, and in that case delegate 
>calls to the standard allocator to __mt_alloc, which would always 
>guarantee a better runtime behaviour than using __pool_alloc.

Very interesting. Maybe this is what should be done.

In any case, it looks like there will have to be a configuration step
for the allocators.

-benjamin