Why Not Translate Perl to C
mwh at python.net
Mon Jul 2 00:00:04 CEST 2001
Oleg Broytmann <phd at phd.fep.ru> writes:
> Yes, but you cannot write a compiler that will translate StringIO
> into cStringIO. Python is too dynamic for this. If Python will ever
> get static typing, things will become much better and we can return
> to the task of building a compiler.
I think the "obvious" approach to making Python go faster is some kind
of dynamic recompilation, so that if a function gets called fifteen
thousand times with integer arguments you can compile up a specialised
Going further you could even implement schemes where functions are
inlined (or methods cached or whatever) and if the name of the inlined
function is rebound you run all over the heap smashing the code that
has this function inlined in, and so on. This would obviously be
quite slow - but you don't rebind function names very often, certainly
much much less often than you call them (in general).
I believe Self uses a boatload of tricks of this form, but that's
about as much as I know about Self.
Also, hard work. Who's going to pay for it? It's not the sort of
thing that's going to happen in one's spare time.
Armin Rigo has been having some fun in this area - read this post for
It's all still some way from being useful, sadly.
Getting truly off into the far blue yonder:
It also seems to me that dynamic recompilation is the way forward for
getting good performance out of modern chips where branch
misprediction has such a high cost - surely the best way to find out
which way a branch is likely to go is to check. Ars Technica has a
fascinating article on HP's Dynamo which explores things in this
(If you haven't read this article , read it now)
Has anyone had the opportunity to run Python under Dynamo? That would
be interesting, to say the least.
. <- the point your article -> .
|------------------------- a long way ------------------------|
-- Cristophe Rhodes, ucam.chat
More information about the Python-list