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
--
http://mail.python.org/mailman/listinfo/python-list
