[Vm-dev] Cog Primitive Performance

Bert Freudenberg bert at freudenbergs.de
Tue Apr 18 19:42:38 UTC 2017


On Tue, Apr 18, 2017 at 9:04 PM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

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

Ah, good point.


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

Agreed.


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

Yep :)

- Bert -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170418/b4d40bcd/attachment.html>


More information about the Vm-dev mailing list