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

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

On 11/05/2018 03:07, Paul Rubin wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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