Speed-up for loops

[Stefan Behnel]

BartC, 05.09.2010 19:09:
> I've thought about it (writing an independent interpreter). But I don't
> know enough of the language, and a lot of it I don't understand (eg.
> OOP). Besides, I think the language itself deliberately makes it
> difficult to get it up to speed. Some of the reasons might be the ones
> set down here, in Chapter 2:
>
> http://codespeak.net/svn/user/antocuni/phd/thesis/thesis.pdf

Second sentence of the abstract:

"""
However, all the existing implementations
prevent programmers from developing very efficient code.
"""

For an incorrect statement, that's a pretty bold one, even in the context 
given by the abstract. The author is lucky not to be an English native 
speaker, which explains some of the offensive wording in the intro.

Also, I'm impressed by an accepted Ph.D. thesis that comes along with just 
a bit more than four pages of references, and that fails to reference 
basically everything that the Python ecosystem provides for fast 
computation. I wouldn't mind a "faster Python", but as long as Python 
continues to be a language that allows you to very quickly get to the point 
where you can benchmark and optimise your code, and as long as CPython then 
makes it easy to do that, I won't be the one jumping up and down for a 
small factor of "general" improvement, especially when it comes at the 
price of switching to a completely different runtime. After all, it's 
really hard to appreciate that a program can now wait 5% more often on I/O 
than before. Larger performance improvements are usually due to algorithmic 
changes (including data structure adaptations and caching), rarely due to 
changes in the interpreter, especially when it's as old and well optimised 
as CPython.

I think the CPython interpreter does a really good job in providing a 
stable and predictable runtime environment and executing code in it, and 
the CPython ecosystem does a really good job in providing tools that make 
code run fast that needs to, be it due to efficient usage of I/O, CPU, 
memory, or whatever.

I'm not trying to put down the achievements of the author of the cited 
thesis, not at all. I'm sure the results are interesting for some people 
and for some kinds of applications, just like the different Python 
implementations are interesting for some people and some applications. But 
an awful lot of existing apps won't benefit at all from a fast CLI based 
Python implementation, simply because it doesn't have access (or at least 
no efficient access) to many of the existing tools in the CPython ecosystem.


>> The simple fact is that there are far more important things for Python
>> developers to spend their time and effort on than optimizations like
>> this.
>
> I don't know, there's seem to be an awful lot of effort going into
> addressing exactly this issue (eg. PyPy, Pscyo, Unladen Swallow,
> Shedskin....)

Those are very different efforts that address very different issues.


> All those compilers that offer loop unrolling are therefore wasting
> their time...

Sometimes they do, yes.

Stefan