Python too slow?

[dongie.agnir]

I'm pretty new to Python, and even newer to Image/Video processing,
and trying to get started on a project similar to GRL Vienna's laser
marker. I found some sample code here http://janto.blogspot.com/2006/01/mo...in-python.html,
but after running the code with the included sample input file, it
seems quite slow (1-2 seconds from start to finish to do the 800 by
600 gif image).

Is there a better way to do color tracking, or is Python just too slow
as an interpreted language to do any effective color tracking?

[Bruno Desthuilliers]

do**********@gmail.com a écrit :

I'm pretty new to Python, and even newer to Image/Video processing,
and trying to get started on a project similar to GRL Vienna's laser
marker. I found some sample code here http://janto.blogspot.com/2006/01/mo...in-python.html,
but after running the code with the included sample input file, it
seems quite slow (1-2 seconds from start to finish to do the 800 by
600 gif image).

Is there a better way to do color tracking,

Not having any experience with this domain, I can't comment on this.

or is Python just too slow
as an interpreted language

Being "interpreted" is a quality of an implementation, not of a
language. And the reference implementation of Python (CPython) is not
interpreted, it's compiled to byte-code, which is then executed by a VM
(just like Java). So while CPython may possibly be too slow for your
application (it can indeed be somewhat slow for some tasks), the reasons
are elsewhere (hint: how can a compiler safely optimize anything in a
language so dynamic that even the class of an object can be changed at
runtime ?) ...

to do any effective color tracking?

[dongie.agnir]

Thanks for the clarification.

Though I was hoping someone could give me a definitive answer. I was
quite excited about this project initially, but seeing the actual
execute times was a big downer. Seeing that the original laser marker
by GRL Vienna is done in Processing which from what I know is built on
Java, I was hoping that Python would be up to a similar task.

[Christian Heimes]

do**********@gmail.com wrote:

I'm pretty new to Python, and even newer to Image/Video processing,
and trying to get started on a project similar to GRL Vienna's laser
marker. I found some sample code here http://janto.blogspot.com/2006/01/mo...in-python.html,
but after running the code with the included sample input file, it
seems quite slow (1-2 seconds from start to finish to do the 800 by
600 gif image).

Have you profiled your application? Do you know the bottle necks and the
reason for the bottle necks? Is your application IO, memory or CPU
bound? Have you considered rewriting the bottle necks in C?

Christian

[Ben Finney]

Christian Heimes <li***@cheimes.dewrites:

do**********@gmail.com wrote:

[...] after running the code with the included sample input file,
it seems quite slow (1-2 seconds from start to finish to do the
800 by 600 gif image).

Have you profiled your application? Do you know the bottle necks and
the reason for the bottle necks? Is your application IO, memory or
CPU bound? Have you considered rewriting the bottle necks in C?

All good questions. Another important one: Is the startup time of the
Python process (i.e. before executing any of the actual statements in
the program) a significant part of the total time in this case?

