[Vm-dev] SqueakJS named primitives in the interpreter modulej

[David T. Lewis]

On Tue, Jan 24, 2017 at 09:46:01PM -0500, David T. Lewis wrote:
> On Mon, Jan 23, 2017 at 04:17:42PM +0100, Bert Freudenberg wrote:
> >  
> > On Sat, Jan 21, 2017 at 5:06 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> > 
> > >
> > > I sent a git pull request for the new primitive, so hopefully you can
> > > review it and include it in SqueakJS if it is not too horrible.
> > 
> > 
> > Awesome! Merged.
> > 
> > To my considerable surprise, DateAndTime>>now seems to be 70 times faster
> > > on SqueakJS when using this primitive along with the enhancements in the
> > > UTCDateAndTime repository.
> > 
> > 
> > Well, emulating a primitive is a lot more expensive on a slow VM like
> > SqueakJS still is. So I'm not too, surprised, but happy nonetheless :)
> > 
> 
> I was comparing DateAndTime class>>now with UTCDateAndTime versus the
> DateAndTime class>>now in standard Squeak Chronology. Both of them call
> primitives, but the new one is much faster.
> 
> Having said that, I can see that other DateAndTime functions are marginally
> slower with UTCDateAndTime in SqueakJS. This is due to using large integer
> arithmetic with no support from LargeIntegersPlugin. I'm guessing that if
> one or two primitives from LargeIntegersPlugin could be implemented in
> SqueakJS, it would provide a big performance boost for this particular
> use case.

Sorry to reply to my own post, but I need to retract this. The profiler
shows that a big portion of the time is spent in

    LargePositiveInteger(Integer)>>digitDiv:neg:

I mistakenly assumed that primDigitDevNegative was not implemented for
the LargeIntegers module, but that is wrong, I see now that function
primDigitDivNegative() is implemented in the translated plugins. So maybe
it is not an efficient implementation when translated to JavaScript?
I am not sure.

Dave