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


Groups > comp.programming > #5078

Re: compiling python

From Kaz Kylheku <kaz@kylheku.com>
Newsgroups comp.programming
Subject Re: compiling python
Date 2015-01-10 19:19 +0000
Organization Aioe.org NNTP Server
Message-ID <20150110110749.53@kylheku.com> (permalink)
References <39a759ea-06c0-4e33-93e8-6c5f99fa9303@googlegroups.com> <cPZrw.416147$Kl4.243354@fx01.am4>

Show all headers | View raw


On 2015-01-09, BartC <bc@freeuk.com> wrote:
> On 09/01/2015 23:36, fir wrote:
>> can someone explain if python can be compiled (to exe) if not why cant be compiled
>
> Try comp.lang.python. That's quite active.
>
>> afaik python is not quite compiled but more like
>> interpreter+bytecode contained in exe form..
>> really there is something that disallows compilation of script languages? I do not
>> understand this thing, what is really the thing that makes scripts not compilable?
>
> You can certainly create a self-contained executable, but it might not 
> be any faster than running the interpreter. Take this bit of code:
>
>   a=b+c
>
> In a scripting language with dynamic types, what would you compile it 
> to? You don't know what the types are! They could be integers, floats, 
> strings, lists, tuples, ranges, functions, classes or any combination. 
> You have to sort this all out at runtime, which is not going to be 
> helped by compiling.

Yes, it is still helped by compiling.

Firstly, the compiler knows certain facts, such as that a, b, and c are (let us
say) lexical variables and can generate fast references to them.

A pure interpreter, by contrast, has to look these things up: it looks at a
and wonders, is that a local? A global? It has to do some environmental lookup.

It also might take advantage of knowing that + is a language built-in that
cannot be redefined (let's say).

The compiled code just does something like:

  load R0, offset_b(R29)   ;; R29 is the current closure
  load R1, offset_c(R23)
  call builtin_plus        ;; result is in R0
  store offset_a(R29), R0  ;; store in a

Though builtin_plus does the work, this compiled code saves cycles
compared to the actions which have to be carried out by pure
interpretation, which basically does:

  (eval '(set a (+ a b)) current-env)

eval has to look at "set", invoke the right operator for that,
then set has to analyze the target place a, looking up its location
(probably by calling a function). Then it has to recursively call

  (eval '(+ a b) current-env)

to get the value and so on.


basically, you're neglecting to look at this from the point of view that
a, b and c can be regarded as variables having the generic type "value",
and that the expression is basically just like C:

  a = builtin_plus(b, c);

you wouldn't say that compiling a function call and assignment isn't
beneficial, right? Even if a, b and c are pointers, and the function
actually has to be called.

On top of that, advanced dynamic languages support optimization. If you
promise to the compiler, via declarations, that a, b, and c have certain
types, then it can generate better code.

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


Thread

compiling python fir <profesor.fir@gmail.com> - 2015-01-09 15:36 -0800
  Re: compiling python BartC <bc@freeuk.com> - 2015-01-09 23:50 +0000
    Re: compiling python fir <profesor.fir@gmail.com> - 2015-01-09 15:59 -0800
      Re: compiling python BartC <bc@freeuk.com> - 2015-01-10 11:45 +0000
        Re: compiling python fir <profesor.fir@gmail.com> - 2015-01-10 07:09 -0800
    Re: compiling python Kaz Kylheku <kaz@kylheku.com> - 2015-01-10 19:19 +0000
      Re: compiling python BartC <bc@freeuk.com> - 2015-01-10 22:02 +0000
        Re: compiling python fir <profesor.fir@gmail.com> - 2015-01-11 10:52 -0800
        Re: compiling python Kaz Kylheku <kaz@kylheku.com> - 2015-01-11 19:24 +0000
          Re: compiling python BartC <bc@freeuk.com> - 2015-01-11 20:23 +0000
          Re: compiling python BartC <bc@freeuk.com> - 2015-01-24 15:01 +0000
            Re: compiling python Kaz Kylheku <kaz@kylheku.com> - 2015-01-24 16:58 +0000
              Re: compiling python Bartc <bc@freeuk.com> - 2015-01-24 19:18 +0000
                Re: compiling python Kaz Kylheku <kaz@kylheku.com> - 2015-01-24 23:54 +0000
                Re: compiling python Bartc <bc@freeuk.com> - 2015-01-25 01:26 +0000
  Re: compiling python Robert Wessel <robertwessel2@yahoo.com> - 2015-01-09 18:13 -0600
    Re: compiling python fir <profesor.fir@gmail.com> - 2015-01-09 16:27 -0800
  Re: compiling python Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-01-12 18:28 +0100

csiph-web