--
\ "In the long run, the utility of all non-Free software |
`\ approaches zero. All non-Free software is a dead end." —Mark |
_o__) Pilgrim |
Ben Finney

[bruno.desthuilliers]

On 9 jan, 21:46, "[e-mail]" <[e-mail]>
wrote:

Thanks for the clarification.

Though I was hoping someone could give me a definitive answer.

Sorry - but I'm definitively not the right person on this...

I was
quite excited about this project initially, but seeing the actual
execute times was a big downer. Seeing that the original laser marker
by GRL Vienna is done in Processing which from what I know is built on
Java, I was hoping that Python would be up to a similar task.

Java's declarative static typing allow agressive just-in-time
optimizations - which is not the case in Python due to it's higly
dynamic nature[1]. You may want to have a look at psyco (a JIT
compiler) or to look for other angles (if there's any - IIRC the
example you're talking about already uses at least PIL for image
processing and something like scipy or numpy for intensive math ops).

If none of the two above answers fits your needs, and no Python Guru
comes with a better answer, then I'm afraid you'll have to go for a
language with a faster implementation. Python is quite faster nowadays
than it used to be, and is usually fast enough for most day-to-day
programming tasks (a, but it's still not as highly optimized as some
Lisp implementations (to compare to another highly

[1] you can read more on this on the pypy website, and specially here
IIRC: http://codespeak.net/pypy/dist/pypy/...anslation.html)

[Ed Jensen]

Bruno Desthuilliers <bd*****************@free.quelquepart.frwrote:

And the reference implementation of Python (CPython) is not
interpreted, it's compiled to byte-code, which is then executed by a VM
(just like Java).

Wow, this is pretty misleading.

Java is, indeed, compiled to bytecode; however, modern JVMs typically
compile the bytecode to native code and then execute the native code.

CPython strictly interprets bytecode; it does not compile the
bytecode to native code.

[Bruno Desthuilliers]

Ed Jensen a écrit :

Bruno Desthuilliers <bd*****************@free.quelquepart.frwrote:

>And the reference implementation of Python (CPython) is not
interpreted, it's compiled to byte-code, which is then executed by a VM
(just like Java).

Wow, this is pretty misleading.

Ho yes ??? Why so, please ? Care to point to anything *wrong* in the
above statement ?

Java is, indeed, compiled to bytecode; however, modern JVMs typically
compile the bytecode to native code and then execute the native code.

Which is known as JIT compilation - and there are a couple attempts at
it in Python too.

Anyway, the JIT compiler is not part of the Java spec (while the
byte-code/VM is), and its not garanteed to be there on each an every
Java VM.

CPython strictly interprets bytecode;

And ?

it does not compile the
bytecode to native code.

And ?

I fail to see how the existence of JIT compilers in some Java VM changes
anything to the fact that both Java (by language specification) and
CPython use the byte-code/VM scheme.

[A.T.Hofkamp]

On 2008-01-09, do**********@gmail.com <do**********@gmail.comwrote:

I'm pretty new to Python, and even newer to Image/Video processing,
and trying to get started on a project similar to GRL Vienna's laser
marker. I found some sample code here http://janto.blogspot.com/2006/01/mo...in-python.html,
but after running the code with the included sample input file, it
seems quite slow (1-2 seconds from start to finish to do the 800 by
600 gif image).

Is there a better way to do color tracking, or is Python just too slow
as an interpreted language to do any effective color tracking?

People seem quite obsessed with execution speed of CPU's.

I have come to believe that it is only one part of the equation, development
time and ease of maintenance or modification is another one, which I believe is
much more interesting to perform as fast as possible.

1-2 seconds may be slower than some alternative solution (you could in
principle develop custom hardware for it, and do the trick in a few
nano-seconds). The question that arises (for me at least) is, how fast can you
write, maintain, and modify what you want in that other solution.

Suppose you can do color-tracking in 0.5 seconds. So, you gained 1.5
seconds CPU time.
Now the question you need to answer for yourself, is how much more worth is
your own time compared to the gain in CPU time. If you think they are equal (ie
the problem as a whole should be solved as fast as possible, thus the sum of
development time + execution time should be as short as possible), you can
spend an additional 1.5 seconds development in the alternative solution.

Of course, if you do more color-tracking, the differences between alternative
solutions become larger, and your custom hardware solution may become a
feasible alternative.... :)

In my experience however, differences in CPU execution time are usually
meaningless compared to differences in development time.
Albert

[Jeroen Ruigrok van der Werven]

-On [20080110 11:46], A.T.Hofkamp (ha*@se-162.se.wtb.tue.nl) wrote:

>In my experience however, differences in CPU execution time are usually
meaningless compared to differences in development time.

I have to disagree with you to a point.

Yes, maintenance of code is important, no denying that. However, if I can
calculate N variations of a certain material's properties in an hour and using
Python will cut that in half, the number of calculated variations per hour, I
will be concerned.

This is especially so for people designing, say, optics. If you look at the
amount of optimizing designs and calculating the resulting properties and
doing this for X iterations in a day it becomes quite painfully obvious that
raw CPU execution time *does* matter.

't All varies with what you want, of course...

--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org/ asmodai
イェルーン ラウフãƒ*ック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
When you have eliminated the impossible, whatever remains, however
improbable, must be the truth...

[dongie.agnir]

For the most part, I agree with you, which is why I chose Python in
the first place. I like quick development. Unfortunately, this is
one of those cases where execution time is a factor. Who knows, maybe
someone who's done camera vision with Python will come in and say it's
just the algorithm in the example that needs work (I'm crossing my
fingers that that's the case).

[Ant]

On Jan 10, 12:04 pm, "[e-mail]" <[e-mail]>
wrote:

For the most part, I agree with you, which is why I chose Python in
the first place. I like quick development. Unfortunately, this is
one of those cases where execution time is a factor. Who knows, maybe
someone who's done camera vision with Python will come in and say it's
just the algorithm in the example that needs work (I'm crossing my
fingers that that's the case).

It would probably be worth reposting your question with a different
subject line. Something along the lines of "Image/Video processing
performance in Python", and explaining what you actually want to
achieve. "Python too slow?" doesn't give enough information - clearly
Python is fast enough for many many tasks, since it is so widely used.
It also sounds like a troll - so many people who would actually be
able to assist you (such as the PIL, pygame and numpy/scipy
communities) may have ignored this thread.

Cheers,

--
Ant.

[dongie.agnir]

On Jan 10, 3:00 am, Ant <[e-mail]:

On Jan 10, 12:04 pm, "[e-mail]" <[e-mail]>
wrote:

For the most part, I agree with you, which is why I chose Python in
the first place. I like quick development. Unfortunately, this is
one of those cases where execution time is a factor. Who knows, maybe
someone who's done camera vision with Python will come in and say it's
just the algorithm in the example that needs work (I'm crossing my
fingers that that's the case).

It would probably be worth reposting your question with a different
subject line. Something along the lines of "Image/Video processing
performance in Python", and explaining what you actually want to
achieve. "Python too slow?" doesn't give enough information - clearly
Python is fast enough for many many tasks, since it is so widely used.
It also sounds like a troll - so many people who would actually be
able to assist you (such as the PIL, pygame and numpy/scipy
communities) may have ignored this thread.

Cheers,

--
Ant.

Thanks for the advice. I'll do that now.

[Fredrik Lundh]

A.T.Hofkamp wrote:

Now the question you need to answer for yourself, is how much more worth is
your own time compared to the gain in CPU time. If you think they are equal (ie
the problem as a whole should be solved as fast as possible, thus the sum of
development time + execution time should be as short as possible), you can
spend an additional 1.5 seconds development in the alternative solution.

so you only run your programs once?

</F>

[George Sakkis]

On Jan 10, 3:37 am, Bruno Desthuilliers wrote:

I fail to see how the existence of JIT compilers in some Java VM changes
anything to the fact that both Java (by language specification) and
CPython use the byte-code/VM scheme.

Because these "some Java VMs" with JIT compilers are the de facto
standard used by millions; the spec is pretty much irrelevant (unless
you're a compiler writer or language theorist).

George

[Ross Ridge]

Bruno Desthuilliers <bd*****************@free.quelquepart.frwrote:

And the reference implementation of Python (CPython) is not
interpreted, it's compiled to byte-code, which is then executed by a VM
(just like Java).

Ed Jensen a écrit :

Wow, this is pretty misleading.

Bruno Desthuilliers <br********************@wtf.websiteburo.oops.comwr ote:

>Ho yes ??? Why so, please ? Care to point to anything *wrong* in the
above statement ?

Python's byte-code interpreter is not "just like" Java's virtual machine.
You're deliberately trying to mislead people into thinking Python performs
similarily to Java.

Ross Ridge

--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rr****@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //

[Ed Jensen]

Bruno Desthuilliers <br********************@wtf.websiteburo.oops.comwr ote:

I fail to see how the existence of JIT compilers in some Java VM changes
anything to the fact that both Java (by language specification) and
CPython use the byte-code/VM scheme.

While your answer was technically correct, by omitting pertinent
information, your answer lead readers to the wrong conclusion.

The only question that remains is if you were being accidentally
misleading or purposefully misleading.

[Fredrik Lundh]

Ed Jensen wrote:

The only question that remains is if you were being accidentally
misleading or purposefully misleading.

oh, please. it was perfectly clear for anyone with the slightest clue
what Bruno was talking about (especially if they'd read the post he was
replying to), so the only question that remains is why you didn't
understand it.

</F>

[Ed Jensen]

Fredrik Lundh <fr*****@pythonware.comwrote:

oh, please. it was perfectly clear for anyone with the slightest clue
what Bruno was talking about (especially if they'd read the post he was
replying to), so the only question that remains is why you didn't
understand it.

If you have something substantive to add to the discussion, by all
means, do so. But please, keep your childish and insulting comments
to yourself.

[Jaimy Azle]

"Ed Jensen" <ej*****@visi.comwrote:

>
Wow, this is pretty misleading.

Java is, indeed, compiled to bytecode; however, modern JVMs typically
compile the bytecode to native code and then execute the native code.

CPython strictly interprets bytecode; it does not compile the
bytecode to native code.

By the existence of psyco which has equal functionality, i think he is right
in term of terminology.

Salam,

-Jaimy.

[Bruno Desthuilliers]

Ed Jensen a écrit :

Fredrik Lundh <fr*****@pythonware.comwrote:

>oh, please. it was perfectly clear for anyone with the slightest clue
what Bruno was talking about (especially if they'd read the post he was
replying to), so the only question that remains is why you didn't
understand it.

If you have something substantive to add to the discussion, by all
means, do so. But please, keep your childish and insulting comments
to yourself.

I don't think you're going to make you some friends here insulting
Fredrik. I don't know who Ed Jensen is, but we are quite a lot here to
know and respect Mr Lundh for his contributions to Python as both a
language and a community.

[Bruno Desthuilliers]

George Sakkis a écrit :

On Jan 10, 3:37 am, Bruno Desthuilliers wrote:

>I fail to see how the existence of JIT compilers in some Java VM changes
anything to the fact that both Java (by language specification) and
CPython use the byte-code/VM scheme.

Because these "some Java VMs" with JIT compilers are the de facto
standard used by millions;

Repeating an argument doesn't make it more true nor more relevant. Once
again, this doesn't change anything to the fact exposed above.

the spec is pretty much irrelevant

I mentionned this because this kind of choice is usually not part of the
language spec but of a specific implementation. Java is AFAIK the only
language where this implementation stuff is part of the spec.

(unless
you're a compiler writer or language theorist).

I thought it was quite clear and obvious that I was talking about points
relating to these fields.

George

[Bruno Desthuilliers]

Ross Ridge a écrit :

Bruno Desthuilliers <bd*****************@free.quelquepart.frwrote:

>And the reference implementation of Python (CPython) is not
interpreted, it's compiled to byte-code, which is then executed by a VM
(just like Java).

Ed Jensen a écrit :

>Wow, this is pretty misleading.

Bruno Desthuilliers <br********************@wtf.websiteburo.oops.comwr ote:

>Ho yes ??? Why so, please ? Care to point to anything *wrong* in the
above statement ?

Python's byte-code interpreter is not "just like" Java's virtual machine.

of course it's not "just like" - different languages, different
byte-codes, different implementations. What is "just like" is the
byte-code/VM scheme. Thought this was obvious to anyone able to parse a
simple sentence.

You're deliberately trying to mislead people into thinking Python performs
similarily to Java.

I don't know what you're smoking, but you should perhaps stop - because
this seems to drive you into paranoïd delirium.

[Bruno Desthuilliers]

Fredrik Lundh a écrit :

A.T.Hofkamp wrote:

>Now the question you need to answer for yourself, is how much more
worth is
your own time compared to the gain in CPU time. If you think they are
equal (ie
the problem as a whole should be solved as fast as possible, thus the
sum of
development time + execution time should be as short as possible), you
can
spend an additional 1.5 seconds development in the alternative solution.

so you only run your programs once?

Lol !-)

[George Sakkis]

On Jan 11, 4:12 am, Bruno Desthuilliers <bruno.
[e-mail]:

George Sakkis a écrit :

On Jan 10, 3:37 am, Bruno Desthuilliers wrote:

I fail to see how the existence of JIT compilers in some Java VM changes
anything to the fact that both Java (by language specification) and
CPython use the byte-code/VM scheme.

Because these "some Java VMs" with JIT compilers are the de facto
standard used by millions;

Repeating an argument doesn't make it more true nor more relevant. Once
again, this doesn't change anything to the fact exposed above.

the spec is pretty much irrelevant

I mentionned this because this kind of choice is usually not part of the
language spec but of a specific implementation. Java is AFAIK the only
language where this implementation stuff is part of the spec.

(unless
you're a compiler writer or language theorist).

I thought it was quite clear and obvious that I was talking about points
relating to these fields.

No it wasn't, and besides the OP is most likely interested in these as
a simple user so the distinction between a spec and a de facto
standard implementation (such as JDK for Java and CPython for Python)
are almost pedantic if not misleading. We're not Lisp (yet ;-)), with
five major implementations and a dozen of minor ones.

George

[Ross Ridge]

Bruno Desthuilliers <bd*****************@free.quelquepart.frwrote:

And the reference implementation of Python (CPython) is not
interpreted, it's compiled to byte-code, which is then executed by a VM
(just like Java).

Ross Ridge a écrit :

Python's byte-code interpreter is not "just like" Java's virtual machine.

Bruno Desthuilliers <br********************@wtf.websiteburo.oops.comwr ote:

>of course it's not "just like" - different languages, different
byte-codes, different implementations. What is "just like" is the
byte-code/VM scheme.

No the schemes aren't "just like" each other. They perform much
differently.

Thought this was obvious to anyone able to parse a simple sentence.

What's obvious is that you're lying.

>You're deliberately trying to mislead people into thinking Python performs
similarily to Java.

I don't know what you're smoking, but you should perhaps stop - because
this seems to drive you into paranoïd delirium.

This isn't the first time you've tried to mislead people into
thinking Python's byte-code interpreter works just like Java's VM.
Your over-zealous Python advocacy is benefiting no one.

Ross Ridge

--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rr****@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //

[Bruno Desthuilliers]

George Sakkis a écrit :

On Jan 11, 4:12 am, Bruno Desthuilliers <bruno.
[e-mail]:

>George Sakkis a écrit :

>>On Jan 10, 3:37 am, Bruno Desthuilliers wrote:
I fail to see how the existence of JIT compilers in some Java VM changes
anything to the fact that both Java (by language specification) and
CPython use the byte-code/VM scheme.
Because these "some Java VMs" with JIT compilers are the de facto
standard used by millions;

Repeating an argument doesn't make it more true nor more relevant. Once
again, this doesn't change anything to the fact exposed above.

>>the spec is pretty much irrelevant

I mentionned this because this kind of choice is usually not part of the
language spec but of a specific implementation. Java is AFAIK the only
language where this implementation stuff is part of the spec.

>>(unless
you're a compiler writer or language theorist).

I thought it was quite clear and obvious that I was talking about points
relating to these fields.

No it wasn't,

"""

or is Python just too slow
as an interpreted language

Being "interpreted" is a quality of an implementation, not of a language.
"""

If that isn't clear enough what I'm talking about, then sorry but I
can't help.

and besides the OP is most likely interested in these as
a simple user so the distinction between a spec and a de facto
standard implementation (such as JDK for Java and CPython for Python)
are almost pedantic if not misleading.

I can live with being called "pedantic" - even I'm not sure whether
correcting a wrong statement about CPython's execution model is pedantic
or not. But I *still* fail to see how it could be "misleading", and
*you* still fail to explain in which way it could be misleading.

If your point is that saying that CPython uses a byte-code/VM scheme
"just like Java" necessarily implies JIT compilation just because some
JVM support this feature, then it would be time you pay more attention
to what is effectively written.

We're not Lisp (yet ;-)), with
five major implementations and a dozen of minor ones.

And ? In which way does it make the distinction between a language and a
language implementation less true ?

[Bruno Desthuilliers]

Ross Ridge a écrit :

Bruno Desthuilliers <bd*****************@free.quelquepart.frwrote:

>And the reference implementation of Python (CPython) is not
interpreted, it's compiled to byte-code, which is then executed by a VM
(just like Java).

Ross Ridge a écrit :

>Python's byte-code interpreter is not "just like" Java's virtual machine.

Bruno Desthuilliers <br********************@wtf.websiteburo.oops.comwr ote:

>of course it's not "just like" - different languages, different
byte-codes, different implementations. What is "just like" is the
byte-code/VM scheme.

No the schemes aren't "just like" each other. They perform much
differently.

fact 1: CPython compiles source code to byte-code.
fact 2: CPython executes this byte-code.
fact 3: Sun's JDK compiles source code to byte-code.
fact 4: Sun's JDK executes this byte-code.

Care to prove me wrong on any of these points ? Don't bother: you can't.
So my first assertion that "CPython is compiled to byte-code, which is
then executed by a VM" is true, and since the same assertion also stands
for Java (ie: sun's JDK), then the "just like" qualifier is true too.
Period.

>Thought this was obvious to anyone able to parse a simple sentence.

What's obvious is that you're lying.

Man, you suffer from a bad case of paranoia.

>>You're deliberately trying to mislead people into thinking Python performs
similarily to Java.

I don't know what you're smoking, but you should perhaps stop - because
this seems to drive you into paranoïd delirium.

This isn't the first time you've tried to mislead people into
thinking Python's byte-code interpreter works just like Java's VM.

I challenge you to come with any evidence to support this claim. I never
wrote anything about CPython's byte-code interpreter inner working.

Your over-zealous Python advocacy is benefiting no one.

Is there any cure for paranoia ?

[Ross Ridge]

Bruno Desthuilliers <br********************@wtf.websiteburo.oops.comwr ote:

>fact 1: CPython compiles source code to byte-code.
fact 2: CPython executes this byte-code.
fact 3: Sun's JDK compiles source code to byte-code.
fact 4: Sun's JDK executes this byte-code.

Care to prove me wrong on any of these points ? Don't bother: you can't.
So my first assertion that "CPython is compiled to byte-code, which is
then executed by a VM" is true, and since the same assertion also stands
for Java (ie: sun's JDK), then the "just like" qualifier is true too.
Period.

No, the "just like" qualifier is false. Python doesn't compile "just
like" Java, nor does it execute "just like" Java. The "byte-code"
langauges are very different and they perform much differently.
Java compiles slower but executes faster. Python's byte-code is ment to
quickly generated on the fly to save having to reparse the source code.
Java code is compiled using optimizations into a virtual machine languague
ment to be executed as fast as possible on a wide range of processors.
The similarities between the two are superficial, Python doesn't compile
and execute code "just like" Java.

Try all you want to try to reparse what you wrote in to a different
meaning, it doesn't change the fact your intent was to mislead.

Ross Ridge

--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rr****@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //

[Hrvoje Niksic]

Bruno Desthuilliers <br********************@wtf.websiteburo.oops.com >
writes:

fact 1: CPython compiles source code to byte-code.
fact 2: CPython executes this byte-code.
fact 3: Sun's JDK compiles source code to byte-code.
fact 4: Sun's JDK executes this byte-code.

Care to prove me wrong on any of these points ? Don't bother: you
can't.

Fact 4 is misleading because it is only one option available to Sun's
JDK. Sun's JDK is also capable of transforming the byte-code to
native code and letting the processor execute that instead of the
original byte code, and that is where the most significant speed
increase comes from. Most importantly, it does so automatically, by
default, with no programmer intervention or configuration, and with
100% compatibility, so it doesn't compare well to Python accelerators
like psyco.

[George Sakkis]

On Jan 11, 8:59 am, Bruno Desthuilliers <bruno.
[e-mail]:

George Sakkis a écrit :

On Jan 11, 4:12 am, Bruno Desthuilliers <bruno.
[e-mail]:

George Sakkis a écrit :

>On Jan 10, 3:37 am, Bruno Desthuilliers wrote:
I fail to see how the existence of JIT compilers in some Java VM changes
anything to the fact that both Java (by language specification) and
CPython use the byte-code/VM scheme.
Because these "some Java VMs" with JIT compilers are the de facto
standard used by millions;
Repeating an argument doesn't make it more true nor more relevant. Once
again, this doesn't change anything to the fact exposed above.

>the spec is pretty much irrelevant
I mentionned this because this kind of choice is usually not part of the
language spec but of a specific implementation. Java is AFAIK the only
language where this implementation stuff is part of the spec.

>(unless
you're a compiler writer or language theorist).
I thought it was quite clear and obvious that I was talking about points
relating to these fields.

No it wasn't,

"""

or is Python just too slow
as an interpreted language

Being "interpreted" is a quality of an implementation, not of a language.
"""
If that isn't clear enough what I'm talking about, then sorry but I
can't help.

Pedantic once again. For languages with a single (or practically
single) implementation such as Python, the average user couldn't care
less about the distinction. Your point might have more merit if
PyPy or IronPython or Jython enter the same league with CPython in
terms of usage.

and besides the OP is most likely interested in these as
a simple user so the distinction between a spec and a de facto
standard implementation (such as JDK for Java and CPython for Python)
are almost pedantic if not misleading.

I can live with being called "pedantic" - even I'm not sure whether
correcting a wrong statement about CPython's execution model is pedantic
or not. But I *still* fail to see how it could be "misleading", and
*you* still fail to explain in which way it could be misleading.

If your point is that saying that CPython uses a byte-code/VM scheme
"just like Java" necessarily implies JIT compilation just because some
JVM support this feature, then it would be time you pay more attention
to what is effectively written.

What three different people in this thread have been trying to tell
you but you seem to miss is that claiming CPython's VM "is just like
Java" is comparable to saying "a Yugo's car engine is just like a
BMW's" (or "humans are just like chimpanzees"), which for some value
of "just like" is technically correct but it's not what most people
would call an accurate statement.

We're not Lisp (yet ;-)), with
five major implementations and a dozen of minor ones.

And ? In which way does it make the distinction between a language and a
language implementation less true ?

In the way that most plain users care (or not) about.

George

[George Sakkis]

On Jan 11, 9:41 am, Hrvoje Niksic <[e-mail]:

Bruno Desthuilliers <[e-mail] >
writes:

fact 1: CPython compiles source code to byte-code.
fact 2: CPython executes this byte-code.
fact 3: Sun's JDK compiles source code to byte-code.
fact 4: Sun's JDK executes this byte-code.

Care to prove me wrong on any of these points ? Don't bother: you
can't.

Fact 4 is misleading because it is only one option available to Sun's
JDK. Sun's JDK is also capable of transforming the byte-code to
native code and letting the processor execute that instead of the
original byte code, and that is where the most significant speed
increase comes from. Most importantly, it does so automatically, by
default, with no programmer intervention or configuration, and with
100% compatibility, so it doesn't compare well to Python accelerators
like psyco.

Plus, IIRC Java's JIT is not limited to optimizing special cases,
while psyco helps primarily with number-crunching code (admittedly an
important special case) and can have zero or even (small) negative
effect on arbitrary Python programs.

George

[Ed Jensen]

Bruno Desthuilliers <br********************@wtf.websiteburo.oops.comwr ote:

fact 1: CPython compiles source code to byte-code.
fact 2: CPython executes this byte-code.
fact 3: Sun's JDK compiles source code to byte-code.
fact 4: Sun's JDK executes this byte-code.

Care to prove me wrong on any of these points ? Don't bother: you can't.
So my first assertion that "CPython is compiled to byte-code, which is
then executed by a VM" is true, and since the same assertion also stands
for Java (ie: sun's JDK), then the "just like" qualifier is true too.
Period.

#2 and #4 are wrong (or, at best, misleading). Here, I'll fix them
for you:

Fact 2: CPython interprets the bytecode.

Fact 4: Sun's JVM does some interpretation of the bytecode, but also
compiles some of the bytecode to native code and executes the
resulting native code.

These distinctions can be important and it's intellectually dishonest
to gloss over them.

[Ed Jensen]

Bruno Desthuilliers <br********************@wtf.websiteburo.oops.comwr ote:

I don't think you're going to make you some friends here insulting
Fredrik. I don't know who Ed Jensen is, but we are quite a lot here to
know and respect Mr Lundh for his contributions to Python as both a
language and a community.

I'll keep in mind that some people around these parts are untouchable
and have a free pass to be insulting and childish.

Thanks for the tip.

[sturlamolden]

On 9 Jan, 20:11, "[e-mail]" <[e-mail]>
wrote:

Is there a better way to do color tracking, or is Python just too slow
as an interpreted language to do any effective color tracking?

You should code numerically intensive tasks using NumPy arrays. If
things are getting slow, chances are you are using Python for loops
instead of vectorized NumPy expressions. This is the same trick you
would use in e.g. Matlab for boosting performance. If things are
running slow despite of having properly vectorized your code, chances
are that porting to C will not make a big difference.

If you need to resort to C or Fortran, it is easy to interface Python
with these languages (e.g. ctypes, Pyrex, Swig, f2py, or weave). Put
the offending bottleneck in a lower level language (detect it using
the profiler module) and leave everything else in Python.

[sturlamolden]

On 9 Jan, 20:11, "[e-mail]" <[e-mail]>
wrote:

Is there a better way to do color tracking, or is Python just too slow
as an interpreted language to do any effective color tracking?

The slowness stems from the use of k-means clustering on each frame.
SciPy's clustering module used for the purpose is written in plain C.
It is not Python that is slow.

[Steven D'Aprano]

On Fri, 11 Jan 2008 09:52:17 -0800, Paul Boddie wrote:

These days, I seriously doubt that anyone uses the term "interpreted" to
mean "parses the source text and works out what to do, over and over
again as the program runs".

Given the way that people seem to use "interpreted" as a pejorative and a
synonym for "slow", I don't doubt it one bit. Especially in management,
where they might be making technical judgments on the basis of half-
remembered Comp Sci 101 lessons from fifteen years earlier and vague
buzzword-laden articles in trade magazines.

--
Steven

[bruno.desthuilliers]

On 11 jan, 16:10, George Sakkis <[e-mail]:

On Jan 11, 8:59 am, Bruno Desthuilliers <bruno.

(snip)

But I *still* fail to see how it could be "misleading", and
*you* still fail to explain in which way it could be misleading.

If your point is that saying that CPython uses a byte-code/VM scheme
"just like Java" necessarily implies JIT compilation just because some
JVM support this feature, then it would be time you pay more attention
to what is effectively written.

What three different people in this thread have been trying to tell
you but you seem to miss is that claiming CPython's VM "is just like
Java"

George, *please*, re-read what I wrote. I *never* claimed that
CPython's VM is just like a JVM, I just stated that both CPython and
Java use a byte-code/VM execution model. Can't you understand that ?

[Paul Boddie]

On 12 Jan, 04:03, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.auwrote:

>
Given the way that people seem to use "interpreted" as a pejorative and a
synonym for "slow", I don't doubt it one bit. Especially in management,
where they might be making technical judgments on the basis of half-
remembered Comp Sci 101 lessons from fifteen years earlier and vague
buzzword-laden articles in trade magazines.

Indeed. Still, there's reason to be upbeat about Python's potential
here. The big question is this: what is everyone with any degree of
concern about Python's performance doing to improve the situation?
Sure, C (or actually C++) seems to win the shootout [1], but there are
plenty of language implementations between g++ and CPython to suggest
that the old choice of extension modules written in C vs. other code
written in Python doesn't provide a complete map of the opportunities.

Paul

[1] http://shootout.alioth.debian.org/gp...t=all&lang=all

[bruno.desthuilliers]

On 11 jan, 15:41, Hrvoje Niksic <[e-mail]:

Bruno Desthuilliers <[e-mail] >
writes:

fact 1: CPython compiles source code to byte-code.
fact 2: CPython executes this byte-code.
fact 3: Sun's JDK compiles source code to byte-code.
fact 4: Sun's JDK executes this byte-code.

Care to prove me wrong on any of these points ? Don't bother: you
can't.

Fact 4 is misleading because it is only one option available to Sun's
JDK. Sun's JDK is also capable of transforming the byte-code to
native code and letting the processor execute that instead of the
original byte code, and that is where the most significant speed
increase comes from. Most importantly, it does so automatically, by
default, with no programmer intervention or configuration, and with
100% compatibility, so it doesn't compare well to Python accelerators
like psyco.

Then fact 1 is misleading too since Python handles the compilation
automatically without programmer's intervention while Java requires
someone to explicitely invoke the byte-code compiler.

I just don't understand what's all that fuss with this simple and
quite comparison of Java and Python. You can google this ng archives,
you'll find hundreds of posts saying the same thing, and everyone so
far seemed to be smart enough to understand that this had nothing to
do with the byte-code specifications, VM implementation and presence
or absence of a JIT compiler.

Anyway, I do maintain that what I said is 100% correct, 100% accurate
given the context, and 0% misleading unless you're clueless enough to
not be able to parse a single english sentence (in which case I just
can't help). As a matter of fact, this didn't seem to "mislead" the OP
into thinking such a thing.

Regards.

[bruno.desthuilliers]

On 11 jan, 17:23, Ed Jensen <[e-mail]:

Bruno Desthuilliers <[e-mail] ote:

fact 1: CPython compiles source code to byte-code.
fact 2: CPython executes this byte-code.
fact 3: Sun's JDK compiles source code to byte-code.
fact 4: Sun's JDK executes this byte-code.

Care to prove me wrong on any of these points ? Don't bother: you can't.
So my first assertion that "CPython is compiled to byte-code, which is
then executed by a VM" is true, and since the same assertion also stands
for Java (ie: sun's JDK), then the "just like" qualifier is true too.
Period.

#2 and #4 are wrong (or, at best, misleading). Here, I'll fix them
for you:

Fact 2: CPython interprets the bytecode.

Fact 4: Sun's JVM does some interpretation of the bytecode, but also
compiles some of the bytecode to native code and executes the
resulting native code.

These distinctions can be important and it's intellectually dishonest
to gloss over them.

These distinctions are important if the context is the VM
implementation, which is *obviously* not the case here. FWIW, I you
had spent a bit more time reading the remaining of the discussion with
the OP, I do clearly mention this distinction. So please get a life
and keep your comment about "intellectual dishonesty" where they
belong.

[bruno.desthuilliers]

On 10 jan, 21:47, Ed Jensen <[e-mail]:

Bruno Desthuilliers <[e-mail] ote:

I fail to see how the existence of JIT compilers in some Java VM changes
anything to the fact that both Java (by language specification) and
CPython use the byte-code/VM scheme.

While your answer was technically correct, by omitting pertinent
information, your answer lead readers to the wrong conclusion.

That's pure non-sense.

The only question that remains is if you were being accidentally
misleading or purposefully misleading.

The only question that remains for me is if you are being just stupid
or totally paranoid.

fu2 /dev/null

[bruno.desthuilliers]

On 10 jan, 03:10, Steven D'Aprano
<[e-mail]:

On Wed, 09 Jan 2008 21:26:05 +0100, Bruno Desthuilliers wrote:

hint: how can a compiler safely optimize anything in a language so
dynamic that even the class of an object can be changed at runtime ?

Is that a trick question?

Nope. Just an observation about the tradeoffs of dynamism.

[dongie.agnir]

Oh.. it seems my naiveness has stirred quite a discussion >_<...

I must admit though, I've learned a bit about Python reading through
this topic. Thanks to everyone who pointed out the flaws in the
code. I'll see if I can come up with my own color tracking solution
in a few weeks and post back here. Thanks!

[Jaimy Azle]

<br*****************@gmail.comwrote:

fact 1: CPython compiles source code to byte-code.
fact 2: CPython executes this byte-code.
fact 3: Sun's JDK compiles source code to byte-code.
fact 4: Sun's JDK executes this byte-code.

Fact 4 is misleading because it is only one option available to Sun's
JDK. Sun's JDK is also capable of transforming the byte-code to
native code and letting the processor execute that instead of the
original byte code, and that is where the most significant speed
increase comes from. Most importantly, it does so automatically, by
default, with no programmer intervention or configuration, and with
100% compatibility, so it doesn't compare well to Python accelerators
like psyco.

Then fact 1 is misleading too since Python handles the compilation
automatically without programmer's intervention while Java requires
someone to explicitely invoke the byte-code compiler.

Sadly it is true also, I read somewhere this silly point was used also to
make distinction between java and python, then claiming python is just like
another interpreter, while java has it's own (what they call as) 'compiler'.
:)

perhaps in the future another sillly point could be added also, Java has
Jython, while Python doesn't have some thing like PyJava or... perhaps Py-va
(Python based Java Language).

Salam,

-Jaimy.

[bearophileHUGS]

Paul Boddie:

what is everyone with any degree of
concern about Python's performance doing to improve the situation?

They are probably developing systems like Cython and ShedSkin, and
hoping to see Psyco improved again to manage itertools better (and
maybe 64 bit CPUs too).

Sure, C (or actually C++) seems to win the shootout [1],

Beside C++ being the faster (not C anymore), there are other ways to
"win" the Shootout, like using less RAM, writing shorter code, etc. If
you change the way you measure you can see that FreePascal, Ruby and D
too "win" the Shootout :-) (the first as the one using less memory,
the second one as the one with shorter programs, and the third one as
"faster && with shorter programs").

but there are
plenty of language implementations between g++ and CPython to suggest
that the old choice of extension modules written in C vs. other code
written in Python doesn't provide a complete map of the opportunities.

I think in few years it may become feasible to use Pyd to write
extensions in D for CPython :-)

Bye,
bearophile

[Bruno Desthuilliers]

Jaimy Azle a écrit :

<br*****************@gmail.comwrote:

>>>fact 1: CPython compiles source code to byte-code.
fact 2: CPython executes this byte-code.
fact 3: Sun's JDK compiles source code to byte-code.
fact 4: Sun's JDK executes this byte-code.
Fact 4 is misleading because it is only one option available to Sun's
JDK. Sun's JDK is also capable of transforming the byte-code to
native code and letting the processor execute that instead of the
original byte code, and that is where the most significant speed
increase comes from. Most importantly, it does so automatically, by
default, with no programmer intervention or configuration, and with
100% compatibility, so it doesn't compare well to Python accelerators
like psyco.

Then fact 1 is misleading too since Python handles the compilation
automatically without programmer's intervention while Java requires
someone to explicitely invoke the byte-code compiler.

Sadly it is true also, I read somewhere this silly point was used also to
make distinction between java and python, then claiming python is just like
another interpreter, while java has it's own (what they call as) 'compiler'.
:)

perhaps in the future another sillly point could be added also, Java has
Jython, while Python doesn't have some thing like PyJava or... perhaps Py-va
(Python based Java Language).

Lol. At least some common sens in this stupid thread. Thanks Jaimy, you
made my day !-)

Salam,

Peace.

PS : and BTW : my apologies to the community - I should have made my
point only once and then shut up. Sorry.

[cokofreedom]

A lecturer gave me the perfect answer to the question of speed.

"You have two choices when it comes to programming. Fast code, or fast
coders."

[Paul Boddie]

On 15 Jan, 08:33, "Jaimy Azle" <[e-mail]:

>
perhaps in the future another sillly point could be added also, Java has
Jython, while Python doesn't have some thing like PyJava or... perhaps Py-va
(Python based Java Language).

You could compile Java to CPython bytecode or, in the case of a little
experiment I did some time ago, translate Java bytecode to CPython
bytecode: the CPython virtual machine operates at a higher level and
can support the Java instructions fairly easily, whereas a fair amount
of work is required to support CPython instructions on the Java
virtual machine. I found that the biggest obstacle was probably
treating Java packages like Python packages - something which
admittedly isn't completely necessary, but which would make the thing
more usable at the prompt. Ultimately, I had little need for Java-
based software and thus wasn't motivated into continuing the work,
although Python 2.5 and beyond do provide some conveniences which
might make some aspects of the implementation more bearable.

Given that other languages (eg. Logix [2], various Lisp dialects) have
been implemented for CPython, I think your point could be better
formulated.

Paul

[1] http://www.boddie.org.uk/python/javaclass.html
[2] http://www.livelogix.net/logix/

[Paul Rudin]

co*********@gmail.com writes:

A lecturer gave me the perfect answer to the question of speed.

"You have two choices when it comes to programming. Fast code, or fast
coders."

Yes, although it's more a continuum than that suggests. The tricky bit
is deciding in each situation where you should be on the continuum.