Erik Naggum (····@naggum.no) wrote:
: so your AI research supporter (?) was not ill-informed, but what he told
: you was not what you thought you heard. garbage collection hindered the
: acceptance, but garbage collection was not at fault, the _perception_ of
: garbage collection was the actual cause.
Actually, my friend is a system and network administrator. I recently got
the free version of Allegro Common Lisp for Windows, and unless I am
horribly mistaken, I saw it pause for a painful length of time to do garbage
collection. If true, this either means that they are not using superior
algorithms that are well known, or garbage collection is an obstacle after
all. My comment about reference counts was not meant to say "listen to my
new idea", but only to say "even this old idea would be better than having
to endure such long pauses, so what's the deal?"
: | Someone else provided the site info. I'll FTP it.
: it is customary to supplement such vague information with harder
: information if you get it. I would still like to know where it is.
The garbage collection survey is at ftp.cs.utexas.edu, and the file is
/pub/garbage/gcsurvey.ps. It is a Postscript file, and I am forced to
confess that I do not know how to read or print it on my Windows machine.
--
+===============================================================+
| Richard Villanueva | Art and science cannot exist but in |
| San Diego, Calif. | minutely organized particulars. |
| ·····@netcom.com | -- William Blake |
+===============================================================+
In article <···············@netcom.com>, ·····@netcom.com (Richard
Villanueva) wrote:
> Actually, my friend is a system and network administrator. I recently got
> the free version of Allegro Common Lisp for Windows, and unless I am
> horribly mistaken, I saw it pause for a painful length of time to do garbage
> collection. If true, this either means that they are not using superior
> algorithms that are well known, or garbage collection is an obstacle after
> all. [...]
ACL/Windows uses a generational garbage collector. However, the free
version limits total heap space to about 600K! In general, I don't think
GC works well if you push the limits of heap space. Also, ACL takes GC
parameters from an ALLEGRO.INI file -- they may simply be inappropriate
for such a small total heap space.
I use the full version of ACL/Windows, and rarely see (the cursor changes
to indicate GC in progress) a GC pause of more than a fraction of a second
on a Pentium 90.
Dave
--
CPU Cycles: Use them now or lose them forever...
http://www.teleport.com/~dlamkins/
Reference counting doesn't work because there is no way to deal with
circular structures that become garbage. I.e., a->b->a, etc.
Now most modern GC's are generation scavenging so they collect only
recent garbage and ignore old garbage (the heuristic is that only recent
allocations become garbage). This normally works pretty well, reducing
GC times on modern machines to times like 1/10 of a second or less.
It can work poorly, but this is unusual.
: so your AI research supporter (?) was not ill-informed, but what he told
: you was not what you thought you heard. garbage collection hindered the
: acceptance, but garbage collection was not at fault, the _perception_ of
: garbage collection was the actual cause.
Actually, my friend is a system and network administrator. I recently got
the free version of Allegro Common Lisp for Windows, and unless I am
horribly mistaken, I saw it pause for a painful length of time to do garbage
collection. If true, this either means that they are not using superior
algorithms that are well known, or garbage collection is an obstacle after
all. My comment about reference counts was not meant to say "listen to my
new idea", but only to say "even this old idea would be better than having
to endure such long pauses, so what's the deal?"
Allegro CL for Windows uses modern GC methods. I would guess that
if you are seeing big delays you may have not have enough memory and
you are seeing paging problems. 8MB of memory is not enough to
run the full development system (which is what you get in the free version)
very well. You really want 16 MB. If you are seeing problems with
16MB then you may have file I/O problems (e.g., network delays), or
least likely, but still possible, you really are seeing slow GC from
atypical usage of memory.
---------------------------------------------------------------
Jim Veitch Internet: ···@franz.com
Franz Inc., http: //www.franz.com/
1995 University Avenue, Phone: (510) 548-3600
Berkeley, CA 94704. FAX: (510) 548-8253
ACL Unix FAQ: ftp.uu.net:/vendor/franz/faq
ACL Windows FAQ: ftp.uu.net:/vendor/franz/acl4w-faq
---------------------------------------------------------------
In article <···············@netcom.com> ·····@netcom.com (Richard Villanueva) writes:
>Erik Naggum (····@naggum.no) wrote:
>
>: so your AI research supporter (?) was not ill-informed, but what he told
>: you was not what you thought you heard. garbage collection hindered the
>: acceptance, but garbage collection was not at fault, the _perception_ of
>: garbage collection was the actual cause.
>
>Actually, my friend is a system and network administrator. I recently got
>the free version of Allegro Common Lisp for Windows, and unless I am
>horribly mistaken, I saw it pause for a painful length of time to do garbage
>collection.
How long was the painful length of time? How do you even know
it was for garbage collection (rather than, say, for paging)?
If it's because the system printed a message to say it was
garbage collecting, would you have noticed if the message had
not been printed? (Try turning the message off.)
How often does this occur?
How much of the total time was spent in these painful pauses?
I haven't used Allegro Common Lisp for Windows, so I don't know what
its properties are. But I regularly compile moderately large systems
in Lisp without being bothered by gc pauses. I find GC a problem only
when I'm pushing near the limits of what the machine can handle in any
case.
It's true that some programs will spend lots of time garbage
collecting, just as some will spend lots of time paging.
>If true, this either means that they are not using superior
>algorithms that are well known, or garbage collection is an obstacle after
>all.
An obstacle to what?
>My comment about reference counts was not meant to say "listen to my
>new idea", but only to say "even this old idea would be better than having
>to endure such long pauses, so what's the deal?"
How do you know reference counting gives you better performance?
Perhaps you think it's obvious, because reference counting distributes
the collection costs throughout the computation, rather than doing it
all at once in a pause. But many GC algorithms also distribute
the work.
-- jd
Richard Villanueva wrote:
> Actually, my friend is a system and network administrator. I recently got
> the free version of Allegro Common Lisp for Windows, and unless I am
> horribly mistaken, I saw it pause for a painful length of time to do garbage
> collection.
[snipp]
I wouldn't draw the conclusion that the GC was to blame for a long pause when running under Windows.
As far as I am concerned, that pause might just as well be a "feature" from dear Microsoft. :)
Sorry if I'm a bit out of line,
/Jonas
--
------ <<<<<<< ((((((( OOOOOOOOOO ))))))) >>>>>>> ------
Jonas Kvist
Bjornkarrsgatan 13A:13 Phone: +46 (0)13 17 74 28
582 51 Linkoping E-mail: ········@und.ida.liu.se
Sweden URL: http://www-und.ida.liu.se/~c93jonkv/
From: Kelly Murray
Subject: Re: Reference count and GC (was: Re: Why garbage collection?)
Date:
Message-ID: <4e9glf$gs@sparky.franz.com>
> ······@ilog.fr (Bruno Haible) wrote:
> >Jim Veitch <···@Franz.COM> wrote:
> > Reference counting doesn't work because there is no way to deal with
> > circular structures that become garbage. I.e., a->b->a, etc.
> This is not true.
Yes it is, unless you consider the "way to deal" with it is
add another algorithm beside reference counting...
> Here is an algorithm which performs garbage collection of circular
> structures in a reference counting system....
> The references which are stored outside the heap (on the stack etc.)
> are called the roots. At the beginning of a GC, all objects which
> are referenced by roots have to be marked. Instead of scanning the
> roots (which may be highly unportable in a C or C++ environment),
> we count the references from within the heap to a specific object,
This is not reference counting --- you're adding a mark-n-sweep
phase to the GC, where the mark is another reference count.
-Kelly Murray ···@franz.com http://www.franz.com
Jim Veitch <···@Franz.COM> wrote:
>> > Reference counting doesn't work because there is no way to deal with
>> > circular structures that become garbage. I.e., a->b->a, etc.
I replied:
>> This is not true.
Kelly Murray <···@franz.com> says:
> Yes it is, unless you consider the "way to deal" with it is
> add another algorithm beside reference counting...
> ...
> This is not reference counting --- you're adding a mark-n-sweep
> phase to the GC, where the mark is another reference count.
Viewing it this way, you are right. Of course the traditional, unmodified
reference counting scheme is not able to reclaim circular structures.
If I misunderstood Jim Veitch's point, I happily eat my words.
My point was just that reference counting and mark-n-sweep can be combined.
Bruno Haible email: <······@ilog.fr>
Software Engineer phone: +33-1-49083585