Re: How to get Ada to ?cross the chasm??

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2018-05-09 23:33, Paul Rubin wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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