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!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.ada Subject: Re: Languages don't matter. A mathematical refutation Date: Tue, 07 Apr 2015 20:53:57 -0700 Organization: A noiseless patient Spider Message-ID: <878ue3ff6y.fsf@jester.gateway.sonic.net> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="c694756f1077760bb5296aae16c74092"; logging-data="3154"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+kXy7s3/pEwpIiCTgvQe1V" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:og4Y1DLG7uRPFrgOg5vJ0FhUyKA= sha1:M/W5FCTiozJMNJjP3p0hp4rSx08= Xref: news.eternal-september.org comp.lang.ada:25458 Date: 2015-04-07T20:53:57-07:00 List-Id: "Randy Brukardt" writes: >> 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. Take all the actively used programs out there and sort by decreasing percentage of their runtime used by GC. Throw away the top and bottom 10% as outliers and call the other 80% typical. That seems meaningful to me. >> in GC'd languages, and the cpu overhead can be made quite small > And this isn't remotely the major expense, So what is the major expense, and how often should anyone care about it? >> 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. Yes, the idea is to use a copying collector, which compacts, so allocation is just bumping a pointer. I don't claim that the copying/compaction phase has no overhead. But, it is not too bad in practice, for most applications in which GC is usable at all. > And compaction is very expensive, Maybe your info is out of date. Modern gc's use generational copying, so during most collections, only recently created data gets copied, which isn't very much data. There are also larger collections when everything gets copied and that takes longer, but it's less frequent. The aggregate overhead isn't too much. There's tons of heavily used code out there using GC these days, e.g. Gmail is written in Java unless I'm mistaken. They wouldn't have done that if GC was unaffordable. > 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.) That sounds like you're talking about copying in the application and not in the GC. The access frequency could be far higher in the app, increasing the copying costs. > 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. You trace from each pointer just once, either by setting a mark bit in the object in the case of a mark-sweep collector, or by overwriting the pointed-to object with a forwarding pointer in the case of a copying collector. So the number of objects matters much more than the number of pointers. Anyway, look at it like this. If your compiler was written 30 years ago and ran at tolerable speed then, it's 1000x faster now because of advances in hardware. Even if using GC would have slowed it down by 2x, it's still 500x faster than before.