In article <[EMAIL PROTECTED]>,
Paul Boddie <[EMAIL PROTECTED]> wrote:
>
>I think the benefits of running Java on CPython are significantly less
>than those had by running Python on the Java VM (or another VM).
>Firstly, who wants to write statically typed code which then runs on a
>virtual machin
"Paul Boddie" <[EMAIL PROTECTED]> wrote:
> I think the benefits of running Java on CPython are significantly less
> than those had by running Python on the Java VM (or another VM).
> Firstly, who wants to write statically typed code which then runs on a
> virtual machine that can't take advantage
On Jan 16, 5:52 pm, Ed Jensen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > 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."
>
> "You're either with us, or against us."
>
> Georg
[EMAIL PROTECTED] wrote:
> 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."
"You're either with us, or against us."
George W. Bush
My understanding is that while CPython performance won't
On 16 Jan, 02:17, "Jaimy Azle" <[EMAIL PROTECTED]> wrote:
>
> Wow, serious... what you've done was really, really cool... :)
In practice, not that cool. ;-)
> I was expect there are nobody willing to do to have python runs Java
> Language (such as PyPy) over CPython. Perhaps your javaclass does n
"Paul Boddie" <[EMAIL PROTECTED]> wrote:
>>
>> 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
[EMAIL PROTECTED]:
> 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."
I don't believe that anymore, ShedSkin compiles slowly and it has
limitations still, but it shows that it's possible to create a
On Jan 15, 1:28 pm, Paul Rudin <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] 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 sugge
[EMAIL PROTECTED] 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 b
On 15 Jan, 08:33, "Jaimy Azle" <[EMAIL PROTECTED]> wrote:
>
> 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 th
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."
--
http://mail.python.org/mailman/listinfo/python-list
Jaimy Azle a écrit :
> <[EMAIL PROTECTED]> wrote:
>
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
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 actu
<[EMAIL PROTECTED]> wrote:
>> > 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 availa
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 h
On 10 jan, 03:10, Steven D'Aprano
<[EMAIL PROTECTED]> wrote:
> 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?
On 10 jan, 21:47, Ed Jensen <[EMAIL PROTECTED]> wrote:
> Bruno Desthuilliers <[EMAIL PROTECTED]> 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.
>
> W
On 11 jan, 17:23, Ed Jensen <[EMAIL PROTECTED]> wrote:
> Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> > 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 by
On 11 jan, 15:41, Hrvoje Niksic <[EMAIL PROTECTED]> wrote:
> Bruno Desthuilliers <[EMAIL PROTECTED]>
> 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 execute
On 12 Jan, 04:03, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
>
> 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 ha
On 11 jan, 16:10, George Sakkis <[EMAIL PROTECTED]> wrote:
> On Jan 11, 8:59 am, Bruno Desthuilliers > 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/V
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 pejorativ
On Fri, 11 Jan 2008 09:55:08 -0800, sturlamolden wrote:
> It seems the code he is referring to is doing k-means clustering on each
> frame. The clustering is done by from SciPy's cluster module, which is
> doing 'vector quantitization'. The algorithm is written in plain C. It
> is not Python that
On 9 Jan, 20:11, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
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
On 10 Jan, 03:10, Steven D'Aprano
<[EMAIL PROTECTED]> wrote:
> You are correct that optimizing Python is hard. However, in many cases,
> the problem is not that Python is too slow, but the specific algorithm
> chosen by the programmer is slow, e.g. no compiler optimization is going
> to turn an O(
On 10 Jan, 21:47, Ed Jensen <[EMAIL PROTECTED]> wrote:
> Bruno Desthuilliers <[EMAIL PROTECTED]> 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.
>
> W
On 9 Jan, 20:11, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
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, ch
Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> 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 kee
Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> 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
On Jan 11, 2008 9:10 AM, George Sakkis <[EMAIL PROTECTED]> wrote:
> On Jan 11, 8:59 am, Bruno Desthuilliers
> [EMAIL PROTECTED]> wrote:
> > George Sakkis a écrit :
> >
> >
> >
> > > On Jan 11, 4:12 am, Bruno Desthuilliers > > [EMAIL PROTECTED]> wrote:
> >
> > >> George Sakkis a écrit :
> >
> > >>
On Jan 11, 9:41 am, Hrvoje Niksic <[EMAIL PROTECTED]> wrote:
> Bruno Desthuilliers <[EMAIL PROTECTED]>
> 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 execu
On Jan 11, 8:59 am, Bruno Desthuilliers wrote:
> George Sakkis a écrit :
>
>
>
> > On Jan 11, 4:12 am, Bruno Desthuilliers > [EMAIL PROTECTED]> wrote:
>
> >> George Sakkis a écrit :
>
> >>> On Jan 10, 3:37 am, Bruno Desthuilliers wrote:
> I fail to see how the existence of JIT compilers in s
Bruno Desthuilliers <[EMAIL PROTECTED]>
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 ? Do
Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
>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 bo
Ross Ridge a écrit :
> Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
>> 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
George Sakkis a écrit :
> On Jan 11, 4:12 am, Bruno Desthuilliers [EMAIL PROTECTED]> wrote:
>
>> 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
Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> 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 mac
On Jan 11, 4:12 am, Bruno Desthuilliers wrote:
> 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 t
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
Ross Ridge a écrit :
> Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
>> 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.
>
> Br
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" w
Ed Jensen a écrit :
> Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>> 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 i
"Ed Jensen" <[EMAIL PROTECTED]> wrote:
>
> 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
Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> 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
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 q
Bruno Desthuilliers <[EMAIL PROTECTED]> 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.
While your answer was technically correct, by omitting pertinent
Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> 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 <[EMAIL PROTECTE
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
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 s
27;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
. 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
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
-On [20080110 11:46], A.T.Hofkamp ([EMAIL PROTECTED]) 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,
On 2008-01-09, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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/motion-capture-in-pyt
Ed Jensen a écrit :
> Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
>> 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 ? Car
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?
By finding things to optimize that *can't* change at runtime.
E.g.
Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> 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
On Wed, 9 Jan 2008 15:45:41 -0800 (PST) "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> Okay I profiled the code and here is the output:
>
> http://heightened.files.wordpress.com/2008/01/output.txt
>
> It seems that the function it spends the longest on is the red_points
> function that he use
Okay I profiled the code and here is the output:
http://heightened.files.wordpress.com/2008/01/output.txt
It seems that the function it spends the longest on is the red_points
function that he uses to find the points.
--
http://mail.python.org/mailman/listinfo/python-list
On 10 jan, 00:02, "[EMAIL PROTECTED]" >
(sorry, hit the wrong key - time to bed I guess...)
> 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
On 9 jan, 21:46, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
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 act
Christian Heimes <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] 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 bott
[EMAIL PROTECTED] 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/motion-capture-in-python.html,
> but after running the c
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
[EMAIL PROTECTED] 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/motion-capture-in-python.html,
> but after running th
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/motion-capture-in-python.html,
but after running the code with the included sample input
66 matches
Mail list logo
