[Python-Dev] 2.7 is here until 2020, please don't call it a waste.

[Maciej Fijalkowski]

Hi

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.

Cheers,
fijal


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
> eGenix.com
>
> 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
>                http://www.egenix.com/company/contact/
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com