Re: Towards faster Python implementations - theory

sturlamolden wrote:
On May 8, 5:53 pm, John Nagle <n...@xxxxxxxxxxx> wrote:

The point here is that we don't need language changes or declarations
to make Python much faster. All we need are a few restrictions that
insure that, when you're doing something unusual, the compiler can
tell.

Franz, CMUCL, SBCL and GCL teams made Lisp almost as fast as C. A
dynamic language can be fast if the implementation is good.

If you look at SBCL and GCL, no code is interpreted. It's all compiled
on the fly to native machine code. The compiler begins with some code
and some input data, and compiles as much as it can. Then the RT
executes the machine code, compiles again, etc. Often long stretches
of code can be compiled without break, and tight performance critical
loops are usually compiled only once. In addition to this, one needs
an efficient system to cache compiled code, in order to do the
compilation work only once. making a dynamic language fast is not
rocket science.

We should have somthing like "GPython", a Python RT on top of a GCC
backend, similar to what the GCL team did for Lisp. There is no
obvious reason as to why Lisp should have better performance than
Python.

I doubt if anyone disputes the gist of what you're
saying[*], viz that Python could be made faster by using
technique (a), (b) or (c) which have been successful elsewhere. At least that it's worth investgating.

But the relevant bit of your last paragraph is at the start:
"We should...". Unless someone or someones has the time,
inclination, money, backing, wherewithal etc. to implement
this or any other measure of speeding-up, it's all
pie-in-the-sky. Useful, maybe, as discussion of what
options are viable, but a project of this magnitude
doesn't just happen in some developer's lunchbreak.

Many people (and I include myself) are quite
happy with Python's speed. In fact, I'm quite happy
with most things about Python. Others would like to
see it faster. That's great. But unless people
puts their money where their mouths are, I don't
see it happening.

TJG

[*] Actually, knowing this community, I'm sure *someone's*
going to!
.

Relevant Pages

  • Re: Why not a Python compiler?
    ... compilation by compiling to Common Lisp and using the CL's compiler to ... In order to correctly implement Python addition, ... Expressing simple loops as C for loops... ... optimization for a Python compiler are vague, ...
    (comp.lang.python)
  • Re: Python 3K or Python 2.9?
    ... function/method argument that might as well be hidden in the compiler ... You could add some syntax to Python such that '.x' was equivalent to ... def factory: ... C.method = foo ...
    (comp.lang.python)
  • Re: How does Ruby compare to Python?? How good is DESIGN of Rubycompared to Python?
    ... pure functional languages can prove facts about the code ... so in theory the compiler can optimize much more away. ... Python carries some extra baggage in each object. ... Haskell is a good pure-functional language to use as a comparison. ...
    (comp.lang.python)
  • Re: can anyone offer Lisp job?
    ... Look at how cool CMU's python compiler is and how ... CMU Python was actively being worked on, but I don't think it would show ... Lisp and the CMU Python compiler crushing ... ... You can't go challenging every world truth every ...
    (comp.lang.lisp)
  • Re: magic names in python
    ... They have no special meaning to the Python compiler. ... I don't consider magic in a programming language a bad thing. ... And it would appear we are working with the same definition as regarding methods: a magic name method is an identifier recognized by the compiler as a special case. ... I'm not contesting that some identifiers have special meaning or are treated differently under certain conditions. ...
    (comp.lang.python)