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=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Languages don't matter. A mathematical refutation Date: Fri, 10 Apr 2015 15:58:04 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <87h9t95cly.fsf@jester.gateway.sonic.net><04f0759d-0377-4408-a141-6ad178f055ed@googlegroups.com> <871tk1z62n.fsf@theworld.com><87oan56rpn.fsf@jester.gateway.sonic.net><877fts7fvm.fsf@jester.gateway.sonic.net><87twwv66pk.fsf@jester.gateway.sonic.net><32ecaopodr1g.1xqh7ssdpa2ud.dlg@40tude.net><87pp7j62ta.fsf@jester.gateway.sonic.net><87pp7hb2xo.fsf@jester.gateway.sonic.net><5rxvgyes5xg8.1mqq86gacbsb1.dlg@40tude.net><87lhi5ayuv.fsf@jester.gateway.sonic.net> <87oan0aote.fsf@jester.gateway.sonic.net> <878ue3ff6y.fsf@jester.gateway.sonic.net> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1428699484 7870 24.196.82.226 (10 Apr 2015 20:58:04 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 10 Apr 2015 20:58:04 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:25510 Date: 2015-04-10T15:58:04-05:00 List-Id: "G.B." wrote in message news:mg8ltb$nql$1@dont-email.me... > On 10.04.15 01:35, Randy Brukardt wrote: >> But how to do tracing without a lot of overhead?? > > One lightweight way of allocating and tracing might be so > dumb that it is not always useful. But I don't know if > it is never useful, or not useful enough to be considered. > The point is to really request memory once, and then to do > almost nothing. Nothing new here (arena pools). Right. Subpools provide a (possibly) better way to manage those. > Imagine a procedure that manipulates a graph. > Or tons of matrices. Or a sequence of short messages. > You need "new T" for the objects(*). > > 1 - require the pool to have enough room for Max objects: > one stretch of storage. Pretty much like any pool. :-) > 2 - make Allocate return the address of the next free > storage element, etc.; remember the then next free > storage element in the pool object. Pretty much like most user-defined pools. I have a pool that does exactly that, although the purpose is to detect valid vs. dangling pointers. > 3 - Deallocate does nothing. Typical in pools that implement subpools; only a subpool deallocate does anything. The mark-release pool example in the RM works this way. > When the region ends, Finalize of the pool frees memory. > So, I guess tracing overhead is one assignment for > keeping track of the next free storage element's address. Right. The subpool version is a bit more flexible, because it allows dumping a bunch of objects at a time (say all of the parts of a single matrix ), without dumping everything. Of course, if you use subpools, you reintroduce the possibility of dangling pointers. One could combine subpools and smart pointers such that dangling pointers are detected, that might be a very appealing combination. That wouldn't have to be very expensive (the expensive part of smart pointers is the implicit finalization, and one wouldn't need it here, at least if you could tolerate someone deallocating a pointer that is actively being used -- not a very likely occurrence), and it could be built in Ada today. Randy.