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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5cb36983754f64da X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-04-03 16:33:12 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: No call for Ada (was Re: Announcing new scripting/prototyping language) Date: Sat, 3 Apr 2004 18:33:03 -0600 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <106ulu7p0tia13d@corp.supernews.com> References: <20040206174017.7E84F4C4114@lovelace.ada-france.org> <54759e7e.0402071124.322ea376@posting.google.com> <87r7v5zao0.fsf@insalien.org> X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:6735 Date: 2004-04-03T18:33:03-06:00 List-Id: "David Starner" wrote in message news:pan.2004.04.03.22.45.16.627405@email.ro... > On Sat, 03 Apr 2004 11:13:35 +0200, Ludovic Brenta wrote: > > > This turned out not to work that well; there have been large > > performance and memory footprint concerns in GCC because of GC. > > There have been large performance concerns in GCC, but I'm unaware > of them being related to GC, and I don't think many of the memory > footprint concerns are related, either. Of course they're related to using GC. That means that they're not paying much attention to storage management, and that is one of the most important determiners of performance in a compiler. When we original built Janus/Ada, it had to run in very cramped memory. Yet we found that it didn't pay to try to deallocate many things (like symboltable entries). The overhead of deallocation exceeded the extra space made in most programs (for example, less than 5% of the symboltable nodes can be reused in typical programs; usually much less). We also found that the overhead of allocation and deallocation, even though it is pretty small, was taking up a substantial portion of the run-time of the compiler. Replacing that by an allocate-once-and-reuse manager improved the compiler performance a lot without any real impact on memory use. The use of GC certainly wouldn't have helped in any significant way (the memory use turned out *not* to be the issue). For compilers (like a lot of other programs), using GC can make things *easier*, but it can't make them *better* (and it usually will make them worse, since compilers don't generate much garbage to begin with). Use GC doesn't absolve designers of considering storage management (because storage use usually will have a substantial performance impact), but it can (by making it easy) cause them to ignore the area. For the record, I don't see any reason to use reference counts in a compiler, either. I don't believe we have any reference counts in Janus/Ada. Objects are either part of a single data structure that is deallocated at once or are in those parts of the compiler that don't benefit from storage recovery (so we don't try to deallocate them). The no-overhead solution always trumps the some-overhead solution. :-) Randy.