Hi Clement,
On Mon, Jan 6, 2014 at 4:42 AM, Clément Bera bera.clement@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@gmail.com
On 6 January 2014 11:11, Nicolai Hess nicolaihess@web.de wrote:
2014/1/6 Clément Bera bera.clement@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