[Python-Dev] 2.7 is here until 2020, please don't call it a waste.
fijall at gmail.com
Tue Jun 2 21:07:40 CEST 2015
There was a PSF-sponsored effort to improve the situation with the
https://bitbucket.org/pypy/codespeed2/src being written (thank you
PSF). It's not better enough than codespeed that I would like, but
gives some opportunities.
That said, we have a benchmark machine for benchmarking cpython and I
never deployed nightly benchmarks of cpython for a variety of reasons.
* would be cool to get a small VM to set up the web front
* people told me that py3k is only interesting, so I did not set it up
for py3k because benchmarks are mostly missing
I'm willing to set up a nightly speed.python.org using nightly build
on python 2 and possible python 3 if there is an interest. I need
support from someone maintaining python buildbot to setup builds and a
VM to set up stuff, otherwise I'm good to go
DISCLAIMER: I did facilitate in codespeed rewrite that was not as
successful as I would have hoped. I did not receive any money from the
PSF on that though.
On Mon, Jun 1, 2015 at 1:14 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> On 01.06.2015 12:44, Armin Rigo wrote:
>> Hi Larry,
>> On 31 May 2015 at 01:20, Larry Hastings <larry at hastings.org> wrote:
>>> p.s. Supporting this patch also helps cut into PyPy's reported performance
>>> lead--that is, if they ever upgrade speed.pypy.org from comparing against
>>> Python *2.7.2*.
>> Right, we should do this upgrade when 2.7.11 is out.
>> There is some irony in your comment which seems to imply "PyPy is
>> cheating by comparing with an old Python 2.7.2": it is inside a thread
>> which started because "we didn't backport performance improvements to
>> 2.7.x so far".
>> Just to convince myself, I just ran a performance comparison. I ran
>> the same benchmark suite as speed.pypy.org, with 2.7.2 against 2.7.10,
>> both freshly compiled with no "configure" options at all. The
>> differences are usually in the noise, but range from +5% to... -60%.
>> If anything, this seems to show that CPython should take more care
>> about performance regressions. If someone is interested:
>> * "raytrace-simple" is 1.19 times slower
>> * "bm_mako" is 1.29 times slower
>> * "spitfire_cstringio" is 1.60 times slower
>> * a number of other benchmarks are around 1.08.
>> The "7.0x faster" number on speed.pypy.org would be significantly
>> *higher* if we upgraded the baseline to 2.7.10 now.
> If someone were to volunteer to set up and run speed.python.org,
> I think we could add some additional focus on performance
> regressions. Right now, we don't have any way of reliably
> and reproducibly testing Python performance.
> Hint: The PSF would most likely fund such adventures :-)
> Marc-Andre Lemburg
> Professional Python Services directly from the Source (#1, Jun 01 2015)
>>>> Python Projects, Coaching and Consulting ... http://www.egenix.com/
>>>> mxODBC Plone/Zope Database Adapter ... http://zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
> ::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::
> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
> Registered at Amtsgericht Duesseldorf: HRB 46611
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
More information about the Python-Dev