On Sat, Apr 2, 2011 at 12:05 PM, John Nagle <na...@animats.com> wrote:
> On 4/2/2011 3:30 AM, Stefan Behnel wrote: > >> Cython actually supports most Python language features now (including >> generators in the development branch), both from Python 2 and Python 3. >> Chances are that the next release will actually compile most of your >> Python code unchanged, or only with minor adaptations. >> > > Cython requires the user to insert type declarations, though, to > get a speed improvement. > Actually, Cython often gives modest speed improvements without type declarations, and greater improvements with type declarations. For still further improvements, you can turn to C datastructures in Cython. It surprises me how often people think of Cython as a weird dialect of Python. I know I used to before actually giving Cython a try. Cython's really pretty close to CPython; it just has some C-like things it can do too. Shed Skin has a good type inference system, but it insists on > a unique type for each object (which includes "null"; a type of > "str or null" is not acceptable). The rest of Shed Skin, outside > the type inference system, is not very well developed. > > There's a path there to a fast Python with some restrictions. > The Shed Skin inference engine with the Cython engine might have > potential. > I'm not sure Shedskin and Cython are that compatible in their backends, though I imagine they could share ideas more. ISTR that Cython already does some type inference without restricting types much. > PyPy gets some speedups, mostly by recognizing when numbers can be > unboxed. For my current project, I find that Pypy gets quite remarkable speedups, even when compared to Cython: http://stromberg.dnsalias.org/~dstromberg/backshift/ The algorithm being tested is a byte-by-byte content-based checksum. (I believe I've shared the above link here before) There's no easy way to speed up Python; that's been tried. > It needs either a very, very elaborate JIT system, more complex > than the ones for Java or Self, or some language restrictions. > The main restriction I would impose is to provide a call that says: > "OK, we're done with loading, initialization, and configuration. > Now freeze the code." At that moment, all the global > analysis and compiling takes place. This allows getting rid > of the GIL and getting real performance out of multithread > CPUs. > Freezing things is a nice idea - one I suggested on the unladen swallow list a while back. But Pypy seems to be doing quite well without it, at least in my limited benchmarking.
-- http://mail.python.org/mailman/listinfo/python-list
