Re: Python too slow?
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 machine that can't take advantage of the type declarations? I know it was a rhetorical question, but I wanted to point out that this is exactly what happens with Java Generics. They didn't want to update the type system in the JVM, so all the generic types get thrown out by the compiler in favor of non-generic types, and casts are inserted as necessary. Practicality wins over Purity again. Gary Duzan Motorola HNM -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 not work just like as PyPy, but really... it is damned cool to get CPython execute java byte-code, congratulations... Well, the limitations that stopped me working on it are listed on the page I referenced, so it wasn't that cool in the end. In fact, the project grew out of just wanting to inspect .class files and pull out method signatures, but it was so tempting to see whether Java bytecodes could be rewritten and run in a CPython environment. 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 of the type declarations? Secondly, isn't it just better to use a virtual machine with just-in- time compilation and all sorts of security mechanisms if you're wanting to write the Java code that, when compiled, can take advantage of all that stuff? In other words: what makes CPython a compelling VM for the Java programmer? My perspective now is that it's a lot more interesting to target Python for virtual machines other than the CPython one because that's where the performance and functionality benefits are most likely to be found. And the most important motivation for this: I prefer writing Python, not Java. ;-) Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
[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 be winning any awards anytime soon, Jython and IronPython are pretty impressive performers. Disclaimer: I haven't personally used Jython or IronPython. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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. George W. Bush My understanding is that while CPython performance won't be winning any awards anytime soon, Jython and IronPython are pretty impressive performers. Disclaimer: I haven't personally used Jython or IronPython. Indeed, it is as Paul Rudin said; It's more a continuum than that suggests. The tricky bit is deciding in each situation where you should be on the continuum. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 of the type declarations? Secondly, isn't it just better to use a virtual machine with just-in- time compilation and all sorts of security mechanisms if you're wanting to write the Java code that, when compiled, can take advantage of all that stuff? In other words: what makes CPython a compelling VM for the Java programmer? I agree, that's why i expecting nobody willing to. But despite of that, at least what you've done is a proof-of-concept that java byte-code could also be executed by python. Salam, -Jaimy. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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
Re: Python too slow?
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 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/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
[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 be on the continuum. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 suggests. The tricky bit is deciding in each situation where you should be on the continuum. Ah, it all comes from hindsight! You always realise in the last week of the deadline you were on the wrong end of the continuum! Problem solved, panic created! :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
[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 language with simple short syntax and high running speed at the same time. Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 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. Wow, serious... what you've done was really, really 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 not work just like as PyPy, but really... it is damned cool to get CPython execute java byte-code, congratulations... Salam, -Jaimy. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
[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 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
On 11 jan, 16:10, George Sakkis [EMAIL PROTECTED] wrote: 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 ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 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/gp4sandbox/benchmark.php?test=alllang=all -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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? Nope. Just an observation about the tradeoffs of dynamism. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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. Bruno Desthuilliers [EMAIL PROTECTED] wrote: 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 !-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 ? 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 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] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/~rridge/ db // -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
On Jan 11, 2008 9:10 AM, George Sakkis [EMAIL PROTECTED] wrote: On Jan 11, 8:59 am, Bruno Desthuilliers bruno. [EMAIL PROTECTED] wrote: George Sakkis a écrit : On Jan 11, 4:12 am, Bruno Desthuilliers bruno. [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 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. The statement was in response to a claim that Python was slow because it is interpreted. This is a little like correcting someone who says that a Yugo is slow because it has a steam engine by telling that no, it's internal combustion, just like the BMW has. It's possible for this a claim like this to lead to a clarifying and informative discussion about JIT technology and how it improves Javas performance, and the use of corresponding techniques in Python. What we got instead was someone who felt some sort of juvenile urge to jump all over a what he thought of as a claim that Python is as fast as Java (which, of course, it sometimes is - the issue is more complicated than a sound bite). 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. Not that I think any of you care about anything except your e-penis at this point, but there is no reason to proscribe discussion to only what plain users want, even if the OP was such a person. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
On Jan 11, 8:59 am, Bruno Desthuilliers bruno. [EMAIL PROTECTED] wrote: George Sakkis a écrit : On Jan 11, 4:12 am, Bruno Desthuilliers bruno. [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 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
On Jan 11, 4:12 am, Bruno Desthuilliers bruno. [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 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
George Sakkis a écrit : On Jan 11, 4:12 am, Bruno Desthuilliers bruno. [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 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 ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 machine. Bruno Desthuilliers [EMAIL PROTECTED] wrote: 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] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/~rridge/ db // -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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, 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 just like Java's virtual machine. Bruno Desthuilliers [EMAIL PROTECTED] wrote: 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 ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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. While your answer was technically correct, by omitting pertinent information, your answer lead readers to the wrong conclusion. Indeed. A perusal of the Java VM architecture documents plus any discussions around dynamic language support (and there's a discussion group about that very topic) reveal a number of differences between the CPython VM and Sun's Java VM. Moreover, despite claims about the Sun VM only being one of many, it holds a fairly similar position to that of the CPython VM in its own part of the computing world, with adoption only likely to increase now that it's open source. (And many new adopters were quite possibly using stuff like gcj previously which, as many will already know, is a native code compiler for Java.) 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. Instead, I imagine that the term typically suggests the presence of a virtual processor doing what all processors do: interpret instructions. It's just that when native code is produced, we look away from the process of interpretation done by the hardware and consider it as the plain on the metal execution of the code. Sure, Sun's Java VM may not remove such a virtual processor entirely from the overall execution of a program, and the output of gcj may include the invocation of lots of moderately expensive library calls, but in contrast with CPython, some sequences of instructions will not ultimately be interpreted by the virtual machine at run-time. All this said, there are options other than CPython, and I imagine that they will become even more interesting to mainstream Python users over the next months and years. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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(n**2) algorithm into an O(1) algorithm. This is possibly the number one cause of 'slowness' complained about on mailing lists. The Original Poster says it takes one or two seconds to process an 800x600 GIF. That sounds believable: on my PC, it takes about five seconds to loop over range(800*600) and do a tiny bit of processing. Something like Psycho might speed that up a lot, possibly by an order of magnitude or two. 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 is slow. It is the amount of processing done on each frame. As the bottleneck is already in C, it cannot be done any faster without radically changing the algorithm and/or the hardware. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 used for the purpose is written in plain C. It is not Python that is slow. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 is slow. It is the amount of processing done on each frame. As the bottleneck is already in C, it cannot be done any faster without radically changing the algorithm and/or the hardware. Thank you for taking the effort to actually investigate the OP's *actual* problem. Such a pity that the chances are he's probably gone away in disgust at the pedantry and insults in this thread. He'll probably become another one of those people convinced that Python is slow because it's interpreted when in fact this is an example of C being slow in spite of being compiled. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 ? 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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-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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
-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, 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... -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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). -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
On Jan 10, 12:04 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
On Jan 10, 3:00 am, Ant [EMAIL PROTECTED] wrote: On Jan 10, 12:04 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 PROTECTED] wrote: 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] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/~rridge/ db // -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 information, your answer lead readers to the wrong conclusion. The only question that remains is if you were being accidentally misleading or purposefully misleading. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 substantive to add to the discussion, by all means, do so. But please, keep your childish and insulting comments to yourself. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 to native code. By the existence of psyco which has equal functionality, i think he is right in term of terminology. Salam, -Jaimy. -- http://mail.python.org/mailman/listinfo/python-list
Python too slow?
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 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? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
[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 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? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
[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 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 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/doc/dynamic-language-translation.html) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 nowadays than it used to be, and is usually fast enough for most day-to-day programming tasks (a ... at least for my own day-to-day tasks) but it's still not as highly optimized as some Lisp implementations (to compare to another highly ... dynamic language). done -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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
Re: Python too slow?
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 uses to find the points. Ok, so what's that look like? Python - used properly - can be quite fast. We process 1.5 billion rows a day through our python-based ETL system. The trick is to arrange things so that the cpu-intensive work gets done by C code. Preferably by tightly coded C written by very sharp people and extensively tweaked to make it go fast. In our case, the T part of our ETL system is handled by a custom C library that's been around - and being debugged and tweaked - for quite some time. Other examples include much of the code for python's builtins, and things like the Numpy extension library. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
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. a keyhole optimizer that detects when you write something like this: def foo(): x = 1 + 2 return x and optimizes it to this: import dis dis.dis(foo) 2 0 LOAD_CONST 3 (3) 3 STORE_FAST 0 (x) 3 6 LOAD_FAST0 (x) 9 RETURN_VALUE (Only in CPython version 2.5 or better.) Okay, okay, so constant folding isn't going to save you a lot of time (unless your constant is being re-calculated millions of times) but it's still an optimization. There are others, some have been done (e.g. optimize away the quadratic behaviour for string concatenation in some limited cases), some are possible but rejected by the BDFL (e.g. tail- call optimization), presumably there are some possible but not yet implemented or even discovered (which is the point of the PyPy project). 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(n**2) algorithm into an O(1) algorithm. The Original Poster says it takes one or two seconds to process an 800x600 GIF. That sounds believable: on my PC, it takes about five seconds to loop over range(800*600) and do a tiny bit of processing. Something like Psycho might speed that up a lot, possibly by an order of magnitude or two. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
