Recent questions about CLOS

[Moon@STONY-BROOK.SCRC.Symbolics.COM (David A. Moon)]

    Date: Tue, 18 Sep 1990 18:29 EDT
    From: John C. Mallery <jcma@REAGAN.AI.MIT.EDU>

	Date: Mon, 17 Sep 1990 11:24-0400
	From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>

	CLOS and Flavors perform about the same on Ivory-based machines (one can
	find examples that are faster in CLOS and other examples that are faster
	in Flavors, most things are the same speed).

    Does this hold for ordered instance variables in flavors?

CLOS doesn't have any concept of ordered instance variables, so it isn't
possible to compare Flavors with CLOS here.

        I would expect any future additional optimization to be oriented
	towards improving virtual-memory locality rather than raw speed.

    Would this mostly effect system code or would it page in user objects more
    effectively?  

Anything that takes page faults.

    I recall that interlisp (and smalltalk) had some facilities for
    object level paging.  Lenat's Eurisko used this feature in Interlisp.  I
    wonder if it would make sense in CLOS, or would it just add undo overhead.

I think that was just a kludge to compensate for an unreasonably small address
space, not something you would want if you didn't have to have it.

	However, I think this is really a "you tell me" situation.  Customers
	should let us know what their priorities are for CLOS.

    Well, I use inline instance variables (:ordered-instance-variables
    and :readable-instance-variables) for all important instance variables in
    practically all the flavors I instantiate. This to gives me fast instance
    variable lookup.  [Qobi recently timed this kind of IV lookup and found it to
    be faster than defstruct.] I think this would increase my motivation to convert to
    CLOS because it would eliminate the fear of taking a perfermance it.

The difference between those and regular instance variables is pretty small.
Your program would have to be spending most of its time reading and writing
instance variables for it to make a big difference in overall performance.
Ordered instance variables were put in back when the speed difference was
hundreds of microseconds.

    Can I expect to see an equivalent in CLOS in Genera sometime?

The committee that defined CLOS wasn't interested in putting in
optimizations like ordered-instance-variables or compile-flavor-methods.
I don't think we want to put a lot of nonstandard extensions into Genera
CLOS, after all, there's no real reason to convert from Flavors to CLOS
if you aren't going to port your code.  And if you are going to port
your code, nonstandard extensions don't do you any good.  Therefore I
would think the answer is no; this is not a commitment on the part of
Symbolics, of course.

    Now that the XL1200 runs my NLP stuff so fast (10pages/minute), it seems that
    the limiting factor is paging performance -- which seems perfectly reasonable
    on the XL1200 but I have yet to try building really large KBs on it.  I
    suspect running the same application in a lisp under UNIX will not yield the
    non-problematic performance, due to, inter alia, the lack of areas in
    common lisp, and a less effective paging strategy.

    Could you briefly compare paging on the Lisp Machine to ITS to Unix?

    I have some idea of why ITS is better than present UNIX implementations but I
    don't know really why the lisp machine is better than ITS.  It seems that fast
    processor could be meaningless if the operating system does not support
    effective paging for large-scale applications.

Paging performance on ITS was quite poor.  It's just that the entire
address space only had 256 pages in it, so there were limits to how bad
it could get.  You remember paging performance on ITS as good because
back when you were using ITS you were running much smaller programs, and
because your memories of ITS are fond in general.  Did you ever use the
AI KA10 during the day (i.e. between 11am and 4am)?

I don't think there was anything about paging in ITS that worked better
than paging in present day Unix (Unix in ITS's day either didn't have
paging or it didn't work, I forget which).

I'm not aware of much effort at optimizing paging performance in the
Lisps on Unix, mostly they just tell you to buy more memory.  However,
there might be some efforts that I'm not aware of.  Optimizing paging
performance has always been a priority in Genera, since our system is
large, we don't always support the newest and fastest disks, and our
customers seem to be a lot less willing to spend hardware money for
adequately configuring lisp machines than for unix machines (perhaps
with good reason, the unix machine investment can be spread over more
users).  Also of course it's a lot easier for us to do it than for the
unix Lisp vendors, since we control the operating system whereas they
don't control it and need to be portable across a bunch of different
versions of Unix, many of them somewhat brain-damaged.

The only other thing to say is that the XL1200 allows quite large
expansion of main memory, by design, since we know well that a faster
processor means more memory is needed to maintain balanced performance.

	     Across lisp environments?

	Sorry, I can't figure out what this question is asking.

    What problems and limitations would you anticipate for implementations in
    Unix-embedded lisps?

I still can't figure out anything helpful to say in response.  I guess
it's just too broad a question.