[Vm-dev] [Pharo-dev] Fed up
eliot.miranda at gmail.com
Thu Jan 23 09:13:02 UTC 2020
On Tue, Jan 21, 2020 at 5:48 PM Ronie Salgado <roniesalg at gmail.com> wrote:
> That performance regression looks more like a language implementation bug
> that a problem of the language itself. If we assume that #do: and some
> other selectors (e.g. #select, #reject) should always receive a block
> instead of a symbol, then the compiler could perfectly replace the symbol
> literal for an already instantiated block literal transparently from the
> user perspective. If the compiler does that we can save the bytecode for
> instantiating the block closure, which can save a potential roundtrip to
> the garbage collector. I guess (I am just speculating) that this
> performance overhead must be in the implementation of the #perform:
> primitive, which I guess has to:
> 1) go through the JIT stack into the C stack transition (saving/restoring
> interpreter/JIT state, additional pressure, and primitive activation
perform:, perform:with: et al (primitive 83), but not
perform:withArguments: are completely implemented in machine code with no
transition to C unless the method is not in the first-level method lookup
cache. See genPrimitivePerform, genLookupForPerformNumArgs:
2) the lack of inline caches for #perform: (again, I am just guessing in
> this case).
Right. There is only the first level method lookup cache so it has
interpreter-like performance. The selector and classs of receiver have to
be hashed and the first-level method lookup cache probed. Way slower than
block activation. I will claim though that Cog/Spur OpenSmalltalk's JIT
perform implementation is as good as or better than any other Smalltalk
VM's. IIRC VW only machine coded/codes perform: and perform:with:
Note that the OpalCompiler is currently inlining some methods such as
> #ifTrue:ifFalse: , #ifNil:ifNotNil: #and: #or: and there are not actual
> message sends, so adding an additional list of selector where literal
> symbol arguments are synthesized as blocks is not different to the cheating
> that the current compiler is doing. If an user wants to disable this
> inlining, there is currently a pragma for telling the compiler.
> Do you want me to propose an experimental patch for testing this
> Best regards,
> El mar., 21 ene. 2020 a las 19:56, Sven Van Caekenberghe (<sven at stfx.eu>)
>> I also like the use of symbols but more for casual code.
>> I know using blocks can be faster, but the difference is not massive.
>> What I don't understand is why it is so super bad. Polymorphism will
>> always be there, that is really powerful, when used wisely. I can't
>> immediately see why one or the other would make analysis easier or better.
>> Can you explain ?
>> > On 21 Jan 2020, at 23:37, Sean P. DeNigris <sean at clipperadams.com>
>> > ducasse wrote
>> >> in Pharo we should write
>> >> aCol do: [ :each | each store ]
>> > I always enjoyed the Symbol/Block polymorphism because I thought it was
>> > a clever and visible example of the power of Smalltalk, and, let's face
>> > I'm lazy and enjoyed saving a few key strokes!
>> > That said, I had no idea that there was a dramatic performance cost.
>> > the issues you raise about analysis seem important.
>> > Since people are free to still use it in their own projects, it doesn't
>> > to controversial. Can/should we add a lint rule? Can/should it be
>> scoped to
>> > Pharo core?
>> > -----
>> > Cheers,
>> > Sean
>> > --
>> > Sent from:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev