python speed

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.

/David

Nov 30 '05 #6

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

Nov 30 '05 #7

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

Nov 30 '05 #8

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... :)
/David

Nov 30 '05 #9

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.

STeVe

Nov 30 '05 #10

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

Nov 30 '05 #11

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

Nov 30 '05 #12

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

Nov 30 '05 #13

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

Nov 30 '05 #14

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 +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

Nov 30 '05 #15

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

Nov 30 '05 #16

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

Nov 30 '05 #17

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

Nov 30 '05 #18

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('@')])"

Nov 30 '05 #19

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

Nov 30 '05 #20

Peter Hansen wrote:

True, but so what? Why did you suddenly change the discussion to
require "pure" Python?
Well, comments about Python's speed usually come in the following two
forms: some Python-based solution isn't fast enough; programs written
in Python aren't fast enough. In other words, they arise either from
specific situations or from general observations gained from running
programs written only in Python (from the author's perspective, without
having written C/Pyrex/Boost extensions).
And please define "pure" Python, given that the interpreter and many builtins, not
to mention many widely used extension modules, are coded in C? From the point of view of an application developer, a "pure" Python solution could be one where they only wrote Python code. Of course, I
can claim to deliver various solutions in "pure" Python, knowing that
some extension module that I didn't write will be doing all the hard
work, but it's useful to think of deployment complications: how easy
would it be for me to deploy my application on some obscure platform
that Python runs on? A "pure" Python solution would have limited
extension module dependencies and thus be relatively easy to deploy,
whereas a reliance on a module that hasn't been ported to RISC OS, for
example, would severely impair portability.
And are you not allowed to use any of the performance-boosting techniques
available for Python, like Pyrex or Psyco?
Well, from the point of view of an application developer, writing Pyrex
isn't quite the same as writing Python. There are variants of Java that
change the semantics of the language in order to achieve better
performance or certain run-time guarantees, but no-one would honestly
claim that they would be writing "pure" Java if they were really coding
for those variants.

Psyco is admittedly a tool that provides improved performance with
compatible semantics within the Python toolset. I'm not familiar with
its effect on all kinds of programs, however, but if performance was a
critical factor for a system, I wouldn't begrudge anyone from using
Psyco.

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

This remark is somewhat ridiculous given that the Java virtual machine
is suitably designed/specified to permit just-in-time complication.
Running Java programs on some interpreter seems like an arbitrary and
absurd exercise, especially when, by engaging in the process of writing
Java, one has already abandoned some high-level language semantics in
order to exploit the performance benefits of the virtual machine
architecture.

Sure, Python-oriented systems can be faster than Java-oriented systems,
or indeed many other kinds of systems, but such posturing on the notion
of "purity" would seem to suggest a denial of any need for an
investigation into the benefits of improved run-time performance for
programs written in Python - a view which contradicts the work done by
the most prominent project in this field, whilst reinforcing various
community perceptions and attitudes that unjustifiably consign
worthwhile work on this topic to the fringes.

Paul

Nov 30 '05 #21

Carsten Haese

On Wed, 2005-11-30 at 14:53, Paul Boddie wrote:

[...] the Java virtual machine
is suitably designed/specified to permit just-in-time complication.

+1 Freudian slip of the week :)

-Carsten Haese

Nov 30 '05 #22

igouy

Paul Boddie wrote:

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

For example, binary trees
http://shootout.alioth.debian.org/gp...trees&lang=all

Nov 30 '05 #23

Peter Hansen wrote:

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

That form of argument is listed as one of the principal forms of
illogical thinking in "Being Logical" D.Q.McInerny - "An Inability to
Disprove Does Not Prove"

"The fact that there is no concrete proof against a position does not
constitute an argument in favour of the position. I cannot claim to be
right simply because you can't prove me to be wrong."

Nov 30 '05 #24

Peter Hansen

Isaac Gouy wrote:

Peter Hansen wrote:
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.
That form of argument is listed as one of the principal forms of
illogical thinking in "Being Logical" D.Q.McInerny - "An Inability to
Disprove Does Not Prove"
Good thing this is the form of argument *against* which I was arguing,
rather than that which I choose to use myself. (Read very carefully, if
you really think I was saying otherwise, and point out exactly where I
made any such claims for my own part. In fact, I was referencing the
arguments of others -- who *were* supporting their arguments with facts,
as near as I can tell -- and I was calling on the opposition to do the
same, and without changing the rules mid-discussion.)
"The fact that there is no concrete proof against a position does not
constitute an argument in favour of the position. I cannot claim to be
right simply because you can't prove me to be wrong."

