Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming > #5154
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Newsgroups | comp.programming |
| Subject | Re: compiling python |
| Date | 2015-01-24 16:58 +0000 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <20150124081944.210@kylheku.com> (permalink) |
| References | (1 earlier) <cPZrw.416147$Kl4.243354@fx01.am4> <20150110110749.53@kylheku.com> <bkhsw.531647$dG.86517@fx32.am4> <20150111112226.707@kylheku.com> <TsOww.430908$BB2.193851@fx35.am4> |
On 2015-01-24, BartC <bc@freeuk.com> wrote:
> On 11/01/2015 19:24, Kaz Kylheku wrote:
>> On 2015-01-10, BartC <bc@freeuk.com> wrote:
>>> On 10/01/2015 19:19, Kaz Kylheku wrote:
>>>> 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.
>>>
>>> That wouldn't count as pure Python then (but as a different version,
>>> perhaps CPython). When I tried adding type info to my own language
>>> efforts, the modest gains weren't worth the extra complexity or losing
>>> the elegance of the language's variant types.
>>
>> I see, and whatever you've been able to achieve is representative of
>> what is possible. Nay, the upper bound.
>
> There is a thread now on comp.lang.python ('Python is doomed! Again!')
> about a proposal to add type-hinting to the language. Many are against
> it because it's ugly and clutters up the code. No-one mentioned what the
> benefits are or whether the intention was to make it faster.
>
> (But what I said about not using type info in my own dynamic language is
> not quite right: I do use type info for defining packed arrays and
> structs, and pointers to raw types. Mainly for interfacing with foreign
> functions or with the OS, not for speed. Actually working with such data
> is slower.)
>
> > I see, and whatever you've been able to achieve is representative of
> > what is possible. Nay, the upper bound.
>
> Take a simple while-loop like this:
>
> def whiletest():
> i=0
> while i<=100000000:
> i=i+1
>
> whiletest()
>
> Execution time:
>
> Python: 120 seconds (normal Python 3 interpreter in C)
> MyLang: 3.7 seconds (pure byte-code interpeter)
> PyPy: 1.3 seconds (jit/tracing etc etc)
> C: 2.7 seconds (native code but unoptimised)
> C: 0.8 seconds (native code, optimised)
> C: 0.0 seconds (when C discards the code completely, however
> these implementations could all employ the same
> trick if they were inclined.)
Yes, well, the entire problem can be cast in terms of not being "inclined".
Python could employ a trick that makes it run in 2.7 seconds, if it were so
inclined, and in 0.8 seconds if it were inclined, all the way down to 0.0
as you note.
> You can see there is quite a difference (some 30 times slower) between
> my little language and Python.
Clozure Common Lisp:
(defun test ()
(do ((i 0 (1+ i)))
((> i 100000000))
(declare
(type fixnum i)
(optimize (speed 3) (safety 0)))))
CPU: Intel Core-i5-2310, 2.9 GHz.
? (time (test))
(TEST)
took 210 milliseconds (0.210 seconds) to run.
During that period, and with 4 available CPU cores,
218 milliseconds (0.218 seconds) were spent in user mode
0 milliseconds (0.000 seconds) were spent in system mode
32 bytes of memory allocated.
NIL
? (disassemble 'test)
(recover-fn) ; [0]
(testl (% temp1) (% temp1)) ; [5]
(jne L50) ; [7]
(pushl (% ebp)) ; [9]
(movl (% esp) (% ebp)) ; [10]
(pushl ($ 0)) ; [12]
(jmp L25) ; [14]
L16
(movl (@ -4 (% ebp)) (% arg_z)) ; [16]
(addl ($ 4) (% arg_z)) ; [19]
(movl (% arg_z) (@ -4 (% ebp))) ; [22]
L25
(movl (@ -4 (% ebp)) (% arg_z)) ; [25]
(cmpl ($ #x17D78400) (% arg_z)) ; [28]
(jle L16) ; [34]
(movl ($ #x13001) (% arg_z)) ; [36]
(leavel) ; [41]
(retl) ; [42]
L50
(uuo-error-wrong-number-of-args) ; [50]
If we take out the declare, it's somehow still just as fast,
even though the code is substantially longer and there are type
checks with branching for various cases which either use
instructions or functions.
? (disassemble 'test)
(recover-fn) ; [0]
(testl (% temp1) (% temp1)) ; [5]
(jne L130) ; [7]
(pushl (% ebp)) ; [9]
(movl (% esp) (% ebp)) ; [10]
(pushl ($ 0)) ; [12]
(jmp L71) ; [14]
L16
(movl (@ -4 (% ebp)) (% arg_z)) ; [16]
(testb ($ 3) (% arg_z.b)) ; [19]
(jne L46) ; [22]
(addl ($ 4) (% arg_z)) ; [24]
(jno L68) ; [27]
(leal (@ 0 (% arg_y)) (% arg_y)) ; [29]
(calll (@ .SPFIX-OVERFLOW)) ; [33]
(recover-fn) ; [39]
(jmp L68) ; [44]
L46
(movl ($ 4) (% arg_y)) ; [46]
(leal (@ 0 (% arg_y)) (% arg_y)) ; [51]
(calll (@ .SPBUILTIN-PLUS)) ; [57]
(recover-fn) ; [63]
L68
(movl (% arg_z) (@ -4 (% ebp))) ; [68]
L71
(movl (@ -4 (% ebp)) (% arg_y)) ; [71]
(testl ($ 3) (% arg_y)) ; [74]
(jne L92) ; [80]
(cmpl ($ #x17D78400) (% arg_y)) ; [82]
(jle L16) ; [88]
(jmp L116) ; [90]
L92
(movl ($ #x17D78400) (% arg_z)) ; [92]
(calll (@ .SPBUILTIN-LE)) ; [97]
(recover-fn) ; [103]
(cmpl ($ #x13001) (% arg_z)) ; [108]
(jne L16) ; [114]
L116
(movl ($ #x13001) (% arg_z)) ; [116]
(leavel) ; [121]
(retl) ; [122]
L130
(uuo-error-wrong-number-of-args) ; [130]
Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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