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: Thu, 10 May 2018 10:07:52 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <1c73f159-eae4-4ae7-a348-03964b007197@googlegroups.com> <87lgd1heva.fsf@nightsong.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> NNTP-Posting-Host: kQkuQcRDy1QFvWpyB1foYw.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 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 X-Notice: Filtered by postfilter v. 0.8.3 Content-Language: en-US X-Mozilla-News-Host: news://news.aioe.org Xref: reader02.eternal-september.org comp.lang.ada:52194 Date: 2018-05-10T10:07:52+02:00 List-Id: On 2018-05-09 23:33, Paul Rubin wrote: > "Dmitry A. Kazakov" writes: >>> You need locks (at least in the form of atomic instructions >> That is right, but the only penalty you get is probably spilling the >> cache > > Oh ok, yeah, if you meant atomic increments the whole time, that clears > up some confusion. The cache spill cost (around 10 cycles, as posted > elsewhere) is much smaller than software locks, though still much larger > than ordinary arithmetic. As mentioned earlier, the cost of atomic > refcount operations has proved too expensive for Python, though Python > uses refcounts far more extensively than an Ada application likely > would. > > The Python tests of atomic refcount operations were done some years ago > so it might be worth trying them again with present-day hardware, hmm. [ Since versions of Python are not compatible and ridden with bugs there is little use in whatever measurements on its implementation. ] >> Yes, if you have a long chain of references which all go to zero. I >> would argue that this is bad design from the start. > > I don't see the problem with a long chain of references per se: linked > lists are another ancient data structure and there's nothing wrong with > having a long one or managing its storage automatically. That was done > all the time in Lisp. See, if they do that in Lisp it is a good advise to do otherwise! (:-)) Low-level lists should not use reference-counting. E.g. I frequently allocate lists in an arena pool. I also have a list design with all pointers hidden inside the storage pool. >> It is incredibly difficult to estimate the time spent by the clients >> of GC. What is measured is probably the GC task with all distributed >> overhead in the clients and the overhead of the overall design >> uncounted. > > Hmm, this is an interesting claim that I won't say is wrong, but I > haven't heard it before and am surprised by it and am skeptical. I've > always just run the profiler and believed when it said the program was > spending X% of its time in GC. Profiling usually works by sampling the > CPU program counter to identify the busy parts of the code. I don't > know where the other overhead would come from. There's overhead > inherent in using a given data structure (say a search tree instead of a > hash table) but I wouldn't ascribe that to the GC. The GC just makes it > easier to choose that type of structure. I would say that about 80% of all time measurements are plain wrong. The 80% of the rest 20% are subtly wrong. It does not matter much if the measurement is intended for benchmarking, because the relation of two wrong measurements is still right, at least in the sign. Or even in one significant digit, if you are lucky (:-)). But measuring GC vs. alternative memory management must be exact and it is a very difficult problem in itself. > As for weak pointers, it looks like C++ std::shared_ptr/weak_ptr > actually involves two objects in the heap. There's the controlled > object itself, and there's the shared_ptr structure. The shared_ptr > structure contains a pointer to the controlled object, plus the count of > strong references and the count of weak references. When the strong > refcount goes to zero, the controlled object is freed, but the > shared_ptr structure must be kept until both counts go to zero (so that > you can tell whether a weak reference is still alive). If Ada weak > pointers work the same way, this sounds like yet more storage > management, plus there is still the overhead of adjusting refcounts all > the time. That depends on the implementation. I keep the list of weak references in the object itself, so there is no heap memory involved. The weak reference is a limited controlled type, of course. > So I'm still skeptical that this can beat a GC approach, where pointers > are just ordinary machine words that can be copied freely, their types > tracked statically at compile time, and with no atomic operations needed > except while the GC is running. I wonder if there's a reasonable way to > benchmark a comparison. If you can track pointers statically you need no pointers at all. You just tack the objects instead. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de