In article <2330@ulogic.UUCP>, hartman@ulogic.UUCP (Richard M. Hartman) writes:
|> In article <CEItLu.3M7@dcs.glasgow.ac.uk> pop@dcs.glasgow.ac.uk (Robin Popplestone) writes a lot of stuff among which I find:
|> >Steve Knight who writes applications for Hewlett Packard reckons that, for
|> >a given effort, he can write a POP-11 program for many applications that
|> >runs twice as fast as the equivalent C. Being able to use appropriate
|> >data-structures for the -problem-, knowing that he does not have to worry
|> >about reclaiming them, a particularly serious problem in an interactive
|> >program that may run ad infinitem, slowly clogging up its virtual memory as
|> >it does.
|>
|> I have yet to be convinced that garbage collection is a requirement
|> for efficient programming. I have never found it difficult to decide
|> when I am done with an object and free() it. Perhaps if you could
|> describe a situation where automatic GC is a requirement, and not merely
|> a convenience it would help me to understand.
If you are a Forth guy, look at Gray, a parser generator written in
Forth. There I use many sets. I allocate them (actually I ALLOT them,
but it would be no difficulty to change that into ALLOCATE), but never
free them. If you can tell me where to insert FREE, I would appreciate
it. The other data structures are also not freed currently, but they
would be easier to free. Release 2 of Gray is at several ftp servers
(ask archie). You can get Release 3 from me, but the changes are
insignificant wrt the problem.
|> Until then, phrases like "knowing that he does not have to worry
|> about reclaiming them" merely imply (to me) a lazy develper who
|> cannot be bothered to figure out when he is done playing with
|> his "toys". This is NOT meant as a slight to Mr. Knight -- merely
|> the biased viewpoint of someone who has been malloc()ing & free()ing
|> for over a decade with very few difficulties who would like to know
|> just what GC can buy me.
This is how I understand the statement: POP-11 programs can be
written faster, and the saved time can be used to make it run twice as
fast as the C program.
Also, note that malloc and free often use a significant percentage of
the runtime of C programs (like 30%). Another (time and space)
overhead is that C programmers copy much data around in order to know
when to free it. In contrast, fast garbage collection costs 3% in a
fast Smalltalk implementation (See Ungar's Ph.D. Thesis), and
Smalltalk usually performs more allocation than C.
Note the followup.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
|