Smalltalk › Squeak › Squeak VM

Direct object pointers vs indirect ones pros and cons

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

24 messages Options

Javier Burroni

Re: Direct object pointers vs indirect ones pros and cons

well, I think you are right. You have the extra loading for all
message sends but when sending to self

entryPoint:
mov [objectTable + selfID], self
cmp [self -4], nativizedClass
jnz lookup
endOfPrologue:

when sending message to self, you just put a call to endOfPrologue

On Wed, Oct 26, 2011 at 6:10 PM, Javier Burroni
<[hidden email]> wrote:

>>
>> yes, but then i will ask you to compare results with JIT optimized for
>> direct pointers.. :)
>>
>>> We have:
>>> accessing ivar: no extra cost
>>> method lookup:
>>> one extra indirection
>>> sends with MonomorphicInlineCache:
>>> no extra cost if implemented in an instance basis (checking against selfID).
>>
>> hmm.. that doesn't makes inline cache to be effective.
>> usually many different objects are passing via single call site but
>> they having same class, this is where monomophic IC shines.
>> if you change the cache to work on per-instance basis, i think it will
>> make it less effective because of too much misses.
> but you can have the two of them.
> In the jited prologue you may have something like:
>
> mov [objectTable + selfID], self
> cmp [self -4], nativizedClass
> jz endOfPrologue // patching code must be added here
> jmp looupAndJIT
> cmp selfID, nativizedSelfID <- entry point
> jnz cmpClass
> mov nativizedSelf, self
> endOfPrologue
>
>
> you add (mainly) an extra memory access, if the branch predictor helps
>
> --
> " To be is to do " ( Socrates )
> " To be or not to be " ( Shakespeare )
> " To do is to be " ( Sartre )
> " Do be do be do " ( Sinatra )
>

--
" To be is to do " ( Socrates )
" To be or not to be " ( Shakespeare )
" To do is to be " ( Sartre )
" Do be do be do " ( Sinatra )

Eliot Miranda-2

Re: Direct object pointers vs indirect ones pros and cons

In reply to this post by Javier Burroni

On Wed, Oct 26, 2011 at 1:11 PM, Javier Burroni <[hidden email]> wrote:

Igor Stasenko wrote:
>
> the first bench is kind-of 'measure time to access directly to objects'
> the second one is 'measure indirect access'
> and third is measure a loop overhead.
>
>

Hi there,
I've just arrived to this thread (thanks to Mariano), and I wanted to share
some speculations:
Having JIT'ed code with self (the oop of the actual object) in a register,
and selfID (the id of self in the object table) in a second register.
We have:
accessing ivar: no extra cost
method lookup:
one extra indirection
sends with MonomorphicInlineCache:
no extra cost if implemented in an instance basis (checking against selfID).
One indirection otherwise

GC (MarkAndCompact):
Faster (due to the removal of the threading process).

But taking a register away from e.g. the calling convention has costs, especially on x86 (6 user registers).

But what is selfID? Is that the object table index for self, or something related to self's class or?

saludos
jb

--
View this message in context: http://forum.world.st/Direct-object-pointers-vs-indirect-ones-pros-and-cons-tp3039203p3942123.html
Sent from the Squeak VM mailing list archive at Nabble.com.

--
best,

Eliot

Javier Burroni

Re: Direct object pointers vs indirect ones pros and cons

> But taking a register away from e.g. the calling convention has costs, especially on x86 (6 user registers).
Agree. I can use one register in the environment I'm using, but is not
costless (one extra push in methods with block closure
instantiations).
> But what is selfID? Is that the object table index for self, or something related to self's class or?
selfId is simple the object table index for self.

But the point that I wanted to make was the no overhead when accessing
ivars, and the gain in gc

saludos
jb

ps: for completeness. When optimizing message send to self, the
instance check must be perform (over self and not selfId), as #become:
may be sent to self

>>
>> saludos
>> jb
>>
>>
>> --
>> View this message in context: http://forum.world.st/Direct-object-pointers-vs-indirect-ones-pros-and-cons-tp3039203p3942123.html
>> Sent from the Squeak VM mailing list archive at Nabble.com.
>
>
>
> --
> best,
> Eliot
>
>

--
" To be is to do " ( Socrates )
" To be or not to be " ( Shakespeare )
" To do is to be " ( Sartre )
" Do be do be do " ( Sinatra )

Javier Burroni

Re: Direct object pointers vs indirect ones pros and cons

>
> ps: for completeness. When optimizing message send to self, the
> instance check must be perform (over self and not selfId), as #become:
> may be sent to self
We don't want this. Again, it's class based, not instance based

>>>
>>> saludos
>>> jb
>>>
>>>
>>> --
>>> View this message in context: http://forum.world.st/Direct-object-pointers-vs-indirect-ones-pros-and-cons-tp3039203p3942123.html
>>> Sent from the Squeak VM mailing list archive at Nabble.com.
>>
>>
>>
>> --
>> best,
>> Eliot
>>
>>
>
>
>
> --
> " To be is to do " ( Socrates )
> " To be or not to be " ( Shakespeare )
> " To do is to be " ( Sartre )
> " Do be do be do " ( Sinatra )
>

--
" To be is to do " ( Socrates )
" To be or not to be " ( Shakespeare )
" To do is to be " ( Sartre )
" Do be do be do " ( Sinatra )