Hi again,<br><br>trying to do some research on ways to record memory usage in an X-platform way...<br><br>keeping my notes here:<br>    <a href="http://renesd.blogspot.com/2010/03/memory-usage-of-processes-from-python.html">http://renesd.blogspot.com/2010/03/memory-usage-of-processes-from-python.html</a><br>
<br>So far people have come up with these two useful projects so far:<br>    <a href="http://code.google.com/p/psutil/">http://code.google.com/p/psutil/</a><br>    <a href="http://code.google.com/p/pympler/">http://code.google.com/p/pympler/</a><br>
<br>I think psutil will have most info needed to construct a decent memory recording module for benchmarks.  However, it includes C code, so will probably have to rip some of the memory parts out, and maybe reimplement with ctypes.<br>
<br><br>cu,<br><br><br><br><br><div class="gmail_quote">On Fri, Mar 12, 2010 at 10:49 AM, René Dudfield <span dir="ltr">&lt;<a href="mailto:renesd@gmail.com">renesd@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
btw, for python memory usage on linux<br>/proc/PID/status<br><br>Here is some code for linux...<br><br>wget <a href="http://rene.f0o.com/%7Erene/stuff/memory_usage.py" target="_blank">http://rene.f0o.com/~rene/stuff/memory_usage.py</a><br>
<br>
&gt;&gt;&gt; import memory_usage<br>&gt;&gt;&gt; bytes_of_resident_memory = memory_usage.resident()<br><br><br>Should be easy enough to add that to benchmarks at the start and end?  Maybe calling it in the middle would be a little harder... but not too hard.<br>

