[pypy-dev] Nightly Benchmarks

Miquel Torres tobami at googlemail.com
Mon Oct 5 23:04:16 CEST 2009

> as I'm not doing any more
> work on the benchmarking framework.

That is a pity. But well, I'll have to do with asking.

There are a couple of things I want to discuss:

- 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.

- The interpreter table needs extra fields:
    - revision: absolutely necessary
    - 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).
    - Furthermore: You state that compile options are not needed, that they
would be different interpreters.
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:
, etc...

What are your thoughts on this?

2009/10/5 Anders Hammarquist <iko at openend.se>

> Hi,
> In a message of Thu, 01 Oct 2009 23:07:38 +0200, Miquel Torres writes:
> >SQLAlchemy is problematic. there is a django-sqlalchemy project, but it is
> >still work in progress:
> >http://code.google.com/p/django-sqlalchemy/wiki/Roadmap
> And that seems rather dead, no checkins since april...
> >Otherwise, your DB design is valid. The simpler, the better.
> >One question: did you intend to keep a DB locally and then copy to the web
> >server backend or to store the data directly on the web server (
> >speed.pypy.org)?
> Well, my thoughts hadn't gone much past getting the runner up and storing
> the results. My intention was to have whatever web presentation running
> on that same host, but I had no plans for more complicated presentation.
> >About the DB design, while sufficient, I would probably add a couple of
> >things like version tags (for betas and final releases, for example),
> maybe
> >compile options (??). Why? because we want to be able to filter trunk
> >versions in every possible way.
> I think remembering the svn revision of the run makes sense. Compile
> options, and probably branch tags, are probably better implemented as
> separate interpreters in my DB design.
> >In any case I want to discuss this a little bit more, because the DB needs
> >to be as complete as possible from the beginning. While the first version
> of
> >the visualization interface will be quick and dirty so that developers
> don't
> >have to wait months to have something useful (And only then will I design
> a
> >more powerful interface), I don't want to make big changes to the DB once
> we
> >start to regularly run benchmarks. That way the data can be safely stored
> >from the start.
> This makes perfect sense. I will be happy to discuss with you, but I will
> leave the implementation in your capable hands as I'm not doing any more
> work on the benchmarking framework.
> /Anders
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20091005/ea441e77/attachment.html>

More information about the Pypy-dev mailing list