Greg Funaro <Gregory.Funaro@hsv.boeing.com> writes:
> Date: Fri, 2 Jul 1999 16:33:49 GMT
> Organization: The Boeing Company
>
> Thanks,
> ...
> You do answer my question with your fourth paragraph ( see below).
> Apparently "fasl" files as they are refered to in Allegro and MCL are
> saved images. This, I do know, poplog provides through clisp %nort
> mkimage or equivalently pop11 %nort mkimage <image name> clisp.
There's a lot of information in the pop11 HELP MKIMAGE library, and
various sample scripts for making saved images in
$usepop/pop/com/mk*
also here at Birminhgam
ftp://ftp.cs.bham.ac.uk/pub/dist/poplog/com/
> The following does bring up the problem I am trying to resolve. Our
> developer is finding that poplog is running slower on a dec alpha than
> on his Macintosh G3 running MCL. Surely, poplog on an Alpha can compete!
I have found poplog on 400 mhz DEC alpha EV5.6 (21164A) processor
is comparable to poplog on 300 mhz Ultrasparc 2 -- faster on some
things because the alpha has a 2Mbyte cache
I have no experience of Macs, but I can't believe Poplog on DEC
Alpha is over 30 times slower!
> Any suggestions on what one can do to speed the executing code.
> Currently the problem set executes in about 2 mins on the Mac. The same
> problem was aborted after an hour on the Alpha. Memory on polog is
> (setf *max-store-size* nil) which I believe tells poplog to use
> everything it can.
Ah: that can be the source of your problems, plus the fact that on
the DEC alpha poplog uses 64-bit pointers, making compiled code a
little bigger and many data-structures (e.g. lists) twice as large.
Your program may be wasting all its time doing huge amounts of
paging!
I assume the Mac is not a 64 bit machine. 64-bit addressing can be
very useful, but when you are doing lots of symbol manipulation it
can cost you a lot in memory requirements -- or paging and swapping.
However memory prices have droppped so much that this may not be
important. (Maybe not DEC Alpha memory!!)
I am not a Lisp user, but according to HELP STOREUTILS
Assigning nil to *max-store-size* is equivalent to setting it to
the value of *most-positive-fixnum*.
If the program grows so big that it cannot fit into the main memory
available then it can start paging onto disk, and this can turn an
inherently very fast program into one that is very, very slow,
especially if you have a slow disk or slow controller, etc.
To check and fix this you have to some inspired guess-work plus
experimenting.
(a) Run your program without altering max-store-size (or popmemlim)
to see if it runs out of space, then try to find the minimal heap
size in which the program will run. Do this by incrementing the heap
size e.g. in steps of 250000.
These are WORDS not bytes, and on a DEC Alpha each word is 8 bytes, so
those are 2Mbyte increments. Use bigger or smaller increments to find
what you actually need.
(b) While your process is running, if you have "top" or some other
system-monitoring tool available, run it to see how much memory your
program uses and how much is available. If there is spare memory
available you can increase the maximum heap size, but you will need
to be sure that other processes will not start up which force yours
to start paging.
E.g. starting poplog clisp in the above DEC Alpha I found, using
"top":
Memory: Real: 23M/120M act/tot Virtual: 488M use/tot Free: 83M
PID USERNAME PRI NICE SIZE RES STATE TIME CPU COMMAND
4708 aaron 42 0 16M 6299K sleep 0:00 1.20% clisp
So I could easily allocate more heap space.
(c) If you find that the miminum heap space required is so large
that your program starts paging then
1. Buy more memory if you can
2. Turn off the stop-and-copy garbage collector.
In pop-11 this is
false -> pop_gc_copy;
In lisp set *gc-copy* to NIL.
The stop and copy garbage collector is very fast, but it works by
temporarily allocating extra memory of about the same size as your
current heap. In a single pass it copies used stuff to the new area,
then copies it back in compacted form. If the heap is already very
large, the process of copying items between the two areas can
generate a huge amount of paging, which can make the difference
between negligible and intolerable GC times.
If you turn off copying, poplog will use a "shuffling" garbage
collector, which would normally be a bit slower, but can be vastly
faster if it eliminates paging.
3. See if you can benefit by locking the heap.
After you have compiled your main functions and created permanent
data-structures, if you are confident that they will not become
garbage you can force a garbage collection and then lock the heap.
After that the store manager will re-cycle only the non-locked
space, which may be very much smaller. It may then even be worth
reverting to copying GC.
To lock the heap, in pop11
sysgarbage();
sys_lock_heap();
In poplog common lisp (according to HELP STOREUTILS):
(lock-heap)
This can sometimes have an amazing effect on GC times.
BEWARE: if you are using X utilities or other externally compiled
functions, then repeatedly locking and unlocking the heap is not
a good idea, as there seems to be a problem releasing space
between two holes in the heap made by external utilities, so your
heap grows and grows...
I think I reported this bug(?) some time ago, but I don't know if it has
been fixed in the latest version V15.53. It is still in V15.5
Aaron
--
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK
EMAIL A.Sloman AT cs.bham.ac.uk (NB: Anti Spam address)
PAPERS: ftp://ftp.cs.bham.ac.uk/pub/groups/cog_affect/0-INDEX.html
|