<br><br>TODO: Would need to be updated for other platforms, and support measuring child processes, tests, and code cleanup :)<br><br>cu,<div><div></div><div class="h5"><br><br><br><br><div class="gmail_quote">On Thu, Mar 11, 2010 at 12:32 AM, Maciej Fijalkowski <span dir="ltr">&lt;<a href="mailto:fijall@gmail.com" target="_blank">fijall@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hey.<br>
<br>
I&#39;ll answer questions that are relevant to benchmarks themselves and<br>
not running.<br>
<div><div></div><div><br>
On Wed, Mar 10, 2010 at 4:45 PM, Bengt Richter &lt;<a href="mailto:bokr@oz.net" target="_blank">bokr@oz.net</a>&gt; wrote:<br>
&gt; On 03/10/2010 12:14 PM Miquel Torres wrote:<br>
&gt;&gt; Hi!<br>
&gt;&gt;<br>
&gt;&gt; I wanted to explain a couple of things about the speed website:<br>
&gt;&gt;<br>
&gt;&gt; - New feature: the Timeline view now defaults to a plot grid, showing<br>
&gt;&gt; all benchmarks at the same time. It was a feature request made more<br>
&gt;&gt; than once, so depending on personal tastes, you can bookmark either<br>
&gt;&gt; /overview/ or /timeline/. Thanks go to nsf for helping with the<br>
&gt;&gt; implementation.<br>
&gt;&gt; - The code has now moved to github as Codespeed, a benchmark<br>
&gt;&gt; visualization framework (<a href="http://github.com/tobami/codespeed" target="_blank">http://github.com/tobami/codespeed</a>)<br>
&gt;&gt; - I have updated <a href="http://speed.pypy.org" target="_blank">speed.pypy.org</a> with version 0.3. Much of the work has<br>
&gt;&gt; been under the hood to make it feasible for other projects to use<br>
&gt;&gt; codespeed as a framework.<br>
&gt;&gt;<br>
&gt;&gt; For those interested in further development you can go to the releases<br>
&gt;&gt; wiki (still a work in progress):<br>
&gt;&gt; <a href="http://wiki.github.com/tobami/codespeed/releases" target="_blank">http://wiki.github.com/tobami/codespeed/releases</a><br>
&gt;&gt;<br>
&gt;&gt; Next in the line are some DB changes to be able to save standard<br>
&gt;&gt; deviation data and the like. Long term goals besides world domination<br>
&gt;&gt; are integration with buildbot and similarly unrealistic things.<br>
&gt;&gt; Feedback is always welcome.<br>
&gt;<br>
&gt; Nice looking stuff. But a couple comments:<br>
&gt;<br>
&gt; 1. IMO standard deviation is too often worse than useless, since it hides<br>
&gt;    the true nature of the distribution. I think the assumption of normalcy<br>
&gt;    is highly suspect for benchmark timings, and pruning may hide interesting clusters.<br>
&gt;<br>
&gt;    I prefer to look at scattergrams, where things like clustering and correlations<br>
&gt;    are easily apparent to the eye, as well as the amount of data (assuming a good<br>
&gt;    mapping of density to visuals).<br>
<br>
</div></div>That&#39;s true. In general a benchmark run over time is a period of<br>
warmup, when JIT compiles assembler followed by thing that can be<br>
described by average and std devation. Personally I would like to have<br>
those 3 measures separated, but didn&#39;t implement that yet (it has also<br>
some interesting statistical questions involved). Std deviation is<br>
useful to get whether a difference was meaningful of certain checkin<br>
or just noise.<br>
<div><br>
&gt;<br>
&gt; 2. IMO benchmark timings are like travel times, comparing different vehicles.<br>
&gt;    (pypy with jit being a vehicle capable of dynamic self-modification ;-)<br>
&gt;    E.g., which part of travel from Stockholm to Paris would you concentrate<br>
&gt;    on improving to improve the overall result? How about travel from Brussels to Paris?<br>
&gt;    Or Paris to Sydney? ;-P Different things come into play in different benchmarks/trips.<br>
&gt;    A Porsche Turbo and a 2CV will both have to wait for a ferry, if that&#39;s part of the trip.<br>
&gt;<br>
&gt;    IOW, it would be nice to see total time broken down somehow, to see what&#39;s really<br>
&gt;    happening.<br>
<br>
</div>I can&#39;t agree more with that. We already do split time when we perform<br>
benchmarks by hand, but they&#39;re not yet integrated into the whole<br>
nightly run. Total time is what users see though, that&#39;s why our<br>
public site is focused on that. I want more information available, but<br>
we have only limited amount of manpower and miquel already did quite<br>
amazing job in my opinion :-) We&#39;ll probably go into more details.<br>
<br>
The part we want to focus on past-release is speeding up certain parts<br>
of tracing as well as limiting it&#39;s GC pressure. As you can see, the<br>
split would be very useful for our development.<br>
<div><br>
&gt;<br>
&gt;    Don&#39;t get me wrong, the total times are certainly useful indicators of progress<br>
&gt;    (which has been amazing).<br>
&gt;<br>
&gt; 3. Speed is ds/dt and you are showing the integral of dt/ds over the trip distance to get time.<br>
&gt;    A 25% improvement in total time is not a 25% improvement in speed. I.e., (if you define<br>
&gt;    improvement as a percentage change in a desired direction), for e.g. 25%:<br>
&gt;    distance/(0.75*time) != 1.25*(distance/time).<br>
&gt;<br>
&gt;    IMO &#39;speed&#39; (the implication to me in the name <a href="http://speed.pypy.org" target="_blank">speed.pypy.org</a>) would be benchmarks/time<br>
&gt;    more appropriately than time/benchmark.<br>
&gt;<br>
&gt;    Both measures are useful, but time percentages are easy to mis{use,construe} ;-)<br>
<br>
</div>That&#39;s correct.<br>
<br>
Benchmarks are in general very easy to lie about and they&#39;re by<br>
definition flawed. That&#39;s why I always include raw data when I publish<br>
stuff on the blog, so people can work on it themselves.<br>
<div><br>
&gt;<br>
&gt; 4. Is there any memory footprint data?<br>
&gt;<br>
<br>
</div>No. Memory measurment is hard and it&#39;s even less useful without<br>
breaking down. Those particular benchmarks are not very good basis for<br>
memory measurment - in case of pypy you would mostly observe the<br>
default allocated memory (which is roughly 10M for the interpreter +<br>
16M for semispace GC + cache for nursery).<br>
<br>
Also our GC is of a kind that it can run faster if you give it more<br>
memory (not that we use this feature, but it&#39;s possible).<br>
<br>
Cheers,<br>
fijal<br>
<div><div></div><div>_______________________________________________<br>
<a href="mailto:pypy-dev@codespeak.net" target="_blank">pypy-dev@codespeak.net</a><br>
<a href="http://codespeak.net/mailman/listinfo/pypy-dev" target="_blank">http://codespeak.net/mailman/listinfo/pypy-dev</a></div></div></blockquote></div><br>
</div></div></blockquote></div><br>