<div dir="ltr">On Sun, Jul 20, 2008 at 11:49 PM, David T. Lewis &lt;<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>&gt; wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
&nbsp;<br>I don&#39;t know if this is of any general interest, but attached is a<br>
gprof output listing of a Squeak VM with the memory access routines<br>
from sqMemoryAccess.h recoded in Slang.<br>
<br>
I now have the Slang inlining working so that it can fully inline all<br>
of these methods. With the Slang inlining activiated, performance is<br>
essentially identical to that of the normal macros in sqMemoryAccess.h.<br>
By turning the Slang inlining off, the functions are all called<br>
individually, which is what I used to generated the attached profile.<br>
<br>
The host is 64-bit Linux AMD. The profile was run by opening a largish<br>
image, running &quot;0 tinyBenchmarks&quot; a half dozen times, and exiting the<br>
image without saving.<br>
<br>
So far, the advantages of putting the memory access routines into<br>
the image as Slang seem to be:<br>
- You can step into the methods in a debugger<br>
- The methods can be profiled<br>
- Exposes type declaration problems previously hidden by the macros<br>
<br>
Is anyone interested in this?<br>
<br>
Dave</blockquote><div><br>Yeah, I&#39;m interested in this.&nbsp; I&#39;m always interested in speeding up the interpreter.<br><br>What I find interesting is that there&#39;s no particular hot spot in the profile. I find<br>that profiling typically reveals a single function taking up 50+% of the runtime,<br>
but that isn&#39;t the case here.&nbsp; There&#39;s a fairly even tail.<br><br>Even if we *doubled* the speed of interpret() and pointerForOop(), we&#39;d still<br>only gain a 20% speed-up.<br><br>So there&#39;s isn&#39;t any easy improvement, unless I misunderstand the data <br>
(which is quite possible!).&nbsp; To gain significant speed-ups, we&#39;d have to make<br>hundreds of micro-optimisations throughout the code-base, which would<br>probably complicate the code (which is pretty clean at the moment).<br>
<br>Andrew</div></div><br></div>