From 8081026737053314776 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: 1014db,9292211c2d4756a8 X-Google-Attributes: gid1014db,public X-Google-Thread: 1108a1,9292211c2d4756a8 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,ee2b84106c640e1b,start X-Google-Attributes: gid103376,public X-Google-Thread: f78e5,9292211c2d4756a8 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1995-01-10 17:44:48 PST Newsgroups: comp.lang.c++,comp.lang.c,comp.object,comp.lang.misc,comp.std.c++,comp.lang.ada Path: nntp.gmd.de!newsserver.jvnc.net!darwin.sura.net!mojo.eng.umd.edu!bloom-beacon.mit.edu!gatech!howland.reston.ans.net!ix.netcom.com!netcom.com!NewsWatcher!user From: hbaker@netcom.com (Henry Baker) Subject: Re: Parallel & RT GC (was Re: Real-Time GC (was Re: Widespread C++...?) Message-ID: Sender: hbaker@netcom.com (Henry G. Baker) Organization: nil 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> Date: Wed, 11 Jan 1995 01:44:48 GMT Lines: 23 Xref: nntp.gmd.de comp.lang.c++:86277 comp.lang.c:74367 comp.object:19511 comp.lang.misc:10339 comp.std.c++:11053 comp.lang.ada:17942 In article <3eua1r$4ea@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar) wrote: > "Is there any work-in-progress by the large chip manufacturers to > design GC into their next-generation CPU architectures? It seems > like the next logical step." > > I sure hope not, I hope we have seen the end of this kind of incorrect > CISC thinking. At most what you want is some very specific hardware > assist instructions that are consistent with RISC instruction design > philosophy Actually, the performance of GC these days is more hindered by cache and VM designs than instruction sets. In particular, GC needs "write-allocate with subblock placement", such as is found on the DEC MIPS machines. I believe that Alphas also have write-allocate, but I'm not completely sure. The Pentium apparently does _not_ do write-allocate, which makes any kind of initialization of untouched memory pretty much of a disaster. Ditto for VM implementations -- people keep talking about 'log-based backing stores', but the major thing that is required isn't so much a log, as the ability to blind write to a page without having to read it first. PLDI'94 and LFP'94 had some good papers on cache issues in GC.