From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,81633e7277ffacee X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!i29g2000prf.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Ada containers and custom allocators Date: Sat, 12 Jan 2008 05:40:31 -0800 (PST) Organization: http://groups.google.com Message-ID: <2d464e2f-b043-4d45-8abd-ca392e92b4f3@i29g2000prf.googlegroups.com> References: <472f2c87-1238-42a5-8b94-92e9b70981da@f47g2000hsd.googlegroups.com> NNTP-Posting-Host: 85.3.224.91 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1200145232 26122 127.0.0.1 (12 Jan 2008 13:40:32 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 12 Jan 2008 13:40:32 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: i29g2000prf.googlegroups.com; posting-host=85.3.224.91; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.0.1) Gecko/20060317 Firefox/1.5.0.1,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:19346 Date: 2008-01-12T05:40:31-08:00 List-Id: On 11 Sty, 23:41, Robert A Duff 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