python speed

[Paul Boddie]

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

 

[Carsten Haese]

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

+1 Freudian slip of the week

-Carsten Haese

 

[igouy]

Faster than physics? ;-)

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/gp4/benchmark.php?test=binarytrees&lang=all

 

[Isaac Gouy]

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

 

[Peter Hansen]

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

 

[Mike Meyer]

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

 

[Donn Cave]

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.[/QUOTE]

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/business/250070_goto29.html
(actually from the NY Times, apparently)

Donn Cave, (e-mail address removed)

 

[Isaac Gouy]

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


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.lang.python/msg/309e439697279060

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?

 

[Peter Hansen]

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/business/250070_goto29.html
(actually from the NY Times, apparently)

"Goto No Longer Considered Harmful" ?

;-)

 

[Paul Boddie]

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

 

[mensanator]

*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.lang.python/msg/309e439697279060

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.

 

[elbertlev]

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.

 

[Leif K-Brooks]

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.

 

[Fredrik Lundh]

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/python-announce-list/2005-November/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>

 

[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/

 

[Isaac Gouy]

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/general.html#what-is-python-good-for

 

[Isaac Gouy]

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

http://dev.i2p.net/javadoc/net/i2p/util/NativeBigInteger.html

And if there is, it just proves my point that benchmarks are
worthless.

How so?

 

[Cameron Laird]

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.

 

[Mike Meyer]

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/python-announce-list/2005-November/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

 

[Fredrik Lundh]

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