[Vm-dev] Cog Primitive Performance

David T. Lewis lewis at mail.msen.com
Wed Apr 19 00:26:57 UTC 2017


On Wed, Apr 19, 2017 at 07:51:06AM +0800, Ben Coman wrote:
>  
> On Wed, Apr 19, 2017 at 3:42 AM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
> 
> >
> > 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.
> >
> 
> By ignore, do you mean excluded from the built binary by conditional
> compilation, to minimise VM size for embedded platforms?
> 

No, the primitives continue to exist and are invoked if and only if the
image wants to use them. The image can be smart enough to know if it wants
to use the primitives. And an older image that is not aware of this discussion
will continue to use the old primitives because they still exist in the VM,
even if they are no longer used or required by newer images.

Regarding VM size, the VM is designed to support named primitives that can
live in separately compiled modules ("external plugins"). The primitives
that we have been discussing here are one such example. They live in the
MiscPrimitivePlugin module, which can be compiled as a separate loadable
plugin module and excluded (or just deleted) if space is a concern.

Dave


More information about the Vm-dev mailing list