🚀 go-pugleaf

In article <10552.9208251648@subnode.aiai.ed.ac.uk>, jeff@aiai.edinburgh.ac.uk (Jeff Dalton) writes:
|> RPG writes:
|> 
|> > I think this concern over dispatch time is insane. It might have made
|> > sense 20 years ago (that is, when C was invented) when computers were
|> > < .1 mips and cost more than 5 years of a hacker's salary, but not
|> > today when computers are > 20 mips and cost 1/5 of a hacker's salary.
|> 
|> I partially agree with this.  I think it would be a mistake to
|> add a bunch of kludgy mechanisms to the language just to speed
|> up dispatch time, for instance.
|> 
|> On the other hand, I don't think the implementors who have put
|> a great deal of effort into speeding up method dispatch have been
|> wasting their time, and I don't think it doesn't matter how much
|> slower CLOS is than C++ or how much slower generic functions are
|> than ordinary ones.
|> 
|> If the difference is only 10-20%, then it's not a problem; but
|> if we're talking small integer factors, that's a different story.

When I was at Gold Hill,  we were able to get much better results than
that.

Gold Hill's CLOS implementation achieved about 50% speedup over a certain
unnamed other Lisp vendor's CLOS implementation by doing smart compilation.
This was tested by running the Gold Hill implementation in the other vendor's
Common Lisp,  which of course precluded using any native optimizations.

The basic idea is to have two modes,  static and dynamic.  When you are
in static mode,  it is assumed that when you compile a method definition,
the class hierarchy that you are inheriting from is static.  Loads of 
optimizations can then be done.

Of course you lose a lot of flexibility doing this,  but you only do it
to create run time applications.  When you want the flexiblity of full CLOS,
use dynamic mode.

This idea came from Bob Strong of Apple Computer,  who wrote the original 
implementation when he was at Cognitive Systems.

Also, with regard to MOP,  you could get rid of the -using-class overhead
at compile time in the same manner.  That way,  you could define metaclasses
that are *more* efficient than standard-class for what you want them to
do.

|> We have some programs here that take, say, 8 hours to process a
|> "realistic" example.  It would make a big difference to cut it
|> to 4.  Sure, we could wait for the next "mini-generation" of
|> machines (which, if recent trends continue, will be about twice
|> as fast) and cut it to 4 hours that way.  But if we can do that,
|> it would be even better to have a faster program and a faster
|> machine and run it in 2 hours.
|> 
|> It also turns out that when we use CLOS we might have to justify
|> this choice to customers.  It will be a lot easier to do this if
|> the time cost isn't very great.
|> 
|> Of course, method dispatch might acount for only a small faction of
|> the total time.  But, in other cases, it's more.  In order to tell
|> when it's "safe" to use generics, we need to know what cost is
|> involved.
|> 
|>