python speed

[Isaac Gouy]

replace "now" with "not" or perhaps "instead of being implemented as",
and it may become a bit easier to parse.

and yes, the proposition matches my experiences. java heads prefer to do
everything in java, while us pythoneers happily mix and match whenever we
can... (which is why guoy's "benchmarks" says so little about Python; if you
cannot use smart algorithms and extensions where appropriate, you're not
really using Python as it's supposed to be used)

</F>

If you can't use C where appropriate, you're not really using Python as
it's supposed to be used?

 

[Fredrik Lundh]

If you can't use C where appropriate, you're not really using Python as
it's supposed to be used?

who's talking about C ? and what's the connection between C and smart
algorithms ?

</F>

 

[Isaac Gouy]

who's talking about C ? and what's the connection between C and smart
algorithms ?

</F>

 

[casevh]

DecInt's division algorithm is completely general also. But I would
never claim that Python code is faster than assembler. I believe that
careful implementation of a good algorithm is more important than the
raw speed of the language or efficiency of the compiler. Python makes
it easy to implement algorithms.

 

[Fredrik Lundh]

DecInt's division algorithm is completely general also. But I would
never claim that Python code is faster than assembler. I believe that
careful implementation of a good algorithm is more important than the
raw speed of the language or efficiency of the compiler. Python makes
it easy to implement algorithms.

that was of course the point here (and your work with DecInt is an
excellent illustration of this principle).

</F>

 

[David Rasmussen]

why not?

Because any program generated automatically by a compiler of any kind
can always be expressed in assembly langauge. That writing assembler for
many processors can be really hard to do well is beside the point. We're
talking about the best-case capabilities of a language. Writing programs
in other languages can be hard as well, not to mention writing a
compiler for any language that produces "as good as best assembly" code,
that is, optimal code.

/David

 

[David Rasmussen]

I don't see why this is so funny. A good C compiler with optimization
typically produces better code than an equivalent assembly language
program. As compilation techniques improve this gap is likely to widen.
There's less and less reason to use assembler language with each passing
year.

I've answered this question elsewhere in the thread.

/David

 

[David Rasmussen]

True, but so what?

So nothing. I was just commenting on the correspondance chess comment...
with a valid observation.

Why did you suddenly change the discussion to
require "pure" Python?

Because that's the only meaningful thing to discuss. If we're allowed to
use Python as a thin layer above C (a very important, practical and cool
feature), then we're measuring the speed of C, not Python. What would be
the point of that? I can already answer how fast that notion of Python
is: as fast as C.

And are you not allowed to use any of the
performance-boosting techniques available for Python, like Pyrex or
Psyco?

Of course.

Why such restrictions, when these are things Python programs use
on a daily basis: these are *part* of Python, as much as the -O switch
on the compiler is part of C/C++.

Because we're then measuring the speed of C, not Python. But if you want
to convey the point that Python can be used for arbitrarily performance
"hungry" problems, you're right. Just code the "fast" parts in C or
assembly language and apply a thin layer of Python on top. Lather,
rinse, repeat.

Okay, let's compare a "pure" Python program (if you can define it in any
meaningful, practical way) with a "pure" Java program, running on a
non-JIT interpreter and with optimizations turned off (because, of
course, those optimizations are umm... somehow.. not "pure"...?).

Says who? And why are you comparing to Java now? Java sucks.

Judging by the other posts in this thread, the gauntlet is down: Python
is faster than Java.

I don't disagree with that.

Let those who believe otherwise prove their point
with facts, and without artificially handcuffing their opponents with
non-real-world "purity" requirements.

You are the one getting theoretical and academic. I was just commenting
on the chess comment above, because it is a field that I have extensive
knowledge in. To make a real-word challenge to make my point obvious:

Write a chess program in Python and win more than 50% out of 100 games
against a good chess program (Crafty, Fritz, Chess Tiger etc.) playing
on the same hardware. In fact, just win one.

Now, if you write the "fast" parts in C, you obviously can solve this
problem, and easily. But then there is no reason to discuss Python's
speed ever. Just say "as fast as C" and code everything in C and make a
hookup in Python. In fact, why not just code it in C then?

/David

 

[David Rasmussen]

There's nothing like "pure" Python. Python depends on a lot of libs,
most of them being coded in C++ or C (or assembly FWIW). The common
scheme is to use Python for the logic and low-level libs for the
critical parts.

I know. But if a discussion like this is to have any meaning, then we're
talking about "algorithmic" or "calculative" code with native Python
constructs, not Python as a layer on another langauge. In that case,
we're measuring the speed of the other language, not Python.

And FWIW, I'd like to see any similar game in "pure" Java !-)

Me too

/David

 

[Andreas Kostyrka]

Am Mittwoch, den 30.11.2005, 08:15 -0700 schrieb Steven Bethard:

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




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDsyLGHJdudm4KnO0RArf1AKCRr/T9Gs93J2Q8BYNF8ldYk8GtIwCfSXJc
FoQ1fwq46cExHSLllFJcUWU=
=7IYN
-----END PGP SIGNATURE-----

 

[Jorgen Grahn]

[on research supposedly proving that Python is faster than C, Java and
Fortran and assembly]

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.

Your discussion is interesting but a bit misleading, because most function
calls in C++ don't involve ownership issues. Most parameters are passed by
value (for reasonably small things, copying on a warm stack is bloody fast!)
or by const reference, with the understanding that the callee doesn't steal
or borrow a reference to the object. Or, the whole thing is inlined.

Yes, it sometimes happens that you have to have weirder things happen to
your objects -- but only to a tiny fraction of them, not all of them as in
Python. I cannot see how that would make Python, in general, faster than
C++.

The normal idiomatic way
is relevant, as third-party libraries usually force one to develop this
way.

I never use third-party C++ libraries, but I can see how an overly complex,
obsolete and badly designed API (MFC, anone? Or CORBA monstrosities.) could
complicate this a lot. /This/ is an area where C++ and similar languages
lose to Python -- you have to be an expert to write reusable C++ APIs which
don't suck!

/Jorgen

 

[bearophileHUGS]

It seems that Java JDK 1.4 (-server) HotSpot compiler sometimes (in
this test, on this computer, etc.) can produce programs faster than C
and Fortran ones in n-body simulations and similar stuff:

http://shootout.alioth.debian.org/gp4/benchmark.php?test=nbody&lang=all
http://shootout.alioth.debian.org/gp4/benchmark.php?test=spectralnorm&lang=all

So maybe PyPy can become quite fast too.

Bye,
bearophile

 

[James Tanis]

Quite honestly I've never heard of java being faster than.. well..
anything. Faster than Python? I really doubt it. Their are several
libraries for game programming specifically as well as opengl, sdl, as
well as several different audio systems/daemons.. I'd suggest browsing
through the categories in python.org's module search engine.

Disclaimer P): The majority of generalizations have some amount of
exceptions, the java crack above was just my opinion - it was not
really intended to offend any java addicts out there (the poor,
miss-guided souls).

 

[Xavier Morel]

Quite honestly I've never heard of java being faster than.. well..
anything. Faster than Python? I really doubt it. Their are several
libraries for game programming specifically as well as opengl, sdl, as
well as several different audio systems/daemons.. I'd suggest browsing
through the categories in python.org's module search engine.

Disclaimer P): The majority of generalizations have some amount of
exceptions, the java crack above was just my opinion - it was not
really intended to offend any java addicts out there (the poor,
miss-guided souls).

While java is much slower than Python in developer-time (e.g. the time
it takes to generate a working app, and the number of lines involved),
(good) Java code running on the hotspot (JIT) VM is usually at least an
order of magnitude faster than the equivalent Python code, if not faster.

What's dog slow in Java is primarily the VM startup, and then the memory
bloating, but as far as execution speed goes, pure Java code is much
faster than pure Python much more often than the opposite (now that may
change with Pypy, but Pypy is not done yet)

Xavier