Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming > #6265

Re: First Program with Python!

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.programming
Subject Re: First Program with Python!
Date 2016-02-10 16:24 +0100
Organization A noiseless patient Spider
Message-ID <n9fki0$576$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>

Show all headers | View raw


On 10/02/16 15:07, BartC wrote:
> On 10/02/2016 00:32, Öö Tiib wrote:
>> On Tuesday, 9 February 2016 16:30:19 UTC+2, Richard Heathfield  wrote:
>>> On 09/02/16 14:11, anitagoyal571@gmail.com wrote:
>>>   > Python is an interpreted language.
>>>   > Interpreter is a program that converts the high-level program we
>>>   > write into low-level program that the computer understands.
>>>
>>> That sounds more like a compiler to me.
>>
>> Good catch. AFAIK Python is simply a programming language without
>> requirement that it *must* be interpreted. There even are some
>> JIT-compiling Python 3 implementations like PyPy and Pyston.

There are few programming languages that /must/ be interpreted, or
/must/ be compiled.  There are C and C++ interpreters available.  And
for many traditionally interpreted languages, there are compilers for
all or part of the language.  (Python is mostly byte-compiled, with the
python byte-code run in a dedicated virtual machine.  Jython compiles
Python source to Java byte code and runs it on a Java virtual machine.)

The exception is for code that is not known at "compile" time, such as
creating Python code from a string - that would have to be interpreted
or JIT-compiled.

>>
> 
> PyPy is such a complex implementation that probably no one knows for
> sure exactly what it is.
> 
> 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. So what is
> JIT-compiled, I think, are parts of the interpreter, which is written in
> customised version of Python. It doesn't JIT-compile the user's actual
> program, AFAICT.

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.

So the user's Python code, along with the Python libraries, get
JIT-compiled.


> 
> It's just a touch confusing.
> 
> 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.

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


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