From: ····@su-russell.UUCP
Subject: Re: autoload (was: Re: Against the Tide of Common LISP)
Date:
Message-ID: <254@su-russell.ARPA>
Stan Shebs is correct in saying that complex function
inter-dependencies can cause poor paging behavior; however,
autoloading doesn't help this problem one bit. In fact, it can
actually aggravate the problem by paging in many useless objects.
Autoloading is a poor substitute for a good virtual memory system
because the grain size is too large - you generally must load a
complete group of related functions and you must waste time parsing
the binary file format at run time. Virtual memory avoids both of
these problems. I'm only arguing against autoloading in a good virtual
memory system, though.
Many popular operating systems do not have wonderful virtual memory
systems. UNIX, for example, handles large processes so poorly that I
might argue that autoloading *is* a good idea when writing a Lisp to
run on it.
Wade
In article <···@su-russell.ARPA> ····@su-russell.ARPA (Wade Hennessey) writes:
>Many popular operating systems do not have wonderful virtual memory
>systems. UNIX, for example, handles large processes so poorly that I
>might argue that autoloading *is* a good idea when writing a Lisp to
>run on it.
Unix? What is a Unix?
Please note that there are many different virtual memory systems
out there, all running under some Unix variant. They may indeed
all be bad, but saying `Unix handles large processes poorly' does
not provide enough information for someone who would be willing
to fix it. Which Unix? (The 4.[123]BSD VM code is generally
acknowledged as overdue for a rewrite. One is in progress, but
I have no details.)
Back to the `main point': autoloading generally gives up time in
favour of space---file system space. One can have umpteen versions
of a lisp binary that all share the same package. In a way this
is much like shared libraries. (If your system does the sharing
automatically, without requiring `autoload's or other helpful hints,
well, that *is* neat.)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP: seismo!mimsy!chris ARPA/CSNet: ·····@mimsy.umd.edu
From: ····@osu-eddie.UUCP
Subject: Re: autoload (was: Re: Against the Tide of Common LISP)
Date:
Message-ID: <3197@osu-eddie.UUCP>
In article <···@su-russell.ARPA> ····@su-russell.ARPA (Wade Hennessey) writes:
>
>Many popular operating systems do not have wonderful virtual memory
>systems. UNIX, for example, handles large processes so poorly that I
>might argue that autoloading *is* a good idea when writing a Lisp to
>run on it.
>
>Wade
No, this is not alltogether true. Unix will handle a very large
program just fine, as long as the memory refrences are not scattered,
but are instead mostly local and/or sequential. The problem here is
that most Lisp implementors are too lazy to carefully watch how there
lisp deals with VM.
One can, of course, give your Lisp a compacting GC, but this opens up
a whole new can of worms, including possibly, reduced GC performace...
-- Paul Placeway
Department of Computer and Information Science
SNail: The Ohio State University
2036 Neil Ave. Columbus OH USA 43210-1277
ARPA: ····@ohio-state.{arpa,csnet}
UUCP: ...!cb{osgd,att}!osu-eddie!paul
-- Paul Placeway
Department of Computer and Information Science
SNail: The Ohio State University
2036 Neil Ave. Columbus OH USA 43210-1277
ARPA: ····@ohio-state.{arpa,csnet}
UUCP: ...!cb{osgd,att}!osu-eddie!paul