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!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.ada Subject: Re: How to get Ada to ?cross the chasm?? Date: Thu, 10 May 2018 18:07:14 -0700 Organization: A noiseless patient Spider Message-ID: <871sejyp8d.fsf@nightsong.com> References: <1c73f159-eae4-4ae7-a348-03964b007197@googlegroups.com> <87zi1gz3kl.fsf@nightsong.com> <878t8x7k1j.fsf@nightsong.com> <87k1sg2qux.fsf@nightsong.com> <87h8njmk4r.fsf@nightsong.com> <87po27fbv9.fsf@nightsong.com> <87h8nhwhef.fsf@nightsong.com> <87d0y4zf7d.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="eb6deaf5ebc236909956e29d21385fdd"; logging-data="942"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19fKBsWSfk57Jq8HvYebNB9" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) Cancel-Lock: sha1:0+fqH75cpyu/e8ENHr7YPgyZCRI= sha1:Q/15ZpaTDQFkfb1FI44f4vbxSuI= Xref: reader02.eternal-september.org comp.lang.ada:52237 Date: 2018-05-10T18:07:14-07:00 List-Id: "Dmitry A. Kazakov" writes: > [ Since versions of Python are not compatible and ridden with bugs > there is little use in whatever measurements on its implementation. ] Sorry but I have to notice that every day, far more practical Python code is being written than practical Ada code. Sure Python 3 is incompatible with Python 2, but nowhere near as incompatible as Algol 68 was with Algol 60. Sure Python programs have bugs, but if you're like most people who drive a car to work every day, you accept a nonzero probability that your car won't start because you don't want to pay for an ultra-reliable car built to NASA specifications. Ada in the practical world is an unpopular competitor to Python for similar reasons. Anyway, the observation about locks affecting refcount manipulation timing has nothing to do with the surrounding application. > Low-level lists should not use reference-counting. E.g. I frequently > allocate lists in an arena pool. So you delete all the lists at the same time? What if you have two 5-element lists, (a b x y z) and (c d x y z) where both share the same 3-element tail? You might be finished with the first while wanting to continue using the second. Even if you disallow circular lists, you still probably want something like refcounting. > But measuring GC vs. alternative memory management must be exact and > it is a very difficult problem in itself. It doesn't sound difficult for a short benchmark if you have enough memory. You can turn off GC completely, so when you allocate memory it is never freed until the benchmark finishes. Then the GC time is zero and you can compare the runtime to running the same program with the GC enabled. Although, it might be faster with GC turned on, because of caching. Ben Zorn in the 1990s did a lot of tests where he captured complete execution traces of programs using different GC methods. It should be possible to classify all the primitive operations in a trace and count up the ones that are part of GC. I don't know if he did that though. > That depends on the implementation. I keep the list of weak references > in the object itself, so there is no heap memory involved. Do you mean a count of weak references (along with the count of strong references), or do you chain all the weakrefs together somehow, so you can find them all and invalidate them when the object is freed? > If you can track pointers statically you need no pointers at all. You > just track the objects instead. I mean the compiler knows the memory layout of each datatype, so if the datatype contains pointers, it knows where they are, and it knows the types of the pointed-to objects. That means starting from some known objects with known types, the GC can recursively find all the reachable objects and reclaim the unreachable memory. That's in contrast with conservative GC where the runtime can't necessarily figure out the types of all the objects. Conservative GC is a terrifying concept in theory, but it works surprisingly well in practice. It has been used in Ada in the past.