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!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: How to get Ada to ?cross the chasm?? Date: Fri, 11 May 2018 12:04:50 +0200 Organization: Aioe.org NNTP Server Message-ID: 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> <871sejyp8d.fsf@nightsong.com> NNTP-Posting-Host: MyFhHs417jM9AgzRpXn7yg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.3 Xref: reader02.eternal-september.org comp.lang.ada:52261 Date: 2018-05-11T12:04:50+02:00 List-Id: On 11/05/2018 03:07, Paul Rubin wrote: > "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. Algol 60 and 68 considered different languages. > Sure Python programs have bugs, I mean Python itself. It took a lot of time for me to work around issues with about half of Python API not working. Therefore my projection is that whatever they measured could possibly be not working, or doing not the things they thought, or maybe never existed in first place. Sorry for a bit of Python bashing in response to Ada bashing... (:-)) >> 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? All logically connected lists. Let you write a compiler and allocate some intermediate stuff in a bunch of lists. After the phase end you just drop the storage pool they live in and be done with that. >> 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. As I said, it is a difficult and interesting methodological problem. And any results from 90's can be safely ignored because new multi-core architectures make it hugely different (I don't say worse or better, but different). > 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. That would be statically known types. Which is very different from statically known objects. And even with statically known types the pointers might be not statically known: type My_Integer (Indirect : Boolean := False) is record case Indirect is when True => Reference : access Integer; when False => Value : Integer; end case; end My_Integer; -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de