[Vm-dev] [Pharo-dev] Fed up

[Eliot Miranda]

Hi Ronie,

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

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:
and adjustArgumentsForPerform:.

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
> infrastructure?
>
> Best regards,
> Ronie
>
> El mar., 21 ene. 2020 a las 19:56, Sven Van Caekenberghe (<sven at stfx.eu>)
> escribió:
>
>> 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>
>> wrote:
>> >
>> > ducasse wrote
>> >> in Pharo we should write
>> >>      aCol do: [ :each | each store ]
>> >
>> > I always enjoyed the Symbol/Block polymorphism because I thought it was
>> such
>> > a clever and visible example of the power of Smalltalk, and, let's face
>> it,
>> > I'm lazy and enjoyed saving a few key strokes!
>> >
>> > That said, I had no idea that there was a dramatic performance cost.
>> Also,
>> > the issues you raise about analysis seem important.
>> >
>> > Since people are free to still use it in their own projects, it doesn't
>> seem
>> > to controversial. Can/should we add a lint rule? Can/should it be
>> scoped to
>> > Pharo core?
>> >
>> >
>> >
>> > -----
>> > Cheers,
>> > Sean
>> > --
>> > Sent from:
>> http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>> >
>>
>>
>>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200123/2972ae0b/attachment-0001.html>