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: Tue, 7 Apr 2015 14:07:03 -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> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1428433624 28500 24.196.82.226 (7 Apr 2015 19:07:04 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 7 Apr 2015 19:07:04 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:25453 Date: 2015-04-07T14:07:03-05:00 List-Id: "Paul Rubin" wrote in message news:87oan0aote.fsf@jester.gateway.sonic.net... > "Randy Brukardt" writes: >> GC overhead (and the corresponding allocation overhead) would be a lot >> more than the combination of free chaining and static allocation ... > > GC doesn't use that much of the runtime of typical programs Given that there is no such thing as a "typical program" when it comes to memory management, that's a meaningless statement. The memory management patterns in a compiler, for instance, are wildly different than in a web server. (Having written both, I have some practical experience there. :-) The real-time systems that Ada customers build are very different from both. > in GC'd languages, and the cpu overhead can be made quite small with > generational gc's. And this isn't remotely the major expense, so that's just a case of optimizing the wrong thing. > There is no allocation overhead (just bump a pointer) And this is bogus. Either items are collected in place, which means that you have to allocate from fragmented memory (a lot of more expensive than "bumping a pointer" - that was the cause of the issues we had with our compiler back in the day), or they're compacted somehow. And compaction is very expensive, simply because copying things around for no reason is expensive. (Ada 2012 has to add access-in-place operations to the Ada Containers specifically to eliminate that overhead.) > and no overhead of freeing garbage. There is some overhead > from tracing and copying the recently created live data (minor > collections, the amount of data touched is usually small) and occasional > more expensive major collections (they also trace older data). This > does have a cost in memory footprint but the cpu load isn't that big. And this is what is complete fantasy. Being able to trace objects requires keeping a lot of extra information at runtime. Keeping enough information to allow runtime debugging slows down our code 5-10% (it makes calls to small subprograms much more expensive). You'd need that and more to be able to do any sort of trace. And I'm dubious about the supposed cost of those traces. Our compiler uses a lot of pointers; most of them act as handles and aren't actually dereferenced in the majority of the code, but they do get passed around a lot. That means a lot of copies of pointers, so lots of data structures to trace. Randy.