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

 

[Aahz]

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.

Why would we want Python to be as fast as Java when it's already faster?

Take a look at PyGame.

 

[Krystian]

Hi

Why would we want Python to be as fast as Java when it's already faster?

hm... i came across this site:
http://shootout.alioth.debian.org/benchmark.php?test=all&lang=java&lang2=python&sort=fullcpu

could you take an attitude with regard to this benchmark?

Take a look at PyGame.

on my way

best
k

 

[mensanator]

Hi


hm... i came across this site:
http://shootout.alioth.debian.org/benchmark.php?test=all&lang=java&lang2=python&sort=fullcpu

could you take an attitude with regard to this benchmark?

Benchmarks are worthless. By that I mean they have no value
to me. What matters is the performance on real problems, such
as generating the 1st 6th Generation Type [1,2] Mersenne Hailstone
Collatz sequence.

That's a BIG number and needs BIG arithmetic to solve. Java has
a BigInteger module and can solve it in less than 10 minutes:

C:\Python23\user\pyjava>java Collatz 2 177149 1

Processing time: 571690
x/2 iterations: 1531812
3x+1 iterations: 854697

The arguments evaluate to 2**177149-1. And because this is a
Mersenne number, the sequence diverges until it's over 280000 bits
before converging to 1 bit after 2386509 iterations.

But is 571 seconds a reasonable amount of time for such a difficult
problem?

Compare it to Python with the GMPY module:

C:\Python23\user\pyjava>collatz.py 2 177149 1
r1 1531812 r2 854697 in 72.9869999886 seconds

Yes, it would appear that in this real world application Java is
ridiculously slow. Of course, Python is doing the heavy lifting
with GMPY which is a compiled C program with a Python
wrapper. But so what? Maybe the reason I use Python is
BECAUSE the math module is compiled C. Duh. With Python/GMPY
I get the high level power I need for the algorithms without
sacrificing the low level muscle I need for the heavy arithmetic.

 

[Frithiof Andreas Jensen]

Hi
are there any future perspectives for Python to be as fast as java?

Sure, if/when Python becomes as water-logged with obtruse OO-layers as Java
is now.

Python is faster than Java.

Because Python per design generally is a thin layer of glue poured over
binary C modules, it does not take very many instructions before one hits
the fastest speed that the platform can go at. I would test it, then worry
about it.

i would like to use Python as a language for writing games.

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

 

[David Rasmussen]

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.

/David

 

[Krystian]

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

or even quake1, do you think it could have any chances to run
smoothly? or maybe demoscene productions...

 

[Harald Armin Massa]

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.

But whatever, the pypy-team is formed out of some more people of his
calibre and founded by the European Union to provide "butter by the
fish", say, to produce real code that may deliver that promise.

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.

For the time being, my Python programs just sit and wait for database,
network, user input or the acting of COM-Applications like Excel or
Winword. Sometimes I even have 3 threads, one to wait for user, one for
database and one to wait for Excel - boy, I wait fast!

But on the other hand, I do no real world applications like triple
mersenne first person shooters, only business software like the one
which in earlier time was written in COBOL or carved into cave walls.
Less challenge, higher reward.

Harald

 

[David Rasmussen]

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


/David

 

[Steven Bethard]

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.

STeVe

 

[Paul Boddie]

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]

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]

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,
partyparallelexecution, branchprediction, out of order execution,
multilevelcaching, hypermetathreading ... 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]

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

 

[Fredrik Lundh]

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,
partyparallelexecution, branchprediction, out of order execution,
multilevelcaching, hypermetathreading ... 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>

 

[Carl Friedrich Bolz]

Hi!

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]

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

 

[bruno at modulix]

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 !-)

 

[Paul Boddie]

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