<br><br><div class="gmail_quote">On Wed, Jan 23, 2013 at 12:58 PM, Ron Teitelbaum <span dir="ltr"><<a href="mailto:ron@usmedrec.com" target="_blank">ron@usmedrec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello All,<br>
<br>
In Memory of Andreas Raab<br>
<a href="http://forum.world.st/In-Memory-of-Andreas-Raab-td4663424.html" target="_blank">http://forum.world.st/In-Memory-of-Andreas-Raab-td4663424.html</a><br>
<br>
We have renamed and released the AndreasSystemProfiler.<br></blockquote><div><br></div><div>Both AndreasSystemProfiler and MessageTally are periodic sampling profilers. The essential difference between AndreasSystemProfiler and MessageTally is in how the current method is sampled.</div>
<div><br></div><div>MessageTally is driven from a high-priority process in a loop waiting on a delay. When the delay fires the lower-priority process being profiled is interrupted, its stack is walked to determine the methods along the call chain, and that data is recorded. But since the sampling occurs when the high-priority process preempts the lower-priority process, a sample is only taken at a preemption point. In particular, primitives are *not* profiled because they are not suspension points. A process can only be suspended on method activation (a non-primitive method activation, or primitive failure) or on backward branch. The cost of primitives is charged to a caller and is inferred by subtracting the cost of children of the caller from the caller itself (subtracting the number of samples in children of the caller form the number of samples in the caller itself). </div>
<div><br></div><div>Another problem is that using the clock that underlies Delay, which is typically the clock used by processes being profiled, causes sampling errors due to the sampling and sampled processes cohering. Delays are limited in resolution (at best 1 millisecond) so if the profiled process waits on a delay it'll fire immediately after the profiling process (because the profiling process is at higher priority) and so the sampling process may only ever see the sampled process in a wait state.</div>
<div><br></div><div>If MessageTally is used to profile multiple processes then a third problem is that if a primitive causes a process switch then its cost will end up being charged to the process switched-to, not switched from. This is again because sampling can only occur after a primitive has completed (successfully or not).</div>
<div><br></div><div>AndreasSystemProfiler is driven from a high-priority process in a loop waiting on a Semaphore known to the VM. The profiling process uses a primitive to schedule a sample some number of ticks of the VM's high-performance clock in the future. When the time is reached the VM samples the current method and the current process, *before any process preemption takes place*, and independently of the standard clock, and signals the semaphore. The profiling process then collects the method,process pair via primitives. So AndreasSystemProfiler provides much more accurate results.<br>
</div><div><br></div><div>That said there are still limitations with primitives and Cog. Currently Cog only samples "interpreter" primitives. Those primitives it implements in machine code (integer and float arithmetic, closure evaluation, at:, identityHash) are not sampled and won't show up; they will be charged to the calling method. This is fixable, since Cog actually compiles the sampling direct into interpreter primitive invocation when profiling is in effect and not at other times, but sampling could be a significant cost in these simple and performance-critical primitives.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href="http://ss3.gemstone.com/ss/AndreasSystemProfiler.html" target="_blank">http://ss3.gemstone.com/ss/AndreasSystemProfiler.html</a><br>
<br>
Using the MIT License.<br>
<br>
Thank you Eliot for your help to get this ready. The profiler works with<br>
Squeak 4.4.<br>
<br>
All the best,<br>
<br>
Ron Teitelbaum, Julie LeMoine and David Smith<br>
<br>
> -----Original Message-----<br>
> From: <a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org">squeak-dev-bounces@lists.squeakfoundation.org</a> [mailto:<a href="mailto:squeak-dev-">squeak-dev-</a><br>
> <a href="mailto:bounces@lists.squeakfoundation.org">bounces@lists.squeakfoundation.org</a>] On Behalf Of Andreas.Raab<br>
> Sent: Friday, January 11, 2013 1:39 PM<br>
> To: <a href="mailto:squeak-dev@lists.squeakfoundation.org">squeak-dev@lists.squeakfoundation.org</a><br>
> Subject: [squeak-dev] Re: Profiling<br>
><br>
> Levente Uzonyi-2 wrote<br>
> > It uses some primitives which were added to the CogVM, so it requires<br>
Cog.<br>
> > We could reimplement it from scratch using the same primitives and get<br>
> > a better profiler in the image. We can't include this due to the GPL<br>
> > license.<br>
><br>
> Or ask Ron if 3dicc (which bought all the rights to the Teleplace IP and<br>
> Software) can re-release the code under a more permissable license.<br>
><br>
> Cheers,<br>
> - Andreas<br>
><br>
><br>
><br>
<span class="HOEnZb"><font color="#888888">><br>
> --<br>
> View this message in context: <a href="http://forum.world.st/Profiling-" target="_blank">http://forum.world.st/Profiling-</a><br>
> tp4662704p4662987.html<br>
> Sent from the Squeak - Dev mailing list archive at Nabble.com.<br>
><br>
<br>
<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>