From: David Cournapeau on
On Sun, Jan 17, 2010 at 11:43 AM, John Nagle <nagle(a)animats.com> wrote:
> David Cournapeau wrote:
>>
>> On Sun, Jan 17, 2010 at 4:17 AM, John Nagle <nagle(a)animats.com> wrote:
>>>
>>> Nobody wrote:
>>>>
>>>> On Fri, 15 Jan 2010 12:34:17 -0800, John Nagle wrote:
>>>>
>>>>>   Actually, no.  It's quite possible to make a Python implementation
>>>>> that
>>>>> runs fast.  It's just that CPython, a naive interpreter, is too
>>>>> primitive
>>>>> to do it.  I was really hoping that Google would put somebody good at
>>>>> compilers in charge of Python and bring it up to production speed.
>>>>>
>>>>>   Look at Shed Skin, a hard-code compiler for Python
>>>>
>>>> A hard-code compiler for the subset of Python which can easily be
>>>> compiled.
>>>>
>>>> Shed Skin has so many restrictions that it isn't really accurate to
>>>> describe the language which it supports as "Python".
>>>>
>>>> Hardly any real-world Python code can be compiled with Shed Skin. Some
>>>> of
>>>> it could be changed without too much effort, although most of that is
>>>> the
>>>> kind of code which wouldn't look any different if it was implemented in
>>>> C++ or Java.
>>>>
>>>> The monomorphism restriction is likely to be particularly onerous: the
>>>> type of a variable must be known at compile time; instances of
>>>> subclasses
>>>> are allowed, but you can only call methods which are defined in the
>>>> compile-time class.
>>>>
>>>> If you're writing code which makes extensive use of Python's dynamicity,
>>>> making it work with Shed Skin would require as much effort as re-writing
>>>> it in e.g. Java, and would largely defeat the point of using Python in
>>>> the
>>>> first place.
>>>>
>>>> http://shedskin.googlecode.com/files/shedskin-tutorial-0.3.html
>>>>
>>>> If you want a language to have comparable performance to C++ or Java,
>>>> you
>>>> have to allow some things to be fixed at compile-time. There's a reason
>>>> why C++ and Java support both virtual and non-virtual ("final") methods.
>>>
>>>   My point is that Python is a good language held back by a bad
>>> implementation.  Python has gotten further with a declaration-free syntax
>>> than any other language.  BASIC and JavaScript started out
>>> declaration-free,
>>> and declarations had to be retrofitted.  Python has survived without
>>> them.
>>> (Yes, there are hokey extensions like Psyco declarations and
>>> "decorators",
>>> but both are marginal concepts.)
>>
>> There are efficient implementations of dynamic programming languages
>> which do not rely on declaration (if by declaration you mean typing
>> declaration), even when available:
>>
>> http://strongtalk.googlecode.com/svn/web%20site/history.html
>>
>> See also:
>>
>> http://www.avibryant.com/2008/05/those-who-misre.html
>
>   Yes, that's my point.

Compilation with global type inference may be a good way to speed up
python, but it is not the only way. Your claim about lookups does seem
to contradict how the various efficient implementations of dynamic
languages work. For example, the V8 engine deal with dynamic
attributes without static analysis:

http://code.google.com/apis/v8/design.html

So JIT may be limited, but I don't think it applies to the examples
you have given. Maybe static analysis ala stalin is needed for very
fast execution.

I don't claim any knowledge on those technologies, but my impression
is that other forces held back a fast python implementation, in
particular compatibility with C extensions. For example, I know no
fast implementation of dynamic languages which do not rely on garbage
collection: if this is indeed true, it may mean that retrofitting a gc
everywhere is needed, but doing so without breaking C extensions is
hard (if at all possible ?). And certainly, one of the big reason for
the python success is easy interface with C. Maybe interfacing with C
is the real reason for holding back python implementations ?

cheers,

David
From: Paul Rubin on
David Cournapeau <cournape(a)gmail.com> writes:

> And certainly, one of the big reason for
> the python success is easy interface with C. Maybe interfacing with C
> is the real reason for holding back python implementations ?

The CPython/C API is not terrible but it's not all that easy to use.
For example, it's very easy to make reference counting errors. Other
language FFI's that I've used avoid that problem to some extent. It's
true that CPython has quite a few existing C modules that would require
rework if the API were to change incompatibly. But I think a different
(better) API wouldn't stop people from writing new modules.
From: Terry Reedy on
On 1/16/2010 10:08 PM, David Cournapeau wrote:

> Compilation with global type inference may be a good way to speed up
> python, but it is not the only way. Your claim about lookups does seem
> to contradict how the various efficient implementations of dynamic
> languages work. For example, the V8 engine deal with dynamic
> attributes without static analysis:
>
> http://code.google.com/apis/v8/design.html

Reading that, I notice a couple of things.

1. Like Psycho, V8 trades space for time. Given that space is now
expanding more than time is shrinking, this is more sensible in general
than it was a decade ago. Given Javascript programs are usually small
and work with small objects, this is even more sensible for Javascript
than for some Python programs.

2. It compiles to object code rather than byte code. If the only target
is standard 32/64 bit Intel/AMD processors, this is quite sensible. Does
V8 have, for instance, Cray versions?

Guido wants the reference version to be runnable on everything with a C
compiler and maintainable and upgradeable by volunteers who are not
assembler experts (which I believe are getting more rare).

tjr

From: Stefan Behnel on
Paul Rubin, 17.01.2010 05:06:
> David Cournapeau writes:
>
>> And certainly, one of the big reason for
>> the python success is easy interface with C. Maybe interfacing with C
>> is the real reason for holding back python implementations ?
>
> The CPython/C API is not terrible but it's not all that easy to use.
> For example, it's very easy to make reference counting errors. Other
> language FFI's that I've used avoid that problem to some extent.

Other languages don't have Cython.


> It's true that CPython has quite a few existing C modules that would require
> rework if the API were to change incompatibly.

"quite a few" sounds a bit too weak here. Some of the existing C extensions
have become reasons to use Python in the first place. Think of NumPy, for
example, and the whole scipy environment. Think of the
performance-to-usability ratio of cElementTree and lxml. Think of the huge
body of Cython code in Sage. Imagine what the set of dbm modules (or even
the entire standard library) would be without external C libraries and C
extensions.

The C-API and the ton of modules that use it are pretty vital for Python.
AFAICT, Py3 is pretty much a virgin platform when it comes to scientific
computing, mostly because NumPy still wasn't adapted to the changes in the
C-API. They even consider rewriting parts of it in Cython a simpler way to
solve this issue than trying to port the code itself. This shows that any
change to that API may have a tremendous effect on the usability of Python
as a whole.


> But I think a different
> (better) API wouldn't stop people from writing new modules.

"Writing new modules" may not be enough.

Stefan
From: Blog on
On 1/12/2010 9:09 PM, ikuta liu wrote:
> I'm a little confused.
> Is python not good enough?
> for google, enhance python performance is the good way better then
> choose build Go language?
>
> Go language try to merge low level, hight level and browser language.
>
> Those I'd like to see it on python..
Have you not heard about the "Unladen Swallow" project from google?
There's a new PEP coming up which will propose google's codebase to be
merged with Py3k, resulting in superior performance.