Archive for Mai, 2009

Code that doesn”t exist …

Sonntag, Mai 31st, 2009

Here’’s a post that nicely summarizes why the LOC count matters, and why bigger isn”t always better:

Code that doesn”t exist contains no bugs.
Code that doesn”t exist takes no time to execute.
Code that doesn”t exist takes up no space.
Code that doesn”t exist doesn”t need maintenance.

Yes, Python matters. And remember: we write C so you don”t have to.

A faster Python implementation? Think Cython!

Samstag, Mai 9th, 2009

I noticed that there is a whole set of talks on alternative Python implementations at EuroPython this year. From a quick glance, there seems to be mainly one missing: Cython.

“What?”, I hear you think, “Cython? Isn”t that just a tool for extending CPython?”. Well, yes, it is a tool for extending CPython. However, when you think about it the other way round, it actually is a Python implementation that only falls back to CPython for stuff that it doesn”t want to do itself, or that it doesn”t support yet. Everything else runs in plain C code and only uses parts of CPython that are not worth reimplementing, namely the object model and implementation, the fast container types, and the standard library. It will switch to CPython’’s eval loop only for Python modules that are not compiled.

Cython even has an on-the-fly compilation mode (pyximport) that can be used to compile Python modules (e.g. standard library modules or external dependencies) into fast C modules transparently on import. This is basically a JIT compiler that automatically falls back to CPython’’s byte code interpretation if the compilation fails for some reason.

The dependency on CPython (any version from 2.3-3.1) has many advantages for Python users. One is that you get 100% Python compatibility by definition, as CPython is always a part of Cython. This includes the complete standard library, all existing Python software, and all existing C extensions, with which you can sometimes even interact directly at the fast C level (e.g. Numpy, lxml.etree and others). Apart from CPython itself, there is no other Python implementation that currently achieves this.

On top of that, it’’s trivial to optimise pure Python code into type annotated Cython code (even in pure Python syntax) to speed up certain code sections by factors of several 100 times (1000 times and more is not unheard of). Running cython -a will generate a highlighted HTML representation of your code that shows where type annotations may lead to a speed up. There is no need to change all your code to get that speedup, just concentrate exactly on those sections that need raw speed - usually inner loops and tight algorithms. Or just call into a C, C++ or Fortran library that does the job fast enough already, even if you are not an expert in that language.

And another really cool feature: using Cython will let your code benefit from enhancements and optimisations in both CPython and Cython. Whenever any of the two projects finds a way to make the built-in types or the generated C code faster, it’’s your code that will become faster. Whenever someone writes a new module or extension for CPython, you can just import it without fearing compatibility issues. Whenever the Python language or the Cython language adds a new syntax feature, you can start using it right away, without waiting for other implementations to catch up. And we do have tons of ideas about stunning features and optimisations that we want to add to the Cython compiler.

So, you can either sit and wait for your code to get optimised for you, or you can get your own hands dirty now and join a very dynamic, open and friendly project that constantly makes Cython faster, better and simpler to use.