Re: Optimizing simple calls in a dynamically typed language?

"Christoffer Lernv" <lerno@dragonascendant.com> wrote in message
> 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?


Raw Pointers (And Presumably Conservative Vs Precise Garbage Collection), Vs
tagged values or other cases, do offer a few advantages:
it is possible to mesh things much more nicely with C land;
a good deal of internal complexity can be reduced;
....


However, With A Raw Pointer Scheme, Getting Good Performance Is A Lot Harder
vs when using tagged values, especially if the compiler/interpreter does not
have strong type inference.




However, I Have Still Eventually Ended Up Largely Settling On Raw Pointers,
or as I have often called them, "magic pointers" (well, along with a VM
project that is, internally, rather overly complex).




> 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.
>


this is a worthwhile approach, especially if combined with a tagged-value
scheme (even if cheap, for example, representing fixnums or flonums as any
kind of allocated objects can become very expensive).


now, in my case, I have done something funky:
I allocate big chunks of address space (the details depends on OS and arch,
where on x86 this is typically the whole upper 1-2GB of the process image,
which is otherwise unusable by the app), and use chunks of this space for
things like fixnums and flonums.


so, I make a design proclamation:
not all of the address space pointed to by dynamic pointers is necessarily
addressable (and even if it is, it is not gueranteed to point at memory
necessarily representing the object being portrayed).


now, on x86-64, I have a far more massive piece of address space to play
with (56 bits usable for addresses? this leaves around 63.9935 bits free to
do anything I want with, although I currently only use another 48 or 56 bits
I think to represent my "special" space).




> 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.
>


some advantages, some disadvantages, despends on what you are doing.
as can be noted, when I was last using tagged values, they internally did
use indexing of this sort, and yes, the other advantages of this approach
(for example, you don't have to "look up" parts of the heap, ...) make up
for the added indirection.




> 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?
>


it is more C-ish mostly, and in C at least, tends to allow a much more
"natural" interface, but at additional costs. actually, within my existing
"magic pointer" system, this is often done as well, but this is also mixed
with far more "opaque" types and interfaces (abstract API calls and
similar...).


this is a system that in my case has generally "evolved" over the past
number of years (me at times using a much more primitive version of this
system, at other times using tagged-reference systems, facing issues like
one system being slower than hell, the other being a horrible PITA to use
from plain C code, ...).


it takes a long time to generally find something that works well...

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