Subject: Re: How can I make my lisp program executable? From: Erik Naggum <news@naggum.no> Date: 1996/12/21 Newsgroups: comp.lang.lisp Message-ID: <3060172326646405@naggum.no> * Martin Cracauer | There are free Lisps that allow you to save a "real" executable, but the | drawback is of course that the executables may be very big. A solution is | WCL, which uses shared libraries for its Common Lisp library. Don't know | if CLiCC can use shared libs. I have tried WCL. it uses shared libraries for the Lisp system and the executable is indeed small. however, firing up the smallest WCL executable requires 15M of virtual memory (as reported by pstat -s), and starting up CMUCL with a dumped image running the same code requires about 2M of virtual memory, although the disk footprint is at least 10M. this goes to show that if you optimize for the disk footprint, you may get excellent disk footprint statistics, but you won't get any better _system_ statistics unless you have some other common situations, like always having the shared libraries in memory, which is the case for most of the other _actually_ shared libraries on my system (C, X11). just because the disk image is huge doesn't mean the memory image or usage will be. a system designed under the presumtion that it cannot know what you will need until runtime, does not _have_ to waste your system resources with what you won't need until you actually need it. somebody clever enough to find a way to be prepared for those needs at very low cost will have been in thta situation before you. e.g., paging will reduce the startup time of your applications if it can page in only those pages that are actually referenced during initialization and they are few in number. however, if your program needs all of its pages on startup, paging will cost more than it saves. in the same vein, paging will often preallocate the system resources necessary to hold all the memory you might page in, even though you will never need all of them simultaneously. if the pager doesn't know that, however, it can't help you and must be prepared for the worst case. if, however, code is written such that it can be loaded into memory anywhere, you can do your own "paging" and not need to preallocate virtual memory. this appears to be what CMUCL does. many people seem to think that when they can see a problem, nobody has seen it before them and thus it is still unsolved. the converse is often true: people have already solved problems others don't see! and neither will they see them, solved as they are. the joy I find in using a major system, from operating systems and Lisp systems to subway systems and airline ticket reservations systems, is in trying to find as many _solved_ problems as I can. I tend to find unsolved problems here and there, but only after I have gained an appreciation of what has been solved before I ever started to look at it. for instance, it recently became clear to me just how much planning and intelligence is required to ensure that traffic will flow smoothly while a large number of people are at work changing some component of a traffic system, building a major traffic machine, repairing roads, or just plain rerouting traffic after a major disaster. most people curse at the problems they see, but (probably by virtue of not driving myself!) I find pleasure in seeing how some incredibly competent people can keep half a million cars cross a bridge every single day when that brigde is being completely replaced during a whole year of work on it. such things have been an inspiration for me to create software systems that keep running even though they are being repaired. hmmm. sorry for being so unabashedly enthusiastic (I must be annoying a _lot_ of people!), but I'm having too much fun to share it only with my friends and my cat. #\Erik -- "He didn't care." "They never do."