Thanks,
Aaron Sloman See text for reply address wrote:
> I guess most of us have no idea what a FASL is. I looked it up in
> the index to the Common Lisp manual (2nd edition) and in three other
> books on Lisp and could find nothing.
>
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.
> I have a hunch (I don't know why?) that it refers to an external
> machine-code file produced by the compiler: I understand that in
> some lisp systems the compiler works by producing such a file, which
> can then be linked into the running lisp system. (A corrollary is
> presumably that compiled functions cannot be automatically garbage
> collected?)
> Poplog has never had such a facility for ordinary users, although
> using POPC to rebuild a poplog system involves partially analogous
> processes which create object modules which can then be linked into
> a new poplog. (See HELP POPC, REF POPC).
>
> A saved image is also partly analogous: it has pre-compiled code
> which can start up quickly. (Examples are the saved images for
> Prolog, Lisp and ML). See HELP SYSSAVE, REF SYSTEM
>
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!
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.
Any suggestions.
> Normally, however, the compiler incrementally compiles declarations
> and procedure definitions, modifying some system structures (e.g.
> the dictionary) and creating new executable machine code procedure
> records which are in the heap, and can therefore be garbage
> collected when no longer needed.
>
> The pop-11 incremental compiler (and likewise the poplog lisp
> incremental compiler) is extremely fast, partly because it doesn't
> do as much optimisation as some lisp compilers (e.g. Lucid lisp),
> and partly because the poplog garbage collector is extremely fast
> (compilation generally produces a lot of garbage).
>
> For example, the poprulebase library
>
> ftp://ftp.cs.bham.ac.uk/pub/dist/poplog/prb/lib/poprulebase.p
>
> has over 5000 lines (137Kbytes) of pop-11 code, and probably uses
> several additional autoloadable libraries. On a 300mhz Ultrasparc 2
> it compiles in about 2 seconds in the basic pop-11 image: basepop11
> and some of that time is fetching files from the central file
> server.
>
> /usr/bin/time basepop11 :"lib poprulebase"
> ;;; LOADING LIB poprulebase
>
> real 2.1
> user 1.4
> sys 0.4
>
> It is faster if I use "pop11" instead of basepop11, as pop11
> includes the pre-compiled "startup" image
>
> /usr/bin/time pop11 :"lib poprulebase"
> ;;; LOADING LIB poprulebase
>
> real 1.0
> user 0.4
> sys 0.2
>
> or equivalently:
>
> /usr/bin/time basepop11 +startup :"lib poprulebase"
> ;;; LOADING LIB poprulebase
>
> real 0.9
> user 0.4
> sys 0.2
>
> Putting
> true -> popgctrace
>
> in the library file shows that there are about 190 garbage
> collections, each taking less than 0.01 secs.
>
> By increasing the inital memory allocation
>
> 1000000 -> popminmemlim;
>
> I reduced that to only 2 or three garbage collections, but it made
> no significant difference to the times!
>
> Apologies for digressing.
>
> As machines get faster, the need for precompiled code decreases.
>
> 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
Thanks, again
Greg Funaro
|