How good is Lispworks CLOS compared to other implementations, for a
big complicated project? If I spend a year doing CLOS development
with Lispworks, how likely am I to spend a significant part of that
year dealing with unexpected limitations and quirks of the
implementation?
··········@mailandnews.com (Software Scavenger) writes:
> How good is Lispworks CLOS compared to other implementations, for a
> big complicated project? If I spend a year doing CLOS development
> with Lispworks, how likely am I to spend a significant part of that
> year dealing with unexpected limitations and quirks of the
> implementation?
There's something really strange about the phrasing of this question,
as if someone has told you to expect something strange. Or do you always
go into a new implementation with this attitude? Weird...
Anyway, I've always found it to be highly competent on things that
matter to me. That's not a warranty, of course. Just a free personal
opinion, worth what you've paid for it.
I'd be surprised but interested to know if you'd heard otherwise (as
your wording suggests), as well as where you heard it and specifically
what was said...
[I have only one standing gripe with it and that's that it doesn't
error-check its arguments to MAKE-INSTANCE (at least in LWW 4.1.20,
though the bug is long-standing), and so sometimes if you misspell an
init keyword, a slot doesn't get initialized that you wish would, and
it's sometimes hard to track down. I've recently re-reported this (my
first time reporting it as a customer instead of an employee--I'm
hoping somehow that being on the outside will help up its priority. :-)
I've not heard back from them on this one, but am crossing my fingers
they'll get to it before the next release...]
> [I have only one standing gripe with it and that's that it doesn't
> error-check its arguments to MAKE-INSTANCE (at least in LWW 4.1.20,
> though the bug is long-standing), and so sometimes if you misspell an
> init keyword, a slot doesn't get initialized that you wish would, and
> it's sometimes hard to track down. I've recently re-reported this (my
> first time reporting it as a customer instead of an employee--I'm
> hoping somehow that being on the outside will help up its priority. :-)
> I've not heard back from them on this one, but am crossing my fingers
> they'll get to it before the next release...]
Speaking of which, is there any schedule for a new release? Not that
the current one is missing anything I need, I'm hoping the
documentation becomes a bit more detailed.
Gregm
Fernando <···@wanadoo.es> writes:
> On 21 Jul 2001 08:41:24 -0400, Greg Menke <··········@mindspring.com> wrote:
>
> >Speaking of which, is there any schedule for a new release? Not that
> >the current one is missing anything I need, I'm hoping the
> >documentation becomes a bit more detailed.
>
> And a syntax-highlighting editor. :-)
Especially one with an off-switch. :-)
Fernando wrote:
> On 21 Jul 2001 08:41:24 -0400, Greg Menke <··········@mindspring.com>
> wrote:
>
>
>>Speaking of which, is there any schedule for a new release? Not that
>>the current one is missing anything I need, I'm hoping the
>>documentation becomes a bit more detailed.
>
> And a syntax-highlighting editor. :-)
I've heard some whispering that you _can_ hold your breath... :-)
ciao,
Jochen
--
http://www.dataheaven.de
Kent M Pitman <······@world.std.com> wrote in message news:<···············@world.std.com>...
> as if someone has told you to expect something strange. Or do you always
> go into a new implementation with this attitude? Weird...
I have been programming for decades, and have learned to expect that
anytime I start a major project with an unknown development
environment I can expect to spend a significant fraction of my time
working around the bugs and quirks of that environment.
I know Lisp has been used so much for so many years that the major
development environments have become very refined. But how much does
that apply to sophisticated usage of CLOS? Bugs get fixed because
they cause problems for large numbers of programmers. But how many
programmers have done really sophisticated projects with CLOS in past
years, where they were stretching it to its limits?
I also have a question about speed. I'm concerned that if I use
particular combinations of features, such as multimethods in a big
class hierarchy with lots of multiple inheritance, I might at some
point discover that some particular combination of features gets
caught in an unknown quirk of the implementation, causing it to be
orders of magnitude slower than it should be. Is this a legitimate
concern, or are there some specific reasons why I should not worry
about it?
··········@mailandnews.com (Software Scavenger) writes:
> Kent M Pitman <······@world.std.com> wrote in message news:<···············@world.std.com>...
>
> > as if someone has told you to expect something strange. Or do you always
> > go into a new implementation with this attitude? Weird...
>
> I have been programming for decades, and have learned to expect that
> anytime I start a major project with an unknown development
> environment I can expect to spend a significant fraction of my time
> working around the bugs and quirks of that environment.
Hmm. I won't deny you sometimes do this, but I haven't personally
found that commercial implementations make this a major part of my
day...
> I know Lisp has been used so much for so many years that the major
> development environments have become very refined. But how much does
> that apply to sophisticated usage of CLOS? Bugs get fixed because
> they cause problems for large numbers of programmers. But how many
> programmers have done really sophisticated projects with CLOS in past
> years, where they were stretching it to its limits?
I think CLOS has been put to some pretty bizarre uses. My own uses tend to
be pedestrian compared to what I've seen some people do. The presence of the
MOP invites people to really push on things.
Bugs often get fixed, by the way, because someone takes the trouble to
track down a good test case, even if it only happens to one person.
Vendors do have some degree of pride in their work, especially as
regards core functionality.
And although CLOS does a lot of cool stuff for you, very little of it
is really very complicated. Compilation is where I'd expect errors to
creep in, where closures and optimizations and stuff are going on,
but for the fact that that is stressed A LOT and has been for
years, so the bugs in that get shaken out pretty fast, too.
> I also have a question about speed. I'm concerned that if I use
> particular combinations of features, such as multimethods in a big
> class hierarchy with lots of multiple inheritance, I might at some
> point discover that some particular combination of features gets
> caught in an unknown quirk of the implementation, causing it to be
> orders of magnitude slower than it should be.
Complicated class hierarchies are not of interest really because dispatch
does not look at the class hieararchy. An effective method is cached per
exact class, so there's a tiny overhead on the first call to a particular
type signature on that generic function if the compiler or loader did not
anticipate that signature and pre-compute one for you.
Multimethods should be no slower and probably faster than you writing the
same code yourself. You may choose not to dispatch off of a certain
argument and so to leave it unspecialized even though you know its class,
and there might be some case in which that's slower, but I'm not sure.
It's a point change to code, though, not something you have to twist your
way out of if it turns out ever to matter.
> Is this a legitimate
> concern, or are there some specific reasons why I should not worry
> about it?
I don't see how this could slow you down more than a constant factor, nor
does it seem likely that a "fix" if you should need one would perturb the
"shape" of your code. All deployed programs end up needing speed tuning,
but it's a bad idea to design around such except algorithmically (which
would not be a vendor issue but a language issue; if it was a vendor issue,
and another vendor was algorithmically faster, the right fix would be a bug
report, not changing your code).
"Kent M Pitman" <······@world.std.com> wrote in message
····················@world.std.com...
> Complicated class hierarchies are not of interest really because dispatch
> does not look at the class hieararchy. An effective method is cached per
> exact class, so there's a tiny overhead on the first call to a particular
> type signature on that generic function if the compiler or loader did not
> anticipate that signature and pre-compute one for you.
Interestingly, I have seen what I believe was this overhead balloon to an
exteme degree. A system I worked on a couple of years ago would take up to
15-30 seconds to execute the first "simple" command of any given type you
gave it after start up. From then on, precisely the same action took around
1-10 seconds. I was told by others this was because of calculating method
look-up tables or something similar. There were 100's (but not 1000's) of
classes and 100's of methods on many of the classes. But this system is
such a tragic combination of brilliance and idiocy that I suppose there
could have been other things at play.
As you point out, this could have been eliviated by pre-computing if the
overhead you describe were the cause. It is a shame no one thought it was a
priority, it was sure a user anoyance and did not help the perception of the
system as quirky, buggy and inefficient.
Coby
--
(remove #\space "coby . beck @ opentechgroup . com")
"Coby Beck" <·····@mercury.bc.ca> wrote in message news:<·······················@typhoon.tampabay.rr.com>...
> I was told by others this was because of calculating method
> look-up tables or something similar. There were 100's (but not 1000's) of
Was it Lispworks? Or what Lisp was it? How well does Lispworks
compare with other Lisps in the speed of calculating method look-up
tables?
"Software Scavenger" <··········@mailandnews.com> wrote in message
·································@posting.google.com...
> "Coby Beck" <·····@mercury.bc.ca> wrote in message
news:<·······················@typhoon.tampabay.rr.com>...
>
> > I was told by others this was because of calculating method
> > look-up tables or something similar. There were 100's (but not 1000's)
of
>
> Was it Lispworks? Or what Lisp was it? How well does Lispworks
> compare with other Lisps in the speed of calculating method look-up
> tables?
>
That was Allegro 5x.
Although Kent took my expression of disappointment to be directed at the CL
standard I was actually under the impression that there was an
implementation dependent remedy for that performance problem, and meant it
was a shame we as developers never addressed it. I recall at my last job,
using Lispworks, puting calls to PRE-COMPILE-COMBINED-METHODS into some kind
of initialization file. I never investigated it in detail, but thought it
had something to do with this or similar issues.
Perhaps I should look it up now... (so much to learn, so little time!)
Coby
--
(remove #\space "coby . beck @ opentechgroup . com")
"Coby Beck" <·····@mercury.bc.ca> writes:
> "Software Scavenger" <··········@mailandnews.com> wrote in message
> ·································@posting.google.com...
> > "Coby Beck" <·····@mercury.bc.ca> wrote in message
> news:<·······················@typhoon.tampabay.rr.com>...
> >
> > > I was told by others this was because of calculating method
> > > look-up tables or something similar. There were 100's (but not 1000's)
> of
> >
> > Was it Lispworks? Or what Lisp was it? How well does Lispworks
> > compare with other Lisps in the speed of calculating method look-up
> > tables?
> >
>
> That was Allegro 5x.
Ahh. And all this time I thought this thread was about LW :-)
> Although Kent took my expression of disappointment to be directed at the CL
> standard I was actually under the impression that there was an
> implementation dependent remedy for that performance problem, and meant it
> was a shame we as developers never addressed it. I recall at my last job,
> using Lispworks, puting calls to PRE-COMPILE-COMBINED-METHODS into some kind
> of initialization file. I never investigated it in detail, but thought it
> had something to do with this or similar issues.
Allegro CL has had precomputation of discriminator functions and effective
methods ("training", if you will) for a long time (almost from the beginning
of our CLOS implementation - in fact, as soon as we discovered that the
learning of these discriminators and effective methods was too slow).
However, we also discovered that most customers did not like to have to
"train" their applications (perhaps there is an innate fear that such
training would become quickly invalidated due to dynamism). Anyway, we
had to also add a "fallback" discriminator, which is slower and more
general than the faster ones, but which eliminates some of the training
effect, and which is still much faster than straight open discrimination.
Such a discriminator is only a fallback, however, and doesn't fire when
training is done, or when method combinations are used other than the
standard-method-combination.
> Perhaps I should look it up now... (so much to learn, so little time!)
It is the best way to get the fastest performance!
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
"Coby Beck" <·····@mercury.bc.ca> writes:
> "Kent M Pitman" <······@world.std.com> wrote in message
> ····················@world.std.com...
> > Complicated class hierarchies are not of interest really because dispatch
> > does not look at the class hieararchy. An effective method is cached per
> > exact class, so there's a tiny overhead on the first call to a particular
> > type signature on that generic function if the compiler or loader did not
> > anticipate that signature and pre-compute one for you.
>
> Interestingly, I have seen what I believe was this overhead balloon to an
> exteme degree. A system I worked on a couple of years ago would take up to
> 15-30 seconds to execute the first "simple" command of any given type you
> gave it after start up. From then on, precisely the same action took around
> 1-10 seconds. I was told by others this was because of calculating method
> look-up tables or something similar. There were 100's (but not 1000's) of
> classes and 100's of methods on many of the classes. But this system is
> such a tragic combination of brilliance and idiocy that I suppose there
> could have been other things at play.
The Lisp Machine had a compile-flavor-methods operator that you could use
to force effective methods for certain types to get pre-computed. It had
a simpler problem because of no multi-methods, but then, user code was
used for subsequent dispatch, so maybe that's worse...
I tried to get a similar feature into CL for efficiency reasons, where you'd
specify the arg signature you wanted precompiled (which is what is hard
for the implementation to guess). It was after feature freeze, and people
voted it down.
Some systems force such pre-computation by calling important methods
to exercise the system before dumping an image. I think the human
body does a similar thing during sleep when it disables all but
rapid-eye-movement in muscular action and then trains the body for
tomorrow's activities by replaying today's disaster with the tiger
numerous times in order to improve the reflex time needed to deal with
its return tomorrow.
> As you point out, this could have been eliviated by pre-computing if the
> overhead you describe were the cause. It is a shame no one thought it was a
> priority, it was sure a user anoyance and did not help the perception of the
> system as quirky, buggy and inefficient.
I'm not the only person who wanted it.
The true shame is that the decision was made by vendors, who were the only
people left in the standards process at the time the decision was made.
The users had all decided the situation was "well in hand" and that hte
vendors would represent their interests. In certain cases, and this was
one, I don't think they did a good job. Don't know if it happened on this
point in particular, but toward the end there was a fair bit of vendors
turning to one another and saying "Hey, this sounds like work I don't want
to do" and others saying "Yeah, yeah...". Outside of the protective umbrella
of the ANSI process, that would sometimes be illegal. But the ANSI process
is designed to take any "other opinions" into account; the fact that there
were no other opinions because users had dropped out makes that protection
less-than-adequate, but at least frees the vendors of concern that they are
unfairly collaborating... at that point they are merely fairly collaborating.
* Software Scavenger wrote:
> I know Lisp has been used so much for so many years that the major
> development environments have become very refined. But how much does
> that apply to sophisticated usage of CLOS? Bugs get fixed because
> they cause problems for large numbers of programmers. But how many
> programmers have done really sophisticated projects with CLOS in past
> years, where they were stretching it to its limits?
Well one fairly sophisticated project implemented with CLOS in many
implementations is large parts of the implementation. Although it's
not really a measure of size worth anything, The default LWW image has
nearly 500 subclasses of STANDARD-OBJECT, out of early 700 total
classes, while ACL (with the IDE loaded to make the comparison less
silly) has nearly 700 STANDARD-OBJECT subclasses out of about 850
total classes. These are quite large systems.
--tim
Tim Bradshaw <···@cley.com> wrote:
>* Software Scavenger wrote:
>
>> I know Lisp has been used so much for so many years that the major
>> development environments have become very refined. But how much does
>> that apply to sophisticated usage of CLOS? Bugs get fixed because
>> they cause problems for large numbers of programmers. But how many
>> programmers have done really sophisticated projects with CLOS in past
>> years, where they were stretching it to its limits?
>
>Well one fairly sophisticated project implemented with CLOS in many
>implementations is large parts of the implementation. Although it's
>not really a measure of size worth anything, The default LWW image has
>nearly 500 subclasses of STANDARD-OBJECT, out of early 700 total
>classes, while ACL (with the IDE loaded to make the comparison less
>silly) has nearly 700 STANDARD-OBJECT subclasses out of about 850
>total classes. These are quite large systems.
Thus one of the application on which I'm working can be considered as semi-quite
large system as it adds 375 classes to the ACL ones :-) . Among them 202
persistent-standard-object subclasses (Allegrostore). Maximum deepness of the
application class hierarchies is 12 (20 if I include the ACL classes). In this
application one class inherits from 8 direct superclasses (1 main class, 6 mixin
classes and the persistent-standard-object Allegrostore class). It's common that
a class inherits from 3 to 4 other classes. I make a heavy use of before and
after methods. Multi-methods are less frequent. Most of the persistent classes
are defined on my own persistent meta-classes.
--
www.algo.be
Logo programming : www.algo.be/logo.html
Fernando <···@wanadoo.es> wrote:
>On Thu, 26 Jul 2001 16:37:26 +0200, Francis Leboutte <··········@algo.be>
>wrote:
>
>
>>Thus one of the application on which I'm working can be considered as semi-quite
>>large system as it adds 375 classes to the ACL ones :-) . Among them 202
>>persistent-standard-object subclasses (Allegrostore). Maximum deepness of the
>>application class hierarchies is 12 (20 if I include the ACL classes). In this
>>application one class inherits from 8 direct superclasses (1 main class, 6 mixin
>>classes and the persistent-standard-object Allegrostore class). It's common that
>>a class inherits from 3 to 4 other classes. I make a heavy use of before and
>>after methods. Multi-methods are less frequent. Most of the persistent classes
>>are defined on my own persistent meta-classes.
>
>
>What kind of app is it? Just curious. O:-)
It helps engineers to design and plan electrical networks (any tension). On my
WEB home page there is a screen capture of the application showing a database
made for a project in Mauritius Isle. In the fisheye window you can see the
contour of the Isle. alas I haven't been sent there with the software!
--
www.algo.be
Logo programming : www.algo.be/logo.html
* Software Scavenger wrote:
> How good is Lispworks CLOS compared to other implementations, for a
> big complicated project? If I spend a year doing CLOS development
> with Lispworks, how likely am I to spend a significant part of that
> year dealing with unexpected limitations and quirks of the
> implementation?
I have significant (but not huge) amounts of CLOSy code which runs on
LW and Allegro (LW for windows, Allegro both Windows and Unix, both
current versions). My experience is that they are both extremely
good-quality implementations and are pretty compatible with each
other. I agree with Kent about the non-argument-checking to
MAKE-INSTANCE in LW, and I think that I have found a couple of other
cases where Allegro warns slightly more aggressively, although I am
not sure what they are, and they definitely weren't a major problem in
practice.
Both implementations have pretty complete AMOP-MOP implementations, at
least as far as I've probed.
My impression is that both Allegro and LW have significantly more
heavyweight CLOS implementations than the free implementations I've
used (mostly CMUCL and CLISP). This is not a criticism of the free
implementations.
Both implementations have very good support.
--tim