Isn't that what I was saying? That those who claim Python isn't faster
were not supporting their arguments with actual facts?

-Peter

Nov 30 '05 #25

Mike Meyer

"Harald Armin Massa" <ha**************@gmail.com> writes:

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.

Chances are, version 1 of the system doesn't have the command. Version
2 does, but it's no better than the obvious hand-coded loop. Version 3
finally makes it faster than the hand-coded loop, if you assume you
have the instruction. If you have to test to see if you can use it,
the hand-coded version is equally fast. Version 4 makes it faster even
if you do the test, so you want to use it if you can. Of course, by
then there'll be a *different* command that can do the same thing,j and
is faster in some conditions.

Dealing with this in assembler is a PITA. If you're generating code on
the fly, you generate the correct version for the CPU you're running
on, and that's that. It'll run at least as fast as hand-coded
assembler on every CPU, and faster on some.

If you wire everything down, you can always hand-code assembler that
will be faster than HLL code (though even sharp programmers can miss
tricks the compiler won't). But things don't stay wired down - the CPU
gets upgraded, caches change size, pages change size, the data gets
bigger, etc. Hand-tuned code doesn't deal well with such, whereas
generated code can be made to do just that.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Nov 30 '05 #26

Donn Cave

In article <86************@bhuda.mired.org>, Mike Meyer <mw*@mired.org>
wrote:

"Harald Armin Massa" <ha**************@gmail.com> writes:
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.

Chances are, version 1 of the system doesn't have the command. Version
2 does, but it's no better than the obvious hand-coded loop. Version 3
finally makes it faster than the hand-coded loop, if you assume you
have the instruction. If you have to test to see if you can use it,
the hand-coded version is equally fast. Version 4 makes it faster even
if you do the test, so you want to use it if you can. Of course, by
then there'll be a *different* command that can do the same thing,j and
is faster in some conditions.

Dealing with this in assembler is a PITA. If you're generating code on
the fly, you generate the correct version for the CPU you're running
on, and that's that. It'll run at least as fast as hand-coded
assembler on every CPU, and faster on some.

Actually I think the post you quote went on to make a similar
point.

I read yesterday morning in the paper that the Goto Basic Linear
Algebra Subroutines, by a Mr. Kazushige Goto, are still the most
efficient library of functions for their purpose for use in
supercomputing applications. Apparently hand-optimized assembler
for specific processors.
http://seattlepi.nwsource.com/busine...70_goto29.html
(actually from the NY Times, apparently)

Donn Cave, do**@u.washington.edu

Nov 30 '05 #27

Peter Hansen wrote:

Isaac Gouy wrote:
Peter Hansen wrote:
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.

That form of argument is listed as one of the principal forms of
illogical thinking in "Being Logical" D.Q.McInerny - "An Inability to
Disprove Does Not Prove"

Good thing this is the form of argument *against* which I was arguing,
rather than that which I choose to use myself. (Read very carefully, if
you really think I was saying otherwise, and point out exactly where I
made any such claims for my own part. In fact, I was referencing the
arguments of others -- who *were* supporting their arguments with facts,
as near as I can tell -- and I was calling on the opposition to do the
same, and without changing the rules mid-discussion.)
"The fact that there is no concrete proof against a position does not
constitute an argument in favour of the position. I cannot claim to be
right simply because you can't prove me to be wrong."

Isn't that what I was saying? That those who claim Python isn't faster
were not supporting their arguments with actual facts?

-Peter

*Python is faster than Java. Let those who believe otherwise prove
their point with facts*

We must be looking at different threads :-)

afaict the only posting that provided something like "facts" was
http://groups.google.com/group/comp....9e439697279060

Which stated "Python is doing the heavy lifting with GMPY which is a
compiled C program with a Python wrapper" - but didn't seem to compare
that to GMPY with a Java wrapper?

Nov 30 '05 #28

Peter Hansen

Donn Cave wrote:

I read yesterday morning in the paper that the Goto Basic Linear
Algebra Subroutines, by a Mr. Kazushige Goto, are still the most
efficient library of functions for their purpose for use in
supercomputing applications. Apparently hand-optimized assembler
for specific processors.
http://seattlepi.nwsource.com/busine...70_goto29.html
(actually from the NY Times, apparently)

"Goto No Longer Considered Harmful" ?

;-)

Nov 30 '05 #29

Carsten Haese wrote:

On Wed, 2005-11-30 at 14:53, Paul Boddie wrote:
[...] the Java virtual machine
is suitably designed/specified to permit just-in-time complication.

