Re: Ada containers and custom allocators

[Maciej Sobczak <see.my.homepage@gmail.com>]

On 11 Sty, 23:41, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:

> Why does it give spectacular performance improvements?
> Doesn't this indicate that the default storage management
> is needlessly inefficient?

Default storage management is always needlessly inefficient, because
it is general and cannot benefit from any additional knowledge about
what will be allocated. Every single bit of additional knowledge is an
improvement opportunity in some area. Fixed-size allocators can use
faster algorithms than general allocators.

Another axis of improvement with custom allocators is thread-safety.
The global allocator cannot assume anything about threading and has to
be defensive in relation to threads, which means that it has to
proactively synchronize everything, always - just in case. Now imagine
you have a container and you know by the design of your system that
this given container will be always used in the context of a single
thread. Why not give it a separate allocator that benefits from this
knowledge (ie. operates on a separate, non-synchronized pool)? On
multicore or multiprocessor systems unnecessary synchronization
(memory barriers and such) is *VERY* expensive and can kill
performance. Why not make things easier for the hardware by reducing
the number of unnecessary membars?
Here, again - every single bit of additional knowledge is an
improvement opportunity.

Related note: it was repeated many times on this groups that Ada is
particularly appropriate for the coming multicore era. I'm not so sure
about this and the above issue is one of the question marks. Forget
about performance if you cannot partition allocation schemes for
containers by threads. This will get only worse as the number of cores
in CPUs increases.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com