Re: Optimizing simple calls in a dynamically typed language?

On Aug 27, 2:12 pm, Christoffer Lernv <le...@dragonascendant.com>
wrote:
> On 25 Aug, 17:20, Paul Khuong <pkhu...@gmail.com> wrote:
>
> > 1. Unless you have hardware tagged arithmetic support (e.g. SPARC),
> > tagging fixnums with 0 saves a couple shifts during arithmetic. The
> > downside is that you have to do one more addition for pointer
> > operations that don't already add a constant offset. That's not bad at
> > all, especially if the architecture you're targeting offers load/store-
> > with-(constant-)offset instructions.
>
> Speaking of raw pointers, is that the way to go?
>
> I originally envisioned some sort of (compact) object table where what
> I passed around was simply the index into that table rather than the
> pointer itself.


I have looked at a few Lisp implementations, Perl, Python, SML-NJ, the
Boehm collector, and probably a few more. The only table-based
storage among them (at least that I recall; my memory is far from
perfect) is Scheme 9 From Emptyspace. S9FES has its inner core coded
in C. It stores conses as parallel arrays - one for cars, one for
cdrs, and a third for 1-byte type tags. An interesting aspect of the
novel cons representation is that C array indexing naturally provides
the (car ) and (cdr ) operations. For example, (caddr x) is
Car[Cdr[Cdr[x]]], where Car and Cdr are the respective object tables.
>
> Obviously this would mean another point of indirection whenever
> accessing data, but I was thinking it would simplify things like
> tracking all objects and maybe enable optimizations later on. It's
> just an idea and I don't know if it has any real advantages.
>
Well, if you have objects in clean tables, you always have a "back
door" for access without following pointers. You're right that this
can be a simplifying factor. It's easy to sweep after a mark pass of
GC. Just scan the tables. It's trivial to write dumps that can be
reloaded without fiddling with pointer offsets. Reflection features
can be easier to implement. Arena compaction can be easier. etc. etc.


A "hidden" indirection cost, though, is that the pointer table roughly
doubles cache load.


> I note that most implementations of object systems in C instead rely
> on passing a pointer directly to the object struct. What are the
> virtues of that approach, except for it being more C-ish?


Indeed, as you infer, a raw pointer dereference is likely to result in
a smaller, faster instruction sequence than a table dereference,
especially when the table base is itself given by a pointer, and even
moreso when the table contains pointers to the objects rather than the
objects themselves.

Return to the comp.compilers page.
Search the comp.compilers archives again.