+1 Freudian slip of the week :)

Well, I never said it was easy. ;-)

Paul

Nov 30 '05 #30

mensanator

Isaac Gouy wrote:

Peter Hansen wrote:
Isaac Gouy wrote:
Peter Hansen wrote:
>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.

That form of argument is listed as one of the principal forms of
illogical thinking in "Being Logical" D.Q.McInerny - "An Inability to
Disprove Does Not Prove"

Good thing this is the form of argument *against* which I was arguing,
rather than that which I choose to use myself. (Read very carefully, if
you really think I was saying otherwise, and point out exactly where I
made any such claims for my own part. In fact, I was referencing the
arguments of others -- who *were* supporting their arguments with facts,
as near as I can tell -- and I was calling on the opposition to do the
same, and without changing the rules mid-discussion.)
"The fact that there is no concrete proof against a position does not
constitute an argument in favour of the position. I cannot claim to be
right simply because you can't prove me to be wrong."

Isn't that what I was saying? That those who claim Python isn't faster
were not supporting their arguments with actual facts?

-Peter

*Python is faster than Java. Let those who believe otherwise prove
their point with facts*

We must be looking at different threads :-)

afaict the only posting that provided something like "facts" was
http://groups.google.com/group/comp....9e439697279060

Which stated "Python is doing the heavy lifting with GMPY which is a
compiled C program with a Python wrapper" - but didn't seem to compare
that to GMPY with a Java wrapper?

Is there such an animal? I only know about Java's BigInteger.
And if there is, it just proves my point that benchmarks are
worthless.

Nov 30 '05 #31

elbertlev

Isaac Gouy wrote:

Which stated "Python is doing the heavy lifting with GMPY which is a
compiled C program with a Python wrapper" - but didn't seem to compare
that to GMPY with a Java wrapper?

You are missing the main idea: Java is by design a general purpose
programming language. That's why all "GMPYs" and alike are written in
Java - now wrappers to C-libraries. Python, by design, is glue
language. Python program is assembly of C extensions and buildins
wrapped in Python sintax.

IHMO "real life" benchmark yuo are critisizing represents real life
situation.

Dec 1 '05 #32

Leif K-Brooks

Krystian wrote:

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?

If <http://www.abrahamjoffe.com.au/ben/canvascape/> can run at a
reasonably speed, yes.

Dec 1 '05 #33

Mike Meyer wrote:

If you wire everything down, you can always hand-code assembler that
will be faster than HLL code

but that doesn't mean that your hand-coded assembler will always be faster
than an HLL implementation that addresses the same problem:

http://mail.python.org/pipermail/pyt...er/004519.html

"Pure Python division is 16x slower than GMP but can actually
be faster in some instances; for example, dividing a 2,000,000
digit number by an 800,000 digit number"

</F>

Dec 1 '05 #34

Luis M. Gonzalez

Pypy is not the only promisory project we have for seeing Python
running like compiled languages.

Shed Skin is already a quite usable Python-to-C++ compiler which, in
version 0.5.1, can actually compile many python scripts to fully
optimized stand-alone executables.
Next version will probably support the use of the standard python
library and many, many exciting enhancements.

The main difference between these two projects is that while PYPY aims
to support 100% of python semantics including (all its dynamic
features) on top of a virtual machine. It uses type inference for
static compilation and just-in-time techniques.
On the other hand, Shed Skin is purely a static compiler that
translates python to c++ and then compiles to a stand alone executable.
It will never support the most dynamic features of Python, but in most
cases, it only requires to restrict our coding style a little bit to
avoid these features and produce highly optimized code.

http://shedskin.sf.net
http://shed-skin.blogspot.com/

Dec 1 '05 #35

el*******@hotmail.com wrote:

Isaac Gouy wrote:
Which stated "Python is doing the heavy lifting with GMPY which is a
compiled C program with a Python wrapper" - but didn't seem to compare
that to GMPY with a Java wrapper?

You are missing the main idea: Java is by design a general purpose
programming language. That's why all "GMPYs" and alike are written in
Java - now wrappers to C-libraries. Python, by design, is glue
language. Python program is assembly of C extensions and buildins
wrapped in Python sintax.

IHMO "real life" benchmark yuo are critisizing represents real life
situation.

"1.1.3 What is Python good for?
Python is a high-level general-purpose programming language that can be
applied to many different classes of problems."

http://www.python.org/doc/faq/genera...ython-good-for

Dec 1 '05 #36

me********@aol.com wrote:

Isaac Gouy wrote:
Peter Hansen wrote:
Isaac Gouy wrote:
> Peter Hansen wrote:
>>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.

> That form of argument is listed as one of the principal forms of
> illogical thinking in "Being Logical" D.Q.McInerny - "An Inability to
> Disprove Does Not Prove"

Good thing this is the form of argument *against* which I was arguing,
rather than that which I choose to use myself. (Read very carefully, if
you really think I was saying otherwise, and point out exactly where I
made any such claims for my own part. In fact, I was referencing the
arguments of others -- who *were* supporting their arguments with facts,
as near as I can tell -- and I was calling on the opposition to do the
same, and without changing the rules mid-discussion.)

> "The fact that there is no concrete proof against a position does not
> constitute an argument in favour of the position. I cannot claim to be
> right simply because you can't prove me to be wrong."

Isn't that what I was saying? That those who claim Python isn't faster
were not supporting their arguments with actual facts?

-Peter
*Python is faster than Java. Let those who believe otherwise prove
their point with facts*

We must be looking at different threads :-)

afaict the only posting that provided something like "facts" was
http://groups.google.com/group/comp....9e439697279060

Which stated "Python is doing the heavy lifting with GMPY which is a
compiled C program with a Python wrapper" - but didn't seem to compare
that to GMPY with a Java wrapper?

Is there such an animal? I only know about Java's BigInteger.

Google.

http://dev.i2p.net/javadoc/net/i2p/u...igInteger.html
And if there is, it just proves my point that benchmarks are
worthless.

How so?

Dec 1 '05 #37

Cameron Laird

In article <11**********************@g49g2000cwa.googlegroups .com>,
<el*******@hotmail.com> wrote:

Isaac Gouy wrote:
Which stated "Python is doing the heavy lifting with GMPY which is a
compiled C program with a Python wrapper" - but didn't seem to compare
that to GMPY with a Java wrapper?

You are missing the main idea: Java is by design a general purpose
programming language. That's why all "GMPYs" and alike are written in
Java - now wrappers to C-libraries. Python, by design, is glue

Dec 1 '05 #38

Mike Meyer

"Fredrik Lundh" <fr*****@pythonware.com> writes:

Mike Meyer wrote:
If you wire everything down, you can always hand-code assembler that
will be faster than HLL code but that doesn't mean that your hand-coded assembler will always be faster
than an HLL implementation that addresses the same problem:

True. But you can always recode the assembler to make it faster than
the HLL for the case at hand, possibly making it worse in other cases.
http://mail.python.org/pipermail/pyt...er/004519.html
"Pure Python division is 16x slower than GMP but can actually
be faster in some instances; for example, dividing a 2,000,000
digit number by an 800,000 digit number"

This isn't the case I outlined, though. This is general-purpose
assembler package, not assembler code designed specifically for
dividing a 2,000,000 digit number by an 800,000 digit number.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Dec 1 '05 #39

Cameron Laird wrote:

You are missing the main idea: Java is by design a general purpose
programming language. That's why all "GMPYs" and alike are written in
Java - now wrappers to C-libraries. Python, by design, is glue

.
I don't understand the sentence, "That's why all 'GMPYs' and alike ..."
Are you saying that reuse of code written in languages other than Java
is NOT important to Java? I think that's a reasonable proposition; I'm
just having trouble following your paragraph.

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>

Dec 1 '05 #40

Fredrik Lundh wrote:

Cameron Laird wrote:
You are missing the main idea: Java is by design a general purpose
programming language. That's why all "GMPYs" and alike are written in
Java - now wrappers to C-libraries. Python, by design, is glue

.
I don't understand the sentence, "That's why all 'GMPYs' and alike ..."
Are you saying that reuse of code written in languages other than Java
is NOT important to Java? I think that's a reasonable proposition; I'm
just having trouble following your paragraph.

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? :-)

Dec 1 '05 #41

Isaac Gouy wrote:

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)

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>

Dec 1 '05 #42

Fredrik Lundh wrote:

Isaac Gouy wrote:
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)
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>

el*******@hotmail.com wrote: Python program is assembly of C extensions and buildins
wrapped in Python sintax.

Dec 1 '05 #43

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.

Dec 2 '05 #44

ca****@comcast.net wrote:

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>

Dec 2 '05 #45

Steve Holden wrote:

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.

I've answered this question elsewhere in the thread.

/David

Dec 6 '05 #46

Harald Armin Massa wrote:

Faster than assembly? LOL... :)

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

Dec 6 '05 #47

Peter Hansen 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?

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

Dec 6 '05 #48