Re: Python's Performance
Um, sorry, but this isn't correct.Although there might be a slight bit of gray area, the simple difference between compiled and interpreted languages is that compiled languages produce a binary consisting of bytes that mean something specific to the CPU of the computer the program is running on. The program is executed pretty much by just sending those bytes to the CPU.In an interpreted language, the "binary" (whether it be a straight text file or a bytecode file that has been produced from a text file) is, at runtime, processed by another program which _does_ consist of the bytes the CPU understands directly. Interpreted languages put an extra layer of software between the executable and the program.In practical terms, there are three differences:1) Interpreted language programs are typically much easier to transfer between machines (not necessarily between operating systems).2) Compiled languages typically have the potential (depending how much work goes into the compiler, amongst other things) to be _far_ faster than interpreted languages.3) Compiled languages require an often very painful, ugly compilation step to produce a binary. In interpreted languages (that produce bytecode), this phase is usually quite a bit easier, if not invisible.Yes, a language can have both an interpreter and a compiler, but almost always one of those plays a trivial role in the use of the language, because it is usually very difficult to get the semantics of the two to match and at the same time produce enough of a benefit to make the effort worthwhile. KenOn 14-Oct-05, at 9:29 AM, Alex Stapleton wrote:You can see that the entire, interpreted vs compiled debate is utterly meaningless and that only implementation specific details actually matter. e.g. Java is native if you compile it with GCJ. x86 is interpreted if you run it under a VM like VirtualPC. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
On 12 Oct 2005, at 09:33, bruno modulix wrote: > Donn Cave wrote: > >> Quoth "Fredrik Lundh" <[EMAIL PROTECTED]>: >> | Alex Stapleton wrote >> | >> | > Except it is interpreted. >> | >> | except that it isn't. Python source code is compiled to byte >> code, which >> | is then executed by a virtual machine. if the byte code for a >> module is up >> | to date, the Python runtime doesn't even look at the source code. >> >> Fair to say that byte code is interpreted? Seems to require an >> application we commonly call an interpreter. >> > > If so, Java is interpreted too. The only difference between Java and > Python here is that Python is smart enough to call the compiler by > itself. All languages are interpreted by something. Even x86 is interpreted by the CPU. This has been said already. Python and Java are both as distant from the machines native language, unless your using a cunning VM which does native code compilation. BASIC is in fact, lower level than Python or Java because it's VM interprets the actual source code, rather than translating it to "bytecode" first, and then interpreting that. You can see that the entire, interpreted vs compiled debate is utterly meaningless and that only implementation specific details actually matter. e.g. Java is native if you compile it with GCJ. x86 is interpreted if you run it under a VM like VirtualPC. Technical terminology generally fails to actually describing anything accurately for very long. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Paul Boddie wrote: > On the subject of other virtual machine implementations, I wonder what > happened to this one: > > http://effbot.org/zone/pytte.htm > > Fredrik? ;-) so much code, so little time... -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Donn Cave wrote:
> Quoth "Fredrik Lundh" <[EMAIL PROTECTED]>:
> | Alex Stapleton wrote
> |
> | > Except it is interpreted.
> |
> | except that it isn't. Python source code is compiled to byte code, which
> | is then executed by a virtual machine. if the byte code for a module is up
> | to date, the Python runtime doesn't even look at the source code.
>
> Fair to say that byte code is interpreted? Seems to require an
> application we commonly call an interpreter.
If so, Java is interpreted too. The only difference between Java and
Python here is that Python is smart enough to call the compiler by itself.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Alex Stapleton wrote:
>
> On 9 Oct 2005, at 19:04, Bruno Desthuilliers wrote:
>
>
>> Laszlo Zsolt Nagy a écrit :
(snip)
>>> Do you want to know how many internal string operations are done inside
>>> the Python interpreter? I believe it is not a useful information. There
>>> are benchmarks testing the *real performance* of Python.
>>>
>>> For example: http://www.osnews.com/story.php?news_id=5602
>>>
>>
>> A benchmark stating that Python is interpreted is bullshit.
>>
> Except it is interpreted. What is your point?
Nope. It's byte-compiled, just like Java. What do you think those .pyc
files are exactly ?
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Ognen Duzlevski wrote: > I am curious, does this make a difference speed wise (aside > from loading time)? The python tutorial would seem to imply > that it does not: > > >From Python-Docs-2.4.2/tut/node8.html#SECTION00812 > > "A program doesn't run any faster when it is read from a .pyc > or .pyo file than when it is read from a .py file; the only thing > that's faster about .pyc or .pyo files is the speed with which > they are loaded." if Python decides that the PYC (or PYO) file can be used, it does the following create module load module code execute module code in module context if it decides to use the source instead, it does: create module compile module source into module code save module code to PYC (or PYO) file, if possible execute module code in module context so if "loading time" covers the "compiling and saving" time, it's a wash. even if you don't include compilation in load time, the difference is still marginal, at least for moderately-sized modules. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Donn Cave wrote: > Quoth "Fredrik Lundh" <[EMAIL PROTECTED]>: > | Alex Stapleton wrote > | > | > Except it is interpreted. > | > | except that it isn't. Python source code is compiled to byte code, which > | is then executed by a virtual machine. if the byte code for a module is up > | to date, the Python runtime doesn't even look at the source code. > > Fair to say that byte code is interpreted? Seems to require an > application we commonly call an interpreter. It's fair to say that Python works just the same as Java in this regard. The myth seems to be that Python is interpreted in the same way as a unix shell script, while Java does some- thing much better. From http://www.osnews.com/story.php?news_id=5602 """Both Java and the .NET languages are "semi-compiled" (or, looking at the flip side of the coin, "semi-interpreted"). By this I mean that source code is compiled into intermediate-level code and then run by a combination interpreter/just-in-time compiler. With Java, the intermediate language is called bytecode and the interpreter/compiler is called a Java Virtual Machine (JVM). Source code in the .NET world is compiled into the Microsoft Intermediate Language (MSIL) and is run on the .NET Common Language Runtime (CLR) engine.""" ... """I wanted to find out how semi-compiled languages compare to fully interpreted languages like Python, Perl or PHP.""" The big difference between Java and Python in regards to this benchmark is that Python uses dynamic typing, which means that code such as "a = a + i" must be capable to handle any concievable value of a and i. In a naive benchmark like this, dynamic typing is just a disadvantage. In real software development, it's often a big advantage, mainly in terms of programmer productivity and program size. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Alex Stapleton wrote > > Except it is interpreted. > except that it isn't. Python source code is compiled to byte code, which > is then executed by a virtual machine. if the byte code for a module is up > to date, the Python runtime doesn't even look at the source code. I am curious, does this make a difference speed wise (aside from loading time)? The python tutorial would seem to imply that it does not: >From Python-Docs-2.4.2/tut/node8.html#SECTION00812 "A program doesn't run any faster when it is read from a .pyc or .pyo file than when it is read from a .py file; the only thing that's faster about .pyc or .pyo files is the speed with which they are loaded." Thanks, Ognen -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
On Mon, 10 Oct 2005 11:21:18 -0700, Donn Cave <[EMAIL PROTECTED]> wrote: >> Iron- >> Python). is it still an interpreter if it generates machine code? > > Is what an interpreter? > > I am not very well acquainted with these technologies, but it sounds > like variations on the implementation of an interpreter, with no > really compelling distinction between them. An important point made by Tannenbaum is this: Once you have a machine that executes instructions (what he called hardware or "Level Zero Machine", then you can create higher level machines that execute code written in the language of that machine. For the purposes of writing C, for example, we pretend that we have this magical machine that "runs C code," or more typically, "the machine that runs (insert OS name) C code." When the Level n machine isn't fast enough, we go to the level n-1 machine . . . C or Java for us, or assembly, but the model remains valid until the point where you bump up against the underlying logic gates. While we don't talk about the "Virtual Machine" the way Java folks do, Tannenbaum's model is still useful for thinking about such things. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
On Mon, 10 Oct 2005 16:47:35 -0700, Paul Boddie wrote: >> The difficulty is that the target architecture in not realized in hardware. > > Or isn't perhaps feasible/viable for hardware realisation: one of the > EuroPython speakers dangled the promise of hardware support for > high-level languages (the classic "Python on a chip" concept), but > there are probably plenty of areas where hardware support can assist > software virtual machines without going to all the trouble of > implementing such virtual machines in hardware completely. I remember back in the mid 1980s, Apple and Texas Instruments collaborated to build a hybrid dual-processor machine. It had a standard Motorola 68000 CPU like the Macintosh, plus a custom TI processor that executed Lisp code in hardware. I'm told that the reason they never sold was that the Lisp machine was considerably slower than the software Lisp solution of the time. On the other hand, there were Forth enthusiasts who hacked their Macintoshes with Forth chips, and they went like a rocket. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
> Terry Hancock <[EMAIL PROTECTED]> (TH) wrote: >TH> He's got to be talking about runtime name-binding. In >TH> other words, when you refer to: >TH> a.spam >TH> the Python interpreter actually knows you labeled that attribute 'spam', >TH> and the string is stored in a.__dict__ , so you can also access it as >TH> getattr(a, 'spam') >TH> etc. >TH> I'm pretty sure this is what string "internment" is for, though, and >TH> that such lookups are optimized out pretty much whenever possible. In the case of getattr(a, 'spam') a string comparison for 'spam' has to be done. AFAIK, in the case of a.spam the string 'spam' has been interned, so that no string comparison is necessary at lookup, only a pointer comparison. Due to hash collisions probably multiple comparisons could be necessary. -- Piet van Oostrum <[EMAIL PROTECTED]> URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4] Private email: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Peter Hansen wrote: > But I'm also not sure I ought to post that to the group, so I'll spare > them and just inflict the thought on you! Or, maybe I'll just fail to trim the newsgroup line and accidentally post to the group anyway. Yes, that's just what I'll do. Sorry folks. :-) -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Steve Holden wrote: > And we definitely need "agile" in there. Bugger, I'll go out and come in > again ... Used in the same breath as the word "bugger", I'm not sure the phrase "go out and come in again" is entirely appropriate for a family forum. ;-) But I'm also not sure I ought to post that to the group, so I'll spare them and just inflict the thought on you! Cheers, -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Peter Hansen wrote: > Harald Armin Massa wrote: > >>""" >>What is Python? >> >>Python is an interpreted, interactive, object-oriented programming >>language. It is often compared to Tcl, Perl, Scheme or Java. >>""" >>taken from >>http://www.python.org/doc/Summary.html >> >>maybe someone could update that??? > > > Maybe we should add '''...for some definitions of "interpreted", > "object-oriented", and perhaps even "interactive". ''' > > I've seen at least the first two debated endlessly here. > > -Peter And we definitely need "agile" in there. Bugger, I'll go out and come in again ... regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
On Monday 10 October 2005 01:21 pm, Donn Cave wrote: > In article <[EMAIL PROTECTED]>, > I am not very well acquainted with these technologies, but it sounds > like variations on the implementation of an interpreter, with no > really compelling distinction between them. When a program is deployed > as instructions in some form other than native code executable, and > therefore those instructions need to be evaluated by something other > than the hardware, then that would be some kind of interpretation. > I agree that there are many shades of grey here, but there's also a > real black that's sharply distinct and easy to find -- real native > code binaries are not interpreted. Please remember the context! Fredrik Lundh meant that anyone doing *benchmarks* who called Python an interpreter was missing something pretty important. Since Python actually pre-compiles much of its work, it acts more like a compiled language on many benchmarks. In fact, this is true of many "interpreted" languages nowadays. In particular, with regard to the original poster's question, the fact that Python knows about and accesses attributes and methods by their string name is not all that relevant -- the string comparisons that are implied are generally optimized out (IIRC). So it seems doubtful that Python does any more "string manipulation" in the course of its usual execution than would any other language, given the same tasks. Admittedly, Python does encourage the kind of meta programming that relies on knowing string names -- but I think that interning strings remains an optimization even for most of those cases. Assuming that Python will be slowed down because it has to do a string comparison everytime it looks up an attribute is assuming the dumbest possible interpreter design! (One which works directly from the source text). I think *that* was the point. -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Harald Armin Massa wrote: > """ > What is Python? > > Python is an interpreted, interactive, object-oriented programming > language. It is often compared to Tcl, Perl, Scheme or Java. > """ > taken from > http://www.python.org/doc/Summary.html > > maybe someone could update that??? Maybe we should add '''...for some definitions of "interpreted", "object-oriented", and perhaps even "interactive". ''' I've seen at least the first two debated endlessly here. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Donn Cave <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> > wrote: > >> Donn Cave <[EMAIL PROTECTED]> writes: >> > I agree that there are many shades of grey here, but there's also a >> > real black that's sharply distinct and easy to find -- real native >> > code binaries are not interpreted. >> >> Except when they are. Many machines are microcoded, which means your >> "real native code binary" is interpreted by a microcode program stored >> in the control store. Most machines don't have a writeable control >> store (WCS), so you generally can't change the interpreter, but that's >> not always true. In the simple case, a WCS lets the vendor fix >> "hardware" bugs by providing a new version of the microcode. In the >> extreme cases, you get OS's in which the control store is part of the >> process state, so different processes can have radically different >> formats for their "native code binaries". >> >> Then there's the Nanodata QM-1, whose microcode was interpreted by >> "nanocode". > > Fine -- given a Python Chip computer, Python programs are > native code. It can use microcode, if that helps. Historical evidence is that general purpose CPUs will (eventually) outperform custom Python chip. > The VAX/11 microcode was just a software extension of the > CPU hardware, implementing some extra instructions, the way > I remember it. I don't recall that it was of any more than > academic interest to anyone using the computer - though it > may have been software in a sense, it was on the hardware > side of the wall. It was of more than academic interest to people interested in performance. As you moved up and down the VAX line, instructions migrated into/out of microcode, and the relative performance of the instructions changed. In particular, the magic "evaluate a polynomial" instruction - which made doing multi-dimensional array indexing trivial - was slower or faster than the obvious sequence of simple instructions for doing the same depending on whether or not that instruction was interpreted. >From (roughly) the same era, the 370 line was all microcoded. The machines in the line had *radically* different underlying architectures. Estimates were that if you could write to the native hardware, you'd pick up about 10% in performance - but your code wouldn't port to any other machine 370 in the 370 line. Just to be strange, some of the 370s had control stores in main memory. Meaning a stray pointer could trash your instruction set. > On the software side of the wall, if your program can go over the > wall by itself, then it's native. And what does "by itself" mean? If it requires that you load the WCS, does that mean it's interpreted? What if what it wants in the WCS is required to run the OS? What if what it wants in the WCS isn't required to run the OS, but is always loaded on the system the author runs on, or is available as an extension module from the vendor, or ... Software is so squishy. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Dennis Lee Bieber wrote: > I'd consider that BASIC to be a fully interpreted language, as the > tokens are still a one-for-one equivalence of the source code. Python, > UCSD, and Java are not one-for-one, so on that basis, they fit the > definition of a compiled language... That's an interesting definition which at least attempts to consider the issue from a perspective other than that which is concerned with whether hardware is in use, what kind of hardware, and so on. > The difficulty is that the target architecture in not realized in hardware. Or isn't perhaps feasible/viable for hardware realisation: one of the EuroPython speakers dangled the promise of hardware support for high-level languages (the classic "Python on a chip" concept), but there are probably plenty of areas where hardware support can assist software virtual machines without going to all the trouble of implementing such virtual machines in hardware completely. > And then... I believe the PowerPC chipset emulated the 680xx instruction set, > didn't it? There may have been some architectural overlap between PowerPC and M68K, but the PowerMacintosh computers used dynamic recompilation/translation software to execute legacy applications. In the case of CPython, the principal technological factor in determining how "interpreted" it is seems to be the complexity of the bytecode instructions, and I believe some work was done to investigate other instructions that might improve performance [2]. Were the most complex instructions replaced with simpler ones, a more performant implementation might be possible, although the work required to translate programs to such a simplified instruction set is very difficult indeed. On the subject of other virtual machine implementations, I wonder what happened to this one: http://effbot.org/zone/pytte.htm Fredrik? ;-) Paul [1] Theo F. de Ridder, "Enabling bare Python as universal connector for ad-hoc networks": http://www.python-in-business.org/ep2005/download.cpy?document=8912 (warning: huge presentation!) [2] Brett Cannon, "Localized Type Inference of Atomic Types in Python": http://www.ocf.berkeley.edu/~bac/thesis.pdf -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> wrote: > Donn Cave <[EMAIL PROTECTED]> writes: > > I agree that there are many shades of grey here, but there's also a > > real black that's sharply distinct and easy to find -- real native > > code binaries are not interpreted. > > Except when they are. Many machines are microcoded, which means your > "real native code binary" is interpreted by a microcode program stored > in the control store. Most machines don't have a writeable control > store (WCS), so you generally can't change the interpreter, but that's > not always true. In the simple case, a WCS lets the vendor fix > "hardware" bugs by providing a new version of the microcode. In the > extreme cases, you get OS's in which the control store is part of the > process state, so different processes can have radically different > formats for their "native code binaries". > > Then there's the Nanodata QM-1, whose microcode was interpreted by > "nanocode". Fine -- given a Python Chip computer, Python programs are native code. It can use microcode, if that helps. The VAX/11 microcode was just a software extension of the CPU hardware, implementing some extra instructions, the way I remember it. I don't recall that it was of any more than academic interest to anyone using the computer - though it may have been software in a sense, it was on the hardware side of the wall. On the software side of the wall, if your program can go over the wall by itself, then it's native. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Mike Meyer wrote: > Donn Cave <[EMAIL PROTECTED]> writes: > >>I agree that there are many shades of grey here, but there's also a >>real black that's sharply distinct and easy to find -- real native >>code binaries are not interpreted. > > > Except when they are. Many machines are microcoded, which means your > "real native code binary" is interpreted by a microcode program stored > in the control store. Most machines don't have a writeable control > store (WCS), so you generally can't change the interpreter, but that's > not always true. In the simple case, a WCS lets the vendor fix > "hardware" bugs by providing a new version of the microcode. In the > extreme cases, you get OS's in which the control store is part of the > process state, so different processes can have radically different > formats for their "native code binaries". > > Then there's the Nanodata QM-1, whose microcode was interpreted by > "nanocode". Or the transmeta processor, that emulated x86 ops. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
On Saturday 08 October 2005 01:54 pm, Fredrik Lundh wrote: > Dave wrote: > > Yes, I would like to know how many internal string operations are done > > inside > > the Python interpreter. > > when you're doing what? > > how do you define "internal string operations", btw? He's got to be talking about runtime name-binding. In other words, when you refer to: a.spam the Python interpreter actually knows you labeled that attribute 'spam', and the string is stored in a.__dict__ , so you can also access it as getattr(a, 'spam') etc. I'm pretty sure this is what string "internment" is for, though, and that such lookups are optimized out pretty much whenever possible. -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Donn Cave <[EMAIL PROTECTED]> writes: > I agree that there are many shades of grey here, but there's also a > real black that's sharply distinct and easy to find -- real native > code binaries are not interpreted. Except when they are. Many machines are microcoded, which means your "real native code binary" is interpreted by a microcode program stored in the control store. Most machines don't have a writeable control store (WCS), so you generally can't change the interpreter, but that's not always true. In the simple case, a WCS lets the vendor fix "hardware" bugs by providing a new version of the microcode. In the extreme cases, you get OS's in which the control store is part of the process state, so different processes can have radically different formats for their "native code binaries". Then there's the Nanodata QM-1, whose microcode was interpreted by "nanocode". http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Fredrik, but still some very valuable people write: """ What is Python? Python is an interpreted, interactive, object-oriented programming language. It is often compared to Tcl, Perl, Scheme or Java. """ taken from http://www.python.org/doc/Summary.html maybe someone could update that??? Harald -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
In article <[EMAIL PROTECTED]>, "Fredrik Lundh" <[EMAIL PROTECTED]> wrote: > Donn Cave wrote: > > > | > Except it is interpreted. > > | > > | except that it isn't. Python source code is compiled to byte code, which > > | is then executed by a virtual machine. if the byte code for a module is > > | up > > | to date, the Python runtime doesn't even look at the source code. > > > > Fair to say that byte code is interpreted? Seems to require an > > application we commonly call an interpreter. > > well, the bytecode isn't Python (the transformation isn't exactly straight- > forward, as we've seen in other posts I've made today). > > and even if the bytecode engine used in CPython can be viewed as an inter- > preter, does that make Python an interpreted language? what about Python > code that uses a runtime that converts it to machine code? (e.g. Psycho, > Iron- > Python). is it still an interpreter if it generates machine code? Is what an interpreter? I am not very well acquainted with these technologies, but it sounds like variations on the implementation of an interpreter, with no really compelling distinction between them. When a program is deployed as instructions in some form other than native code executable, and therefore those instructions need to be evaluated by something other than the hardware, then that would be some kind of interpretation. I agree that there are many shades of grey here, but there's also a real black that's sharply distinct and easy to find -- real native code binaries are not interpreted. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Python enjoyment (was Re: Python's Performance)
Ditto to the below! I quite literally considered leaving the CS field until I found Python. Now my main job description is 'technical writing', but I get to use python at work (MoinMoin) and for all of my own computing needs.Cheers,KenOn 10-Oct-05, at 2:03 AM, Ron Adam wrote:If I was forced to go back to MS C++ again, I think I would take up painting instead of programing as my main hobby. ;-) Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Steven D'Aprano wrote: > For what it is worth, Python is compiled AND interpreted -- it compiles > byte-code which is interpreted in a virtual machine. That makes it an > compiling interpreter, or maybe an interpreting compiler, in my book. Good points, and in addition to this, the individual byte codes and many builtin routines in python are compiled 'C' code. So it's really a matter of how many level of indirect references are between the the application code and the internal cpu registers. Even in assembly language you can program though indirect data structures to simplify overall program design. I really think the performance differences will get narrower as Python is developed further. I for one would much rather have a language I can program new things in a matter of days, rather than one which would require a few thousand pages of reference material just to figure out where to start. If I was forced to go back to MS C++ again, I think I would take up painting instead of programing as my main hobby. ;-) Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
On Sun, 09 Oct 2005 21:00:57 +, Dennis Lee Bieber wrote: > I'd consider that BASIC to be a fully interpreted language, as the > tokens are still a one-for-one equivalence of the source code. Python, > UCSD, and Java are not one-for-one, so on that basis, they fit the > definition of a compiled language... The difficulty is that the target > architecture in not realized in hardware. > > And then... I believe the PowerPC chipset emulated the 680xx > instruction set, didn't it? So does that mean old 680xx Mac programs, in > whatever the original language was, are now "interpreted languages" when > run on the first PPC Macs (prior to a native PPC build becoming > available)? In case it isn't obvious by now, compiled and interpreted are fuzzy concepts, with lots of wiggle room between them. Your compiled machine code is interpreted by the CPU. "Compiled" versus "interpreted" are descriptions that made more sense when there was little overlap between the two. Once byte-code compilers running an interpreter in a virtual machine came on the scene, the distinction became less useful. For what it is worth, Python is compiled AND interpreted -- it compiles byte-code which is interpreted in a virtual machine. That makes it an compiling interpreter, or maybe an interpreting compiler, in my book. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Donn Cave wrote: > | > Except it is interpreted. > | > | except that it isn't. Python source code is compiled to byte code, which > | is then executed by a virtual machine. if the byte code for a module is up > | to date, the Python runtime doesn't even look at the source code. > > Fair to say that byte code is interpreted? Seems to require an > application we commonly call an interpreter. well, the bytecode isn't Python (the transformation isn't exactly straight- forward, as we've seen in other posts I've made today). and even if the bytecode engine used in CPython can be viewed as an inter- preter, does that make Python an interpreted language? what about Python code that uses a runtime that converts it to machine code? (e.g. Psycho, Iron- Python). is it still an interpreter if it generates machine code? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Quoth "Fredrik Lundh" <[EMAIL PROTECTED]>: | Alex Stapleton wrote | | > Except it is interpreted. | | except that it isn't. Python source code is compiled to byte code, which | is then executed by a virtual machine. if the byte code for a module is up | to date, the Python runtime doesn't even look at the source code. Fair to say that byte code is interpreted? Seems to require an application we commonly call an interpreter. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Alex Stapleton wrote > Except it is interpreted. except that it isn't. Python source code is compiled to byte code, which is then executed by a virtual machine. if the byte code for a module is up to date, the Python runtime doesn't even look at the source code. > What is your point? that some people have trouble distinguishing interpreters from compilers, and find mixed paradigms confusing? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
On 9 Oct 2005, at 19:04, Bruno Desthuilliers wrote: > Laszlo Zsolt Nagy a écrit : > > >> Dave wrote: >> >> >> >>> Hello All, >>> >>> I would like to gather some information on Python's runtime >>> performance. As far as I understand, it deals with a lot of string >>> objects. Does it require a lot string processing during program >>> execution? How does it handle such time-consuming operations? Is >>> there >>> a way to find out how many string operations (perhaps in the >>> underlying system) ) it does during program execution? >>> >>> >> >> >> Do you want to know how many internal string operations are done >> inside >> the Python interpreter? I believe it is not a useful information. >> There >> are benchmarks testing the *real performance* of Python. >> >> For example: http://www.osnews.com/story.php?news_id=5602 >> >> >> > > A benchmark stating that Python is interpreted is bullshit. > > Except it is interpreted. What is your point? Python != C -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Laszlo Zsolt Nagy a écrit : > Dave wrote: > >> Hello All, >> >> I would like to gather some information on Python's runtime >> performance. As far as I understand, it deals with a lot of string >> objects. Does it require a lot string processing during program >> execution? How does it handle such time-consuming operations? Is there >> a way to find out how many string operations (perhaps in the >> underlying system) ) it does during program execution? > > > Do you want to know how many internal string operations are done inside > the Python interpreter? I believe it is not a useful information. There > are benchmarks testing the *real performance* of Python. > > For example: http://www.osnews.com/story.php?news_id=5602 > A benchmark stating that Python is interpreted is bullshit. > Les > -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
On Sat, 08 Oct 2005 10:14:25 -0700, Phillip J. Eby wrote: > So, without meaning to, the benchmark author has demonstrated something > important about Python, which is that writing the obvious thing in > Python tends to work correctly, even if it sometimes takes longer to > run than it would take for another language to produce the wrong > answer. :) Which is of course demonstrates two different strategies of programming. The first is, "I don't care what answer I get, so long as I get it quickly!". The second is, "I don't care how long it takes, so long as I get the right answer!" The smart programmer will understand that both strategies can be the right one in different circumstances. For instance, the Apollo landers didn't have the computing power to calculate the right answer quickly enough to prevent the lander from burying itself deep beneath the moon's surface, so they used a strategy of calculating the wrong answer quickly, then incrementally improving it. I'm told that the Apollo 11 lander's computer rebooted something like 20 times in the few minutes it took to go from orbit to the surface. It would crash, reboot, and just pick up the calculations from the last one that completed. Try doing that with Wintel! :-) -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Dave wrote: > Yes, I would like to know how many internal string operations are done inside > the Python interpreter. when you're doing what? how do you define "internal string operations", btw? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Paul Boddie wrote: >> There are benchmarks testing the *real performance* of Python. >> >> For example: http://www.osnews.com/story.php?news_id=5602 > > Just the observation that there are 166 comments to that article would > suggest that the methodology employed was somewhat debatable. (I don't > need to read them all - it is OSNews, after all.) > > As for the "real performance" of Python, what do we learn from these > benchmarks which "...didn't test string manipulation, graphics, object > creation and management (for object oriented languages), complex data > structures, network access, database access, or any of the countless > other things that go on in any non-trivial program"? That Python > doesn't perform well executing loops involving mathematical operations? fwiw, if you leave out the environments that compile to native machine code, CPython is the fastest runtime in this floating-point benchmark: http://www.fourmilab.ch/fbench/fbench.html (I recently translated some satellite navigation code from a Python prototype to C, and was a bit surprised to find that I only got a 7x speedup...) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Yes, I would like to know how many internal string operations are done inside the Python interpreter. Thanks. Laszlo Zsolt Nagy <[EMAIL PROTECTED]> wrote: Dave wrote:> Hello All,> > I would like to gather some information on Python's runtime > performance. As far as I understand, it deals with a lot of string > objects. Does it require a lot string processing during program > execution? How does it handle such time-consuming operations? Is there > a way to find out how many string operations (perhaps in the > underlying system) ) it does during program execution?Do you want to know how many internal string operations are done inside the Python interpreter? I believe it is not a useful information. There are benchmarks testing the *real performance* of Python.For example: http://www.osnews.com/story.php?news_id=5602Les Yahoo! Music Unlimited - Access over 1 million songs. Try it free.-- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Laszlo Zsolt Nagy wrote: > Dave wrote: > > > Hello All, > > > > I would like to gather some information on Python's runtime > > performance. As far as I understand, it deals with a lot of string > > objects. Does it require a lot string processing during program > > execution? How does it handle such time-consuming operations? Is there > > a way to find out how many string operations (perhaps in the > > underlying system) ) it does during program execution? > > Do you want to know how many internal string operations are done inside > the Python interpreter? I believe it is not a useful information. There > are benchmarks testing the *real performance* of Python. > > For example: http://www.osnews.com/story.php?news_id=5602 Actually, that benchmark shows something rather interesting. The C and Java versions of the benchmark are much faster than Python on so-called "64-bit arithmetic", but only Python computes the *correct* answer to the benchmark! The others overflow 64 bits at some point and lose precision, resulting in a nonsense result that the author failed to notice. So, without meaning to, the benchmark author has demonstrated something important about Python, which is that writing the obvious thing in Python tends to work correctly, even if it sometimes takes longer to run than it would take for another language to produce the wrong answer. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Laszlo Zsolt Nagy wrote: > There are benchmarks testing the *real performance* of Python. > > For example: http://www.osnews.com/story.php?news_id=5602 Just the observation that there are 166 comments to that article would suggest that the methodology employed was somewhat debatable. (I don't need to read them all - it is OSNews, after all.) As for the "real performance" of Python, what do we learn from these benchmarks which "...didn't test string manipulation, graphics, object creation and management (for object oriented languages), complex data structures, network access, database access, or any of the countless other things that go on in any non-trivial program"? That Python doesn't perform well executing loops involving mathematical operations? Or something about "research and development" in the big consulting houses? Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Dave wrote: > Hello All, > > I would like to gather some information on Python's runtime > performance. As far as I understand, it deals with a lot of string > objects. Does it require a lot string processing during program > execution? How does it handle such time-consuming operations? Is there > a way to find out how many string operations (perhaps in the > underlying system) ) it does during program execution? Do you want to know how many internal string operations are done inside the Python interpreter? I believe it is not a useful information. There are benchmarks testing the *real performance* of Python. For example: http://www.osnews.com/story.php?news_id=5602 Les -- http://mail.python.org/mailman/listinfo/python-list
Python's Performance
Hello All, I would like to gather some information on Python's runtime performance. As far as I understand, it deals with a lot of string objects. Does it require a lot string processing during program execution? How does it handle such time-consuming operations? Is there a way to find out how many string operations (perhaps in the underlying system) ) it does during program execution? Thanks a lot for your help! Yahoo! Music Unlimited - Access over 1 million songs. Try it free.-- http://mail.python.org/mailman/listinfo/python-list
Re: python's performance
> > Have u been used such camera with PIL before?
> >
> > im_1= Image.fromstring("I", datasize, buf, 'raw', 'I;16')
running on a 700 MHz box:
c:\> timeit -s "import Image" -s "data = 1344*1024*2*'x'"
"im = Image.fromstring('I', (1344, 1024), data, 'raw', 'I;16')"
10 loops, best of 3: 102 msec per loop
running on a 3.0 GHz box:
c:\> timeit -s "import Image" -s "data = 1344*1024*2*'x'"
"im = Image.fromstring('I', (1344, 1024), data, 'raw', 'I;16')"
10 loops, best of 3: 34.7 msec per loop
I somehow doubt that this takes 1 full second on a 2.0 GHz PC.
--
http://mail.python.org/mailman/listinfo/python-list
Re: python's performance
> On 9/29/05, James Hu wrote:
> > Hi,
> >
> > I used python and PIL to capture image from a digital camera,
> > It seems like it took more than 1 second to capture a 1280x1024 image,
> > however, the demo capturing application from the company (coded by VB)
> > took only .2s or less for one image with the same size.
> > Don't know why python and PIL is so slow, any idea to improve the
> > performance? Thanks a lot!
> >
> > James
> >
> > --
> > http://mail.python.org/mailman/listinfo/python-list
> >
>
> Bill Mill wrote:
> You've gotta framinate your capacitor to speed it up.
>
> (Translated: With no information about your camera, memory card, type
> of connection, platform, method of access, version of python, version
> of PIL, or code, how in the world could I help you to diagnose your
> loosely-specified problem? Ask something that's answerable, and we'll
> try to help you.)
>
> Peace
> Bill Mill
> bill.mill at gmail.com
>
On 9/29/05, James Hu <[EMAIL PROTECTED]> wrote:
> Thanks for your fast reply.
>
> Camera, HAMAMATSU C4742-95-12G04, IEEE1394-based,
> Can capture frame at 8.8/s at full resolution 1344X1024
> Memory: 512M
> Platform: Win2K and DELL 2.0GHz P4
> Python 2.4
> PIL: 1.15
>
> Have u been used such camera with PIL before?
>
> im_1= Image.fromstring("I", datasize, buf, 'raw', 'I;16')
>
> Your help would be greatly appreciated!
>
> James
>
Where do datasize and buf come from? Have you profiled your
application to make sure that it is the Image.fromstring line which is
slowing down your code? (If you don't know how to profile, just ask)
Peace
Bill Mill
bill.mill at gmail.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: python's performance
You've gotta framinate your capacitor to speed it up. (Translated: With no information about your camera, memory card, type of connection, platform, method of access, version of python, version of PIL, or code, how in the world could I help you to diagnose your loosely-specified problem? Ask something that's answerable, and we'll try to help you.) Peace Bill Mill bill.mill at gmail.com On 9/29/05, James Hu <[EMAIL PROTECTED]> wrote: > Hi, > > I used python and PIL to capture image from a digital camera, > It seems like it took more than 1 second to capture a 1280x1024 image, > however, the demo capturing application from the company (coded by VB) > took only .2s or less for one image with the same size. > Don't know why python and PIL is so slow, any idea to improve the > performance? Thanks a lot! > > James > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
python's performance
Hi, I used python and PIL to capture image from a digital camera, It seems like it took more than 1 second to capture a 1280x1024 image, however, the demo capturing application from the company (coded by VB) took only .2s or less for one image with the same size. Don't know why python and PIL is so slow, any idea to improve the performance? Thanks a lot! James -- http://mail.python.org/mailman/listinfo/python-list
