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.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f891f,9292211c2d4756a8
X-Google-Attributes: gidf891f,public
X-Google-Thread: 109fba,46882e3fad98420e
X-Google-Attributes: gid109fba,public
X-Google-Thread: 103376,48b89668821c1c9f
X-Google-Attributes: gid103376,public
X-Google-Thread: f78e5,9292211c2d4756a8
X-Google-Attributes: gidf78e5,public
X-Google-Thread: 1108a1,9292211c2d4756a8
X-Google-Attributes: gid1108a1,public
X-Google-Thread: 1014db,9292211c2d4756a8
X-Google-Attributes: gid1014db,public
X-Google-ArrivalTime: 1995-01-17 08:29:13 PST
Path: 
 nntp.gmd.de!Germany.EU.net!wizard.pn.com!sundog.tiac.net!news.kei.com!news.mathworks.com!udel!gatech!howland.reston.ans.net!agate!blanket.mitre.org!linus.mitre.org!spectre!eachus
From: eachus@spectre.mitre.org (Robert I. Eachus)
Newsgroups: 
 comp.lang.c++,comp.lang.c,comp.object,comp.lang.misc,comp.std.c++,comp.lang.ada
Subject: Re: Parallel & RT GC (was Re: Real-Time GC (was Re: Widespread
 C++...?)
Date: 17 Jan 1995 16:29:13 GMT
Organization: The Mitre Corp., Bedford, MA.
Distribution: world
Message-ID: <EACHUS.95Jan17112913@spectre.mitre.org>
References: <787227087snz@wslint.demon.co.uk> <3ckb8g$841@gateway.wiltel.com>
	<1994Dec21.151952.8902@merlin.h
	<19941230.201628.350635.NETNEWS@UICVM.UIC.EDU>
	<3e9f60$8du@jive.cs.utexas.edu> <3epfsi$64d@gamma.ois.com>
	<3eua1r$4ea@gnat.cs.nyu.edu> <3f5vaf$r07@gamma.ois.com>
	<kelvin.790009178@kickapoo>
NNTP-Posting-Host: spectre.mitre.org
In-reply-to: kelvin@cs.iastate.edu's message of 13 Jan 95 14:59:38 GMT
Xref: nntp.gmd.de comp.lang.c++:87643 comp.lang.c:75377 comp.object:19930
 comp.lang.misc:10473 comp.std.c++:11231 comp.lang.ada:18212
Date: 1995-01-17T16:29:13+00:00
List-Id: <comp.lang.ada>

In article <kelvin.790009178@kickapoo> kelvin@cs.iastate.edu (Kelvin Nilsen) writes:

   > By placing the custom hardware within the memory subsystem,
   > we are able to provide the desired benefits without most of the
   > costs of developing special-purpose CPUs.

    There is another major reason for putting the custom hardware in
the memory system.  There is a fairly large class of problems which
require time proportional to n^k lg2 n on any von Neuman architecture,
but can be solved in time n^(k-1) lg2 on hardware which supports
clearing large sections of memory to zero in constant time.  (Note
that if k is one, you can get orders of magnitude improvement.)

     Since many memory systems can support this happy property, all you
need to do to get the faster algorithms is to bypass the OS, or more
politely, have an OS call which clears a section of memory.


					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...