fischer@arisia.Xerox.COM (Ronald A. Fischer) (03/17/89)
You were comparing the *performance* of one lisp function run in both images, and then comparing the total size of each image. This doesn't seem quite the right way to do it. How about also looking at the size of the compiled function itself in both Lisps? As well as the memory usage. Speed versus space. Let's take a look at the bigger picture. ENVOS Lisp has taken a commercially difficult speed/space tradeoff. Its always easier to say you're faster than the competition on a few tightly constrained benchmarks, but what has the cost of this been? Ultimately it has caused the Lisp vendors to emphasize speed over all else. The result has been incredibly memory hungry implementations. Of course, hardware vendors love these sort of tendencies. By using a compiler that generates bytecodes at the bottm layer of the system ENVOS has a highly portable, but rather slow Lisp. Code size for any function is small, and remember that one of Lisp's major failings is its space use. ENVOS Lisp also uses CDR coding for lists, another speed slowdown that shrinks the size of the resulting memory image.r For some of the highly optimized native Lisps the code and data memory use is enormous. This affects swapping. For a large lexical analysis application that runs at Xerox PARC an experiment was performed: run the application in ENVOS Lisp and "another popular brand." The other Lisp compiled native machine code for the Sun 4. ENVOS Lisp was initially slower, but as the run continued for the three days that it normally takes to complete, the other lisp swapped itself to death (it crashed) and the ENVOS Lisp image ran to completion. As regards the size of the ENVOS Lisp image, again, bear in mind what's really in there. Most lisps are really just a runtime, an interpreter, a compiler, and a few trivial debugging tools. Lisp's vaunted prototyping ability has been more based on the language's traditional inclusion of an interpreter and its dynamic typing than any particular set of tools that are always provided. A few of the other lisps may have been around long enough to get an editor interface and maybe some good hooks into the operating system's window toolkit. ENVOS Lisp includes in its basic image such things as a window based structure editor that dynamically prettyprints code depending on window size, various proramming utilities including a system for tracking residential definitions, a window system, an operating system, a complete toolkit for building applications including a very clever grapher, remote debugging facility a la what the C people currently call a debugger, a *real* debugger with window interface, etc. There's alot of stuff in there which drives the size of the image up, but not because the compiled functions are enormous, rather because there's alot of functionality in there. You may also optionally load in our document editor (TEdit), Bitmap editor, structured graphics editor (Sketch) or applications like NoteCards or Rooms. ALL of these have programmer's interfaces as well so that they can be used to decreases application develpment time. ALL of these are also integrated tightly with one another using "imageobjects" a concept similar to what HP is now selling as "New Wave" and which Apple and Microsoft may someday get into their systems. All of this stuff originally came out of the clever folks at Xerox PARC, and its an amazing and very useful set of tools. I've also not touched on the basic problem that many highly optimized Lisps will now produce "unsafe" code, i.e. it will crash your Lisp image or worse operating system if simple errors occur. This has traditionally been another major Lisp advantage, one whose importance has been de-emphasized in the race for improved speed. ENVOS Lisp always produces "safe" code. Most other Lisps can too with appropriate compiler settings, but compare the resulting code size and speed under these settings too. Many checks are built into the ENVOS bytecode that will need to be explicitly coded otherwise. So, please be careful in how you benchmark. Consider size of the resulting function as well as its speed. Consider how "safe" the highly optimized code is. Consider the amont of memory needed to store your data. Consider how much shorter your development time might be with a better set of development tools or application toolkit. And finally, as a fellow Lisp developer, I wish you the best of luck in this volatile and small marketplace. (ron) Ron Fischer ENVOS Corp. Project Manager PS- These views are my own but are likely to be shared by others, I hope.
karp@SUMEX-AIM.STANFORD.EDU (Peter Karp) (03/20/89)
Hi, Your recent message was very interesting. I wonder if you know the answer to the following: does ENVOS plan to incorporate true multiprocessing into their Lisp? This has been one of my biggest complaints about Interlisp for years. Peter
karp@SUMEX-AIM.STANFORD.EDU (Peter Karp) (03/20/89)
My apologies for sending that reply to the entire list. Apparently the maintainer of this mailing list has set things up so that by default replies go to the entire list. This is a non-standard practice that could lead both to waste material on the mailing list, and to embarrasement for message senders. I hope the practice will be changed. While I'm at it, why don't we rename this list to INFO-INTERLISP ? Peter
mikel@apple.com (mikel evins) (03/22/89)
In article <654@arisia.Xerox.COM> fischer@arisia.Xerox.COM (Ronald A. Fischer) writes: > Consider how much shorter your development time > might be with a better set of development tools or application > toolkit. I won't claim that Allegro CL on the Mac has the richness of a Symbolics or Xerox Lisp machine; I've had my hands on a Symbolics and on TI machines (though, regrettably, not a Xerox), and I know something of what I'm missing. I will say, though, that, for a personal computer, or microcomputer, Allegro is a very nice programming environment. Yes, it has gc, it has a nice windowing debugger with a view of the execution stack, and inspectors for all kinds of variables, including system variables not visible in most Mac programming environments; it is very well integrated with the Mac interface toolbox. In short, for a personal computer (as opposed to workstation) implementation, it's pretty nice, and real fast, and quite robust, so far as I've seen so far, though not yet a match for Lisp machines. Just thought I'd put in a good word for the underdog. (I hope the identity of my employer won't bias readers with regard to my integrity; I liked Allegro CL a long time before I had any idea Apple was going to buy Coral).