[Vm-dev] Cog Primitive Performance

Eliot Miranda eliot.miranda at gmail.com
Tue Apr 18 19:04:28 UTC 2017


Hi Bert, Hi All,

On Tue, Apr 18, 2017 at 10:55 AM, Bert Freudenberg <bert at freudenbergs.de>
wrote:

>
> On Tue, Apr 18, 2017 at 6:09 PM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
>>
>> Concerning the specific case of hashMultiply, since it's just an imul and
>> a bitAnd, the primitive should be inlined by the VM just like other basic
>> arithmetic operations IMO.
>> So the remarks of Andres makes sense, even if we can't generalize to
>> other Misc primitives.
>>
>
> Yes, code optimized by Sista should be pretty much as fast as a primitive,
> so we could hopefully get rid of many primitives that are just there to
> improve performance.
>

The problem to think through carefully is the impact on the
ContextInterpreter, StackInterpreter and SqueakJS VMs.  I have a gut
feeling that the right thing to do is to keep the primitives for the
benefit of these VMs and to have Cog ignore them.  That implies that the
primitive failure code can be what one would like to execute and have Sista
optimize.  That means that translated primitives are an obstacle.

Rewriting the translated primitives as conventional primitives in
MiscPrimitivePlugin and not including the MiscPrimitivePlugin in Cog (JIT)
VMs (o including one which provides no primitives) would allow the
primitive failure code in the various Collection methods to be written
optimally, allow the interpreter VMs to keep using the primitives, allow
Cog VMs to ignore the primitives easily, and would allow putting the
primitives closer to the receivers.  Redirecting through to the class side
wastes cycles.

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


More information about the Vm-dev mailing list