[Vm-dev] Performance of primitiveFailFor: and use of primFailCode

David T. Lewis lewis at mail.msen.com
Tue May 24 16:55:20 UTC 2011


On Tue, May 24, 2011 at 09:07:30AM -0700, Eliot Miranda wrote:
>  
> On Mon, May 23, 2011 at 8:42 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> >
> > The performance hit was due almost entirely to
> > InterpreterPrimitives>>failed,
> > and perhaps a little bit to #successful and #success: also.
> >
> > This issue with #failed is due to "^primFailCode ~= 0" which, for purposes
> > of C translation, can be recoded as "^primFailCode" with an override in
> > the simulator as "^primFailCode ~= 0". This produces a significant speed
> > improvement, at least as fast as for the original interpreter
> > implementation
> > using successFlag.
> >
> 
> Note that with the Cog code generator and for the purposes of the simulator
> this can read
> 
> failed
> <api>
> ^self cCode: [primFailCode] inSmalltalk: [primFailCode ~= 0]
> 
> The Cog inliner maps self cCode: aCBlock inSmalltalk: anStBlock to aCBlock
> at TMethod creation time, hence avoiding the inability to inline
> cCode:inSmallalk:.  See MessageNode>>asTranslatorNode: in the Cog VMMaker.
>  I'll integrate as such in Cog.

Thanks. I had some problems with inlining when I wrote it that way, so I
had to back off to just using an override in the simulator. I'll look to
pick up the appropriate fixes for this from Cog as merging proceeds.

BTW I, did not actually test the simulator after doing this, hope I did
not break anything for Craig's Spoon work ;)

Dave



More information about the Vm-dev mailing list