On Sun, 17 Feb 2002, Bijan Parsia wrote:

>
> Well, yes and no. From what some folks tell me, DNU based MI was really
> too slow to be of all that much use. Frank Adrian has mentioned to me
> *many* a time his frustration that the MOP facilities in Smalltalk are
> often too weak for *practical* systems...i.e., you need to dig into the VM
> at some point.
>

I've thought of a *very* different caching strategy using zero-cost
invalidation hash tables. IE, as long as you store method source in a
non-relocating GC area, you can invalidate any cache in any object or
method in the whole system with no cost. The idea was to figure out how to
add megabytes or more of specialized methods or method caches into
squeak without paying the invalidation cost on each programming change.

And, for free, the same code can be used as-is for PIC caching..

Unfortunately, it doesn't appear as if thats all that useful, AFAIK, the
method lookup doesn't appear to be the bottleneck, and without JIT, method
specialzization doesn't seem too useful.

And, IMO, JIT would be nice for squeak, *but*, it'd lead to a harder to
port and more fragile interpreter. I'd rather have something that could be
ported easily to run on everything (includign a kitchen sink) to something
that might run a lot faster, but only with a lot of work in porting a far
more complicated interpreter.. which experience shows is unlikely to be
done.

I have thought on a direct/indirect threaded forth underlying interpreter,
with a JIT to compile to the forth code and optional method
specialization. If anyone wants to brainstorm cool interpreter ideas... CC
me.

--

On a more practical side, adding a much faster DNU to squeak wouldn't be
all *that* hard. If the cache lookup fails, add an entry to the
methodcache that invokes a primitive that does a DNU lookup on the method
cache. Thus, assuming that you don't blow out the cache, a DNU lookup
costs the same as two cache hits in the method cache. It doesn't have to
cost the same as doing a full lookup up the heiararchy.

Then, the only remaining costs are the Smalltalk side. Runtime support
could be added to help this by allowing a runtime method to directly add a
method to the method cache. With my cache, and a large enough cache for a
high hit rate, a MI invocation would cost about the same as a normal
invocation.


> (MOPs alone are no panacea, as the Common Lisp experience shows. The
> vendors tune their implementations to the standard object system and
> typical tricks and you can pay large speed prices if you diddle things in
> an unanticipated way.)

Yep.. Most of this isn't more than an implementation problem.. Why were
there no really good and fast LISP (~comparable to C) compilers for
numerics and bit/byte manipulations before CMUCL? Because nobody had
thought to write one. :)

Scott

--

PS. If anyone is considering working on a new interpreter, I've got some
ideas you may find useful, in terms of caching strategies, algorithms, and
datastructures.