Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming > #6266
| From | BartC <bc@freeuk.com> |
|---|---|
| Newsgroups | comp.programming |
| Subject | Re: First Program with Python! |
| Date | 2016-02-10 16:55 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <n9fps8$q5r$1@dont-email.me> (permalink) |
| References | <56ee81f0-8542-49e5-a177-c7794f2d48d7@googlegroups.com> <n9ct09$phe$1@dont-email.me> <5ef3721a-7b0f-4dfd-8dbf-fac4a7172b94@googlegroups.com> <n9fg1k$jke$1@dont-email.me> <n9fki0$576$1@dont-email.me> |
On 10/02/2016 15:24, David Brown wrote: > On 10/02/16 15:07, BartC wrote: >> From what I've been able to glean, PyPy is actually an interpreter (and >> an even slower one than CPython), but written in such a way that >> repeated execution paths (through the interpreter apparently, not the >> bytecode being executed) are chosen to be JIT-compiled. > PyPy is a Python interpreter with JIT acceleration. Where possible, > Python code is used to generate C code that is then compiled (with gcc > or clang), and called from the PyPy interpreter. Some Python code > cannot sensibly be compiled in this way, and it gets interpreted. I believe PyPy is written in RPython. That is, the interpreter for normal Python is written in a special language called RPython, which looks like Python but restricts those features that make it slow. That RPython undergoes whole-program analysis to turn it into C. So, we now still have a Python intepreter, but it's in C (a bit like the normal CPython), but there is some extra magic in there to optimise 'hot' execution paths. This is where it's unclear as to whether those paths are part of the RPython interpreter, or part of the Python bytecode being executed. I thought it was the former. But the end result is that the Python program ends up faster (sometimes a magnitude or two faster), than normal CPython. In which case, no will really care exactly how it works! Unless someone is discussing whether the Python is being compiled or interpreted... >> You can tell from the language anyway that it is completely unsuitable >> for normal 'straight' compilation to native code. So interpretation >> would be the usual start-point. > Certainly interpretation is the common way to handle Python code. And > static compilation is going to be a lot less efficient than dynamic or > JIT compilation. For example, consider the function: > > def average(it) : > return sum(it) / len(it) > > Your code could call that function with lists of integers, tuples of > floating point, a tree structure of matrix types, or anything else that > supports an iteration interface and whose elements can be added and then > divided by an integer. Clearly any general compiled version of that > function is going to involve a lot of indirect lookup to get the > required functions to operate on the types that happen to be passed to > any particular call of the function. > > But if your code only ever calls the function with tuples of three > floating point numbers, it can be reduced to a few assembly instructions > to operate only on that particular type of argument. So a JIT compiled > version is going to be a great deal smaller and faster than a statically > compiled version could ever be. The JIT compiler needs to find that out first. PyPy for example is good at optimising loops, so if average() is called a million times from a loop, each time with the same type for 'it', then that because a 'hot path'. (Yours is not a good example however because most of the work will be done inside sum(). If this is a built-in, then it will be executing native code N times, not bytecode, even if it still needs to do dynamic type-dispatch for each element.) -- Bartc
Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
First Program with Python! anitagoyal571@gmail.com - 2016-02-09 06:11 -0800
Re: First Program with Python! Richard Heathfield <rjh@cpax.org.uk> - 2016-02-09 14:30 +0000
Re: First Program with Python! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-02-09 14:35 +0000
Re: First Program with Python! Richard Heathfield <rjh@cpax.org.uk> - 2016-02-09 19:06 +0000
Re: First Program with Python! Öö Tiib <ootiib@hot.ee> - 2016-02-09 16:55 -0800
Re: First Program with Python! Richard Heathfield <rjh@cpax.org.uk> - 2016-02-10 09:20 +0000
Re: First Program with Python! Kaz Kylheku <330-706-9395@kylheku.com> - 2016-02-15 16:49 +0000
Re: First Program with Python! Öö Tiib <ootiib@hot.ee> - 2016-02-09 16:32 -0800
Re: First Program with Python! BartC <bc@freeuk.com> - 2016-02-10 14:07 +0000
Re: First Program with Python! David Brown <david.brown@hesbynett.no> - 2016-02-10 16:24 +0100
Re: First Program with Python! BartC <bc@freeuk.com> - 2016-02-10 16:55 +0000
Re: First Program with Python! David Brown <david.brown@hesbynett.no> - 2016-02-11 00:18 +0100
Re: First Program with Python! BartC <bc@freeuk.com> - 2016-02-11 00:07 +0000
Re: First Program with Python! Kaz Kylheku <330-706-9395@kylheku.com> - 2016-02-15 16:58 +0000
Re: First Program with Python! Richard Heathfield <rjh@cpax.org.uk> - 2016-02-10 21:51 +0000
Re: First Program with Python! BartC <bc@freeuk.com> - 2016-02-11 00:15 +0000
Re: First Program with Python! Kaz Kylheku <330-706-9395@kylheku.com> - 2016-02-15 16:46 +0000
Re: First Program with Python! BartC <bc@freeuk.com> - 2016-02-15 17:31 +0000
Re: First Program with Python! Richard Heathfield <rjh@cpax.org.uk> - 2016-02-15 20:16 +0000
Re: First Program with Python! BartC <bc@freeuk.com> - 2016-02-15 22:45 +0000
Re: First Program with Python! Kaz Kylheku <330-706-9395@kylheku.com> - 2016-02-16 03:40 +0000
csiph-web