<div>> as I'm not doing any more<br>> work on the benchmarking framework.</div><div><br></div><div>That is a pity. But well, I'll have to do with asking.</div><div><br></div><div>There are a couple of things I want to discuss:</div>
<div><br></div><div>- An extra table (class) may be needed to store the hardware the benchmark was run on. pypy will probably need to be tested on other architectures.</div><div><br></div><div>- The interpreter table needs extra fields:</div>
<div> - revision: absolutely necessary</div><div> - tag: this is for 1.0, 1.1, beta, trunk, snapshot, or what ever. This is needed to know what pypy revisions to list in the web page that allows comparison to other python implementations (most importantly cpython).</div>
<div><div> - Furthermore: You state that compile options are not needed, that they would be different interpreters.</div><div>I agree that we can have pypy-c, pypy-crl and pypy-c-jit (for example) as different interpreters. But things can get messy if we add garbage collectors and other options: <span class="Apple-style-span" style="font-family: monospace; font-size: medium; white-space: pre; ">pypy-c-68150-gc=hybrid--opt=3--no-allworkingmodules <span class="Apple-style-span" style="font-family: arial; white-space: normal; font-size: small; ">, etc...</span></span></div>
</div><div><br></div><div>What are your thoughts on this?</div><div><br></div><div><br><br><div class="gmail_quote">2009/10/5 Anders Hammarquist <span dir="ltr"><<a href="mailto:iko@openend.se" target="_blank">iko@openend.se</a>></span><br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">Hi,<br>
<div><br>
In a message of Thu, 01 Oct 2009 23:07:38 +0200, Miquel Torres writes:<br>
>SQLAlchemy is problematic. there is a django-sqlalchemy project, but it is<br>
>still work in progress:<br>
><a href="http://code.google.com/p/django-sqlalchemy/wiki/Roadmap" target="_blank">http://code.google.com/p/django-sqlalchemy/wiki/Roadmap</a><br>
<br>
</div>And that seems rather dead, no checkins since april...<br>
<div><br>
>Otherwise, your DB design is valid. The simpler, the better.<br>
>One question: did you intend to keep a DB locally and then copy to the web<br>
>server backend or to store the data directly on the web server (<br>
><a href="http://speed.pypy.org" target="_blank">speed.pypy.org</a>)?<br>
<br>
</div>Well, my thoughts hadn't gone much past getting the runner up and storing<br>
the results. My intention was to have whatever web presentation running<br>
on that same host, but I had no plans for more complicated presentation.<br>
<div><br>
>About the DB design, while sufficient, I would probably add a couple of<br>
>things like version tags (for betas and final releases, for example), maybe<br>
>compile options (??). Why? because we want to be able to filter trunk<br>
>versions in every possible way.<br>
<br>
</div>I think remembering the svn revision of the run makes sense. Compile<br>
options, and probably branch tags, are probably better implemented as<br>
separate interpreters in my DB design.<br>
<div><br>
>In any case I want to discuss this a little bit more, because the DB needs<br>
>to be as complete as possible from the beginning. While the first version of<br>
>the visualization interface will be quick and dirty so that developers don't<br>
>have to wait months to have something useful (And only then will I design a<br>
>more powerful interface), I don't want to make big changes to the DB once we<br>
>start to regularly run benchmarks. That way the data can be safely stored<br>
>from the start.<br>
<br>
</div>This makes perfect sense. I will be happy to discuss with you, but I will<br>
leave the implementation in your capable hands as I'm not doing any more<br>
work on the benchmarking framework.<br>
<font color="#888888"><br>
/Anders<br>
</font></blockquote></div><br>
</div>