Re: asynchronous task communication

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

On Wed, 02 Jan 2013 11:02:54 -0800, Charles Hixson wrote:

> On 01/02/2013 01:55 AM, Dmitry A. Kazakov wrote:
>> On Tue, 01 Jan 2013 23:36:13 -0800, Charles Hixson wrote:
>>
>>> On 01/01/2013 10:54 AM, Robert A Duff wrote:
>>>> Charles Hixson<charleshixsn@earthlink.net>   writes:
>>>>
>>>>> ...I really preferred a language with a garbage collector,
>>>>
>>>> I have used the Boehm garbage collector successfully with Ada.
>>>>
>>>> You could also consider use-defined storage pools.
>>>> I don't know enough detail of what you're doing to know
>>>> if they would help.
>>>>
>>> I don't think storage pools would help, though I admit I don't
>>> understand them.
>>
>> Storage pools allow implementation of arenas and stacks which are extremely
>> useful when dealing with graphs. I don't know how many nodes you have, but
>> in my system a decision tree might have hundreds of thousands of nodes.
>> Merely finalization of such a structure would take a lot of time if nodes
>> are allocated in the standard memory pool.
>>
>>> Actually, for the current project the need for garbage collection is
>>> minimal...but I often do things where garbage collection really
>>> simplifies memory management.
>>
>> Not really. And for graphs seems just the opposite.
>>
>> Though you would need to carefully design for which graph edges the
>> references will be strong and which ones weak.
>>
>>> Even on this one I'm going to need to
>>> figure out how to recycle memory with Ada.Collections.Vectors attached,
>>> as different cells will connect to differing numbers of other cells.
>>
>> Variable structures like Ada.Containers usually allocate memory in advance
>> to speed up incremental insertions. For NN I would consider a custom
>> fixed-size structure.
>>
>> You might also consider refactoring subgraphs. Structures like that tend to
>> combinatorial explosion when the same graph pattern keeps on repeating
>> itself. Memory use and training/classification times could be reduced when
>> repeating subgraphs are shared rather than replicated. This is another
>> argument to consider a custom implementation.
>>
> A constant size container is not reasonable...though it would certainly 
> make things simpler if it was.

You make node a discriminated record type. Usually when a node is created
it is already known how many children and/or parents it will have. E.g.

   type Node;
   type Node_Ptr is access Node;
   for Node_Ptr'Storage_Pool use Arena;
   type Node_Ptr_Array is array (Positive range <>) of Node_Ptr;
   type Node (Children_Number : Positive) is record
       Successors : Node_Ptr_Array (1..Children_Number);
   end record;

> But I really can't see how storage pools 
> would help, as cells would not be freed in any predictable pattern, and 
> not en-mass.

You allocate all graph or a layer of in the storage pool. Nodes are usually
allocated in the LIFO order which makes allocation much more efficient then
allocation in a standard pool. Deallocation is usually all-at-once, e.g.
you drop the pool and that is.
 
> P.S.:  Is there any way to generate documentation for Ada, better than 
> robodoc?

By hands. I write docs manually. It is tedious, I admit. Consider it as an
extra code review step, helps finding inconsistencies and gaps which
otherwise slip through.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de