python speed

[Andreas Kostyrka]

Am Mittwoch, den 30.11.2005, 08:15 -0700 schrieb Steven Bethard:
> David Rasmussen wrote:
> > Harald Armin Massa wrote:
> > 
> >> Dr. Armin Rigo has some mathematical proof, that High Level Languages
> >> like esp. Python are able to be faster than low level code like
> >> Fortran, C or assembly.
> > 
> > Faster than assembly? LOL... :)
> 
> I think the claim goes something along the lines of "assembly is so hard 
> to get right that if you can automatically generate it from a HLL, not 
> only will it be more likely to be correct, it will be more likely to be 
> fast because the code generator can provide the appropriate optimizations".
> 
> OTOH, you can almost certainly take automatically generated assembly 
> code and make optimizations the code generator wasn't able to, thanks to 
> knowing more about the real semantics of the program.

Well, it's easy enough to "prove".

Take one aspect of Python: Automatic memory management via reference
counting.

Now, while it's certainly possible to implement exactly what Python does
in C++ (both are turing complete, ...), the normal and idiomatic way is
to have APIs that care about object ownership. The normal idiomatic way
is relevant, as third-party libraries usually force one to develop this
way.

Now, APIs with a static object ownership relationship are the norm in 
C++ land. By this I mean, that a function like:

obj *func(obj2 *o2, obj3 *o3)

has a static behaviour when it comes to object ownership.

Either it always takes care of o2, which means that it has to free it
anyway, which means that a caller that wants to keep it has to copy it, 
or it never takes care of o2, which means that an implementation of func
that needs to keep a copy of o2 needs to copy it.

Now the obvious answer is, use a reference counting pointer type.
Problem here: It's probably an external reference counter, or it is not
generic:

[refptr]
 count
 ptr      --->  [object]
                 data

Which means two objects to allocate, two levels of indirection, etc.

And it might not work in many contexts where there is already existing
code that needs to interface with it. Even more difficult is the task to
use an inobject refcounter.

In Python on the other hand,

def func(o2, o3):

func can keep a o2 or not, and nobody cares. Actually the fact if o2 is
kept or not, might be runtime dependant.

To summerize, in complex applications, the better runtime fundation of
languages like Python might lead to situations where Python is faster
then C/C++.

If one takes additionally the developer-costs into this comparisation
(which is a relevant metric in 95% of code developed), the Python
solution has the additional benefit, that it allows us to implement more
complicated and faster algorithms, because the language is so much
higher level and more productive.

OTOH, almost languages are turing-complete, meaning that you can do
anything you can do in Python in C, C++ or Assembler. Just don't tell me
that it is usual to write self-modifying assembler programs that create
an optimized piece of code for combinations of argument types, like
Psyco does.

Andreas



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://mail.python.org/pipermail/python-list/attachments/20051229/8acf9189/attachment.sig>