Hi,
when at school, I work on a pretty quick machine, but many people
share it, and so I try to be nice in terms of memory usage. I have
found that lisp-listeners in ACL are very efficient in terms of
sharing memory. That is, if I need to run a large Lisp process and
would like to have about 15 Meg of memory loaded into the Lisp
interpreter (i.e. data) then running two separate Lisp processes would
be about 40 Meg. but I've found that w/ Lisp Listeners, I can start a
new listener, and instead of incurring another 20 Meg, I only incur
about 3 Meg. that's great! Obviously, I'm asking for twice as much
work to be done. so what I want to know is whether or not the amount
of time it'll take till both processes end is also (about) twice as
long. In other words, I'm asking if this lisp listener thing is
efficient enough that running two listeners in || will cut timewise
performance in 1/2 (which would be great). The other possibility is
that although the shared memory is obviously very efficient (only 3
Meg out of 20 was duplicated after a ``fork''), the scheduling is done
poorly so that the two tasks slow down by more than a factor of 2.
dave
* David Bakhash wrote:
> Obviously, I'm asking for twice as much
> work to be done. so what I want to know is whether or not the amount
> of time it'll take till both processes end is also (about) twice as
> long. In other words, I'm asking if this lisp listener thing is
> efficient enough that running two listeners in || will cut timewise
> performance in 1/2 (which would be great). The other possibility is
> that although the shared memory is obviously very efficient (only 3
> Meg out of 20 was duplicated after a ``fork''), the scheduling is done
> poorly so that the two tasks slow down by more than a factor of 2.
Well, I think you need to measure this! However, it's likely that --
assuming the memory you save causes the machine to page less (and if
it's not paging, then you don't really need to save the memory, cache
hit rate issues aside), then this will dominate any scheduling
inefficiency, so you'll win.
Of course, it will slow down by a *bit* more than 2, because there
will be *some* scheduling overhead, but this may be small. (And again,
this may not be right if you're on a multiprocessor.)
--tim