On Sun, Mar 20, 2011 at 9:39 AM, Stefan Behnel <stefan...@behnel.de> wrote: > Jesse Noller, 20.03.2011 13:51: >> >> ...snip >> >>> IMHO, taking modules that currently only have a C implementation due to >>> performance constraints and rewriting them in Cython is a much more >>> worthwhile thing to do than adding an alternative pure Python >>> implementation >>> that other Python runtimes wouldn't use anyway. And at least IronPython >>> could soon benefit directly from a Cython implementation as well. >>> >>> Stefan >> >> The other python implementation expressed serious interest, and are >> willing to help support a shared standard library, and shared modules. >> So saying they "won't use them anyway" may apply to things such as the >> io module, but is far from the truth for the entire standard library. > > I guess someone would have to look through the stdlib and make a list of > suitable candidates for Cython compilation and/or Python/Cython/C > reimplementations at this point. > > >> You're also asking that we depend on Cython within core > > It's a substantial dependency, sure. The question is: what's more work, > having to install a specific version of Cython in order to work on CPython, > or having to get fluent in C + C-API first? > > I like the way the Jython people put it, slightly adapted into "We write C > so you don't have to". > > >> which while >> it has it's benefits, I think warrants a PEP and a working >> implementation to show the potential speedups you're talking about >> before we can agree to include it/depend on it. > > We will have a Cython core developers workshop next weekend. Maybe we can > find a bit of time there to run the then-merged-together-bleeding-edge > Cython over the standard library and see what that gives. > > It's not easy to find good benchmarks, though. Most of what the PyPy/Unladen > developers settled on so far isn't very interesting for the way Cython > works. It's usually a bit of work to make the code substantially faster by > providing enough type annotations to let the compiler drop critical Python > code into C. We did that for a couple of benchmarks, but lost interest as > there wasn't much to win - all we could show was that, by changing the code > enough to make it violate the usual constraints of a fair benchmark > comparison, you could make it run as fast as C code without writing C code. > Not much news to us and nothing that would integrate in any acceptable way > into speed.pypy.org. > > If anyone knows about a good benchmark for a currently pure Python standard > library module, preferably a smaller, self-contained one that's somewhat > computationally intensive, I'd be happy to hear about it. > > Stefan
The nice thing is about those benchmarks - from PyPy and Unladen Swallow's work - is that they do reflect real world applications, and tend away from pure numerical micro benchmarks (how fast you can do fibonacci is almost worthless). So if we want to add more to that suite of benchmarks, great - but those will be some of the benchmarks against which speed improvements would be measured against. There's also a plan (coming out of the vm summit/language summit) to turn speed.pypy.org into a shared "performance.python.org" resource, and showcase the speed of CPython, Jython, IronPython and PyPy side by side, using common benchmarks. I am currently working on acquiring the needed resources from the PSF side to get us to the point where the real work can begin. If you can show that Cython lowers the barrier to writing fast(er) Python extensions, without dropping into pure C, and we don't cripple the ability for the other implementation to share the code, then by all means, I personally recommend a PEP. jesse _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
