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

Groups > comp.programming > #5155

Re: compiling python

Show all headers | View raw

On 24/01/2015 16:58, Kaz Kylheku wrote:
> On 2015-01-24, BartC <bc@freeuk.com> wrote:
>> On 11/01/2015 19:24, Kaz Kylheku wrote:

>>> 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:

Sorry, that should be 1000000000 (1 billion). I needed to reduce it so 
that testing Python 3 wouldn't take so long. All the timings are for a 
count of 1 billion.

(Perhaps trivial language enhancements such as separators in numeric 
literals would be more usefully implemented before bolting on ad-hoc 
type systems!)

>> 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.

What's the trick? And why isn't it used more often? It it involves using 
Cython or writing anything in C, then it doesn't count. Otherwise we'd 
just use the fastest possible language for any task.

>> 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.

OK, let's say 2.1 seconds for a billion. That compares very well with 
the above timings (ignoring the fact that your machine might be faster 
or slower than mine).

Actually when I first tried your code with CLISP, I was quite impressed: 
it finished instantly whatever value I used for the loop. Then I 
discovered I had to add (test) at the end!

CLISP took 65 seconds for the above, so presumably 10-11 minutes for a 
billion. This is on the same machine where my /bytecode interpreter/ 
executes in 3.7 seconds.

This is part of my point: why are there so many slow interpreters 
around? What on earth are they doing for them to take so long? But 
whatever the bottleneck is, the lack of type information is unlikely to 
be the problem.

>    ? (disassemble 'test)

>    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]

> 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)
<snip>

So you're saying it doesn't matter too much whether static type 
information is present or not?

But it seems that you have a very effective language which is capable of 
generating fast native code; why doesn't Python do the same? (Maybe it 
could just be translated to your Lisp!)

Anyway we're not comparing the same things. I'm saying my /bytecode/ 
interpreter with /dynamic/ type dispatch can perform quite respectively 
compared with your implementation that directly executes /native code/.

And I don't know how much of a built-in 'do' is for Lisp, but if I use a 
more dedicated loop statement, I can improve the timings a little:

i:=0
while i< 1 billion do      # 3.7 seconds
     ++i
end

for i to 1 billion do      # 2.2 seconds
end

to 1 billion do            # 2.0 seconds
end

As I said, adding type info doesn't buy me much; I'd rather keep the 
language uncluttered.

-- 
Bartc

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