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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,8e11100f675ea2df X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.81.40 with SMTP id w8mr11890303wix.0.1357120547686; Wed, 02 Jan 2013 01:55:47 -0800 (PST) Path: i11ni347150wiw.0!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!194.109.133.86.MISMATCH!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!news.stack.nl!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: asynchronous task communication Date: Wed, 2 Jan 2013 10:55:44 +0100 Organization: cbb software GmbH Message-ID: References: <1c2dnd5E6PMDR33NnZ2dnUVZ_sednZ2d@earthlink.com> <50e18094$0$6583$9b4e6d93@newsspool3.arcor-online.net> <7NednS4s2oukfXzNnZ2dnUVZ_oadnZ2d@earthlink.com> <7cudnYloBfQDw3_NnZ2dnUVZ_rKdnZ2d@earthlink.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: cDN0fd8KlIeJLyErIrSf0A.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2013-01-02T10:55:44+01:00 List-Id: 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 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de