[Vm-dev] Re: [Pharo-dev] Can we override == in Pharo ?

Eliot Miranda eliot.miranda at gmail.com
Tue Jan 7 02:10:04 UTC 2014


Hi Clement,

On Mon, Jan 6, 2014 at 4:42 AM, Clément Bera <bera.clement at gmail.com> wrote:

> So I tried and it worked.
>
> In Opal to remove the usage of #==, I removed it from the special selector
> array in the method:
> IRBytecodeGenerator class>>specialSelectorsArray
>  ^ #(#+ 1 #- 1 #< 1 #> 1 #<= 1 #>= 1 #= 1 #~= 1 #* 1 #/ 1 #\\ 1 #@ 1
> #bitShift: 1 #// 1 #bitAnd: 1 #bitOr: 1 #at: 1 #at:put: 2 #size 0 #next 0
> #nextPut: 1 #atEnd 0 #== 1 nil 0 #blockCopy: 1 #value 0 #value: 1 #do: 1
> #new 0 #new: 1 #x 0 #y 0)
>
> Then I ran:
> IRBytecodeGenerator initialize.
> OpalCompiler recompileAll.
>
> Then in my example:
>
> A>>==
>     ^ true
>
> a := A new.
> b := A new.
> a == b  answered true, so it worked.
>
> I don't like all these messages with no lookup. I don't even know if this
> permits to earn performance now that we have inline caches.
>

Well, the arithmetic selectors *really* pay their way.  Try your experiment
with #+ through #~= and I bet you'll see slower loops.  I think there's a
compromise, which is to only inline the arithmetic selectors.  That's what
we did with the VisualWorks VM, HPS.  There one can set a hidden flag in
the image which directs the JIT (HPS only has a JIT) not to inline #== (VW
does not inline #class), and change the flag with a primitive.  We could
(and I think should) do the same.  Note that currently only #== and #class
are inlined for all objects.  The arithmetic selectors #+ et al and #< et
al are only inlined by the JIT for SmallInteger, and executed without
lookup in the interpreter for SmallInteger x Float.


> @Frank Shearar
> Just a detail, #timesRepeat: is not inlined any more by default in Pharo
> 3.0 because there were conflicts with a stream library. Anyway it didn't
> provide a lot of performance (just removed 1 indirection).
>
>
>
>
>
>
> 2014/1/6 Frank Shearar <frank.shearar at gmail.com>
>
>> On 6 January 2014 11:11, Nicolai Hess <nicolaihess at web.de> wrote:
>> > 2014/1/6 Clément Bera <bera.clement at gmail.com>
>> >>
>> >> Hello,
>> >>
>> >> here I have a class
>> >>
>> >> A>>==
>> >>     ^ true
>> >>
>> >> Now:
>> >> a := A new.
>> >> b := A new.
>> >> a == b "Answers false"
>> >> a perform: #== with: b "Answers true"
>> >>
>> >> Do I have to remove the usage of the byte code for #== in the compiler
>> to
>> >> be able to override == ?
>> >>
>> >>
>> >
>> >
>> > No, a==b should be used for "are the same Objects" (pointing to the same
>> > object) and not "are equal".
>> > Look for example at the commentn for ProtoObject>>==
>>
>> Given the kinds of things Clément does, I suspect he knows full well
>> the difference between #== and #=.
>>
>> My understanding is that the compiler inlines #== sends like it does
>> with #timesRepeat: and ifTrue:ifFalse:. So yes, you'd need to fiddle
>> with the compiler for any #== overrides to actually run.
>>
>> (I'm keen for Marcus to show us how exactly to do that in Opal!)
>>
>> frank
>>
>> > Nicolai
>>
>>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140106/47ecbd3d/attachment.htm


More information about the Vm-dev mailing list