<br><br><div class="gmail_quote">On Mon, May 23, 2011 at 8:42 PM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>On Mon, May 23, 2011 at 07:30:09PM -0400, David T. Lewis wrote:<br>
> On Mon, May 23, 2011 at 02:33:52PM -0700, Eliot Miranda wrote:<br>
> ><br>
> > On Mon, May 23, 2011 at 2:08 PM, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
> > ><br>
> > > Testing success status, original:<br>
> > > if (foo->successFlag) { ... }<br>
> > ><br>
> > > Testing success status, new:<br>
> > > if (foo->primFailCode == 0) { ... }<br>
> > ><br>
> > > Setting failure status, original:<br>
> > > foo->successFlag = 0;<br>
> > ><br>
> > > Setting failure status, new:<br>
> > > if (foo->primFailCode == 0) {<br>
> > > foo->primFailCode = 1;<br>
> > > }<br>
> > ><br>
> > > So in each case the global struct is being used, both for successFlag<br>
> > > and primFailCode. Sorry for the confusion. In any case, I'm still left<br>
> > > scratching my head over the size of the performance difference.<br>
> > ><br>
> ><br>
> > One thought, where are successFlag and primFailCode in the struct? Perhaps<br>
> > the size of the offset needed to access them makes a difference?<br>
><br>
> In both cases they are the first element of the struct, so that<br>
> cannot be it.<br>
><br>
> I think I had better circle back and redo my tests. Maybe I made<br>
> a mistake somewhere.<br>
><br>
<br>
No mistake, the performance problem was real.<br>
<br>
Good news - I found the cause. Better news - this may be good for a<br>
performance boost on StackVM and possibly Cog also.<br></blockquote><div><br></div><div>thanks!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
The performance hit was due almost entirely to InterpreterPrimitives>>failed,<br>
and perhaps a little bit to #successful and #success: also.<br>
<br>
This issue with #failed is due to "^primFailCode ~= 0" which, for purposes<br>
of C translation, can be recoded as "^primFailCode" with an override in<br>
the simulator as "^primFailCode ~= 0". This produces a significant speed<br>
improvement, at least as fast as for the original interpreter implementation<br>
using successFlag.<br></blockquote><div><br></div><div>Note that with the Cog code generator and for the purposes of the simulator this can read</div><div><br></div><div>failed</div><div><div><span class="Apple-tab-span" style="white-space:pre"> </span><api></div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>^self cCode: [primFailCode] inSmalltalk: [primFailCode ~= 0]</div></div><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
I expect that the same change applied to StackInterpreter may give a similar<br>
10% improvement (though I have not tried it). I don't know what to expect<br>
with Cog, but it may give a boost there as well.<br>
<br>
Changes attached, also included in VMMaker-dtl.237 on SqueakSource.<br>
<br>
Dave<br>
<br>
<br></blockquote></div><br>