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

[Paul Rubin <no.email@nospam.invalid>]

"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.

> 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.  Obviously anything that potentially required
traversing the list would have a WCET problem.

> 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.

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.

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.

Fwiw I don't see anything in Ada95 Distilled about how to manage weak
references or adjust refcounts automatically, but maybe GNAT has
libraries for that.