Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.object Subject: Re: What is Objective C? Message-ID: Date: 11 Sep 90 15:58:43 GMT References: <3864@bingvaxu.cc.binghamton.edu> <77500056@m.cs.uiuc.edu> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 55 In-reply-to: johnson@m.cs.uiuc.edu's message of 4 Sep 90 22:36:00 GMT On 4 Sep 90 22:36:00 GMT, johnson@m.cs.uiuc.edu said: chisolm> So . . . will a program that, by the language definition, must chisolm> do garbage collection, run as quickly as a program where the chisolm> "user" (the programmer in the language in question) must manage chisolm> memory? Probably not, unless the language implementor has done chisolm> a terrific job, and the "user" has botched it. Probably yes, as others have remarked. Most programmers do not understand performance issues very well, least of all memory management. The greatest bottleneck in computer science is the number of competent system programmers; putting one of them to work on automatic memory management probably results in more efficient programs than putting hundreds of less competent (in the subject of memory management) application programmers to the task of doing memory management themselves. Notice that this applies to *any* kind of automatic memory management, not just garbage collection, which is just one of the techniques. johnson> Although I agreed with most of what Paul Chisholm said, I johnson> disagree with this statement. My experience with C++ is that johnson> memory management takes a lot of CPU time. We use reference johnson> counting, and have to lock objects before changing their johnson> reference count (we are using a multiprocessor). For example, this is *not* necessary in many cases. Since you *must* eventually invoke a garbage collector to reclaim cycles, you can just accept imprecise reference counting, that is counting that misses some count decrements. Or you can use reference count logs, etc... johnson> Not only is this time-consuming for the programmer to get johnson> right, it is time-consuming for the computer to execute. Case in point. The choice between reference counting and garbage collection is not an easy one. For example, Johnson is here restating the well known fact that the overhead of reference counting is proportional to the number of accesses to valid objects and the number/size of garbage objects, while that of garbage collection is proportional to the rate of object generation and the number/size of valid objects. Also, compaction under the two regimes has quite different effects, and so for example is the interaction with virtual memory (simple minded reference counting is very very very very bad under virtual memory). For example, Johnson may/may not be aware that many sophisticated reference counting schemes that substantially reduce reference counting overhead have been published, some designed with special reference to multiprocessors, but I am not sure that the implementation of an efficient multiprocessor reference counting scheme is his main research objective. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk