python speed

[Krystian]

Hi
are there any future perspectives for Python to be as fast as java? i
would like to use Python as a language for writing games.

best regards
krystian

[Paul Boddie]

Steven Bethard wrote:

David Rasmussen wrote:

Faster than assembly? LOL... :)

Faster than physics? ;-)
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".

I think this is just a restatement of existing motivations for using
high-level languages and compilers. My impression is that PyPy takes
inspiration from work which showed that run-time knowledge can
sometimes produce code that is better optimised than that produced by a
compiler.

That said, when everyone starts showing off their favourite benchmarks,
it might be more interesting not to parade some festival of arithmetic
yet again. Where more recent versions of the Java virtual machines have
improved is in their handling of object memory allocation, amongst
other things, and merely scoffing that Java is slow (by pulling
specific/specialised extension packages out of the hat) fails to
acknowledge the potential for similar improvements (and others) in
Python, especially where programs involving plain objects - as opposed
to numbers, and where no conveniently available and wrapped C/C++
package exists for the task - are concerned.

Paul

[Kay Schluehr]

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.

I am not wise enough to understand that proof.

Maybe I understood those papers totally wrong and he was saying
something totally different.

Here is a paper of Armin explaining his psycology:

http://psyco.sourceforge.net/theory_psyco.pdf

Heck, Python has at least one programmer who is computer scientist and
knows how to draw commutative diagrams :)

[Dave Brueck]

Steven Bethard wrote:

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.

Yeah, but the other important part of the claim has to do with just that: the
real [runtime] semantics of the program.

Hand optimization happens before runtime, obviously, whereas the HLL->assembly
conversion can happen once the program is running and more info is known about
the actual sets of data being operated on, the frequence of function calls, i.e.
where the need for optimization actually exists. The optimization could even
happen multiple times to adapt over time, or to allow multiple optimizations for
different classes of data so that the code that actually executes is highly
specialized.

So, yeah, knowledge of the runtime behavior can allow a hand-optimized version
to run faster than a static, automatically-generated version, but knowledge of
the runtime behavior could also allow a dynamic code generator to even beat the
hand-optimized version.

-Dave

[Harald Armin Massa]

>Faster than assembly? LOL... :)

why not? Of course, a simple script like "copy 200 bytes from left to
right" can be handoptimized in assembler and run at optimum speed.
Maybe there is even a special processor command to do that.

I learned that there was one generation of CPUs which had effectively a
command to copy X bytes from left to right; but a specific version of
that CPU did this command slower then a loop in certain situations.
Some newer generations of that CPU and even some competitors CPU had
that command implented correctly, and it was indeed faster than the
loop.

Now: is it rather likely that for a single programm a programmer is
able to get it right for all CPUs?

It even gets more complicated. The human mind is able to consider a
certain amount of things at once, sth. like on-chip-cache or
short-term-memory.

Now with an ever growing complexity of processors, with cache lines,
partyparallelex ecution, branchpredictio n, out of order execution,
multilevelcachi ng, hypermetathread ing ... it may be that the usual
availaible human brain is no longer capable of really knowing what
happens.

My guess is that the average code speed of a Rigopy could indeed be
higher than the average code speed of the average assembler programmer.
Harald

[Steve Holden]

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 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.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Carl Friedrich Bolz]

Hi!

Harald Armin Massa wrote:

And I could see real development just from watching the BDFL: 3 years
ago PyPy was 2000times slower then CPython, and Guido was joking "and
that number is growing", this year there were not officially negated
romours that sometime maybe PyPy could be the reference implementation
of Python; and also reports that PyPy is only 18 times slower then
CPython.

well, currently PyPy is around 9-11 times slower than CPython. Since a
few weeks ago we are now able to switch stacklessness on and off at
compile time to be able to have an interpreter that supports very deeply
recursive algorithms, if that is needed.

Cheers,

Carl Friedrich Bolz

[Peter Hansen]

David Rasmussen wrote:

Frithiof Andreas Jensen wrote:

From the speed requirement: Is that correspondance chess by any chance??

Regular chess at tournament time controls requires speed too. Any pure
Python chess program would lose badly to the best C/C++ programs out
there now.

I would also like to see Half Life 2 in pure Python.

True, but so what? Why did you suddenly change the discussion to
require "pure" Python? And please define "pure" Python, given that the
interpreter and many builtins, not to mention many widely used extension
modules, are coded in C? And are you not allowed to use any of the
performance-boosting techniques available for Python, like Pyrex or
Psyco? 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++.

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"...?) .

Judging by the other posts in this thread, the gauntlet is down: Python
is faster than Java. Let those who believe otherwise prove their point
with facts, and without artificially handcuffing their opponents with
non-real-world "purity" requirements.

-Peter

[Fredrik Lundh]

Harald Armin Massa wrote:

Faster than assembly? LOL... :)

why not? Of course, a simple script like "copy 200 bytes from left to
right" can be handoptimized in assembler and run at optimum speed.
Maybe there is even a special processor command to do that.

I learned that there was one generation of CPUs which had effectively a
command to copy X bytes from left to right; but a specific version of
that CPU did this command slower then a loop in certain situations.
Some newer generations of that CPU and even some competitors CPU had
that command implented correctly, and it was indeed faster than the
loop.

Now: is it rather likely that for a single programm a programmer is
able to get it right for all CPUs?

It even gets more complicated. The human mind is able to consider a
certain amount of things at once, sth. like on-chip-cache or
short-term-memory.

Now with an ever growing complexity of processors, with cache lines,
partyparallelex ecution, branchpredictio n, out of order execution,
multilevelcachi ng, hypermetathread ing ... it may be that the usual
availaible human brain is no longer capable of really knowing what
happens.

global optimizers for non-C languages can sometimes produce faster code
than human C coders, also when those optimizers use C as an intermediate
language...

</F>

[bruno at modulix]

David Rasmussen wrote:

Frithiof Andreas Jensen wrote:

From the speed requirement: Is that correspondance chess by any chance??

Regular chess at tournament time controls requires speed too. Any pure
Python chess program would lose badly to the best C/C++ programs out
there now.

I would also like to see Half Life 2 in pure Python.

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.

And FWIW, I'd like to see any similar game in "pure" Java !-)
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"

[Paul Boddie]

Steven Bethard wrote:

David Rasmussen wrote:
Faster than assembly? LOL... :)
Faster than physics? ;-)
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".

I think this is just a restatement of existing motivations for using
high-level languages and compilers. My impression is that PyPy takes
inspiration from work which showed that run-time knowledge can
sometimes produce code that is better optimised than that produced by
a
compiler.

That said, when everyone starts showing off their favourite
benchmarks,
it might be more interesting not to parade some festival of arithmetic
yet again. Where more recent versions of the Java virtual machines
have
improved is in their handling of object memory allocation, amongst
other things, and merely scoffing that Java is slow (by pulling
specific/specialised extension packages out of the hat) fails to
acknowledge the potential for similar improvements (and others) in
Python, especially where programs involving plain objects - as opposed
to numbers, and where no conveniently available and wrapped C/C++
package exists for the task - are concerned.

Paul