Static typing [was Re: Python and the need for speed]

bartc bc at freeuk.com
Sun Apr 16 06:55:57 EDT 2017


On 16/04/2017 05:27, Steve D'Aprano wrote:
> On Sat, 15 Apr 2017 11:55 am, Rick Johnson wrote:
>
>> apparently, the py-devs believe we
>> only deserve type declarations that do nothing to speed up
>> code execution (aka: type-hints), instead of type
>> declarations that could actually speed up the code. Go
>> figure!
>>
>> I'm not a fan of forced static typing, but i am a fan of
>> optional static typing.
>
> Are you aware that optional static typing CANNOT be used for optimization?
>
> Since it is *optional*, it is only a hint, not a fact. You can tell the
> compiler that you believe that n will be an int, but it's not guaranteed.

No, Rick distinguished between hints, and actual declarations. It 
doesn't matter if the latter are optional.

I played around with this at one time. All variables were of type 
'variant', unless they had an explicit type declaration.

But it got complicated. I decided to keep the dynamic language pure, as 
after all I had a statically compiled language with exactly the same 
syntax if I needed it faster!

Examples A and B here: https://pastebin.com/D89zP3LF

Example C of the same silly program in Python:

def add(a,b):
     return a+b

def testfn():
     sum=a=b=0
     for i in range(100000000):
         sum += add(a,b)
         a += 1
         b += 2

     print (a,b,sum)

testfn()


Timings:

A (Pure HLL**)          13   seconds      (dynamic/interpreted)
A (With ASM module)      3
A (With ASM module)      2                (older version; hmmm...)

B (my compiler)          0.5              (static/compiled)
B (via C/gcc-O3)         0.14

C (Python 2)           163
C (Python 2/xrange)     30
C (Python 3)            38
C (Pypy)                 5

(Python 2 with 'range' locked up my machine for nearly 3 minutes because 
it presumably exhausted the 4GB memory just executing a simple loop. 
Have I mentioned that building a massive list just to execute 'for' was 
a stupid idea?)

The pypy timing is not bad, however it is misleading: you can't for 
example deduce the execution time of one iteration by dividing by 100 
million, as you can with the others (gcc-O3 excepted as I've no idea 
what it does). You only get that timing if you actually wanted 100 
million iterations.

> (That doesn't necessarily mean that you have to use type declarations, like
> in C, Pascal and Java. A good modern compiler can infer types, like in ML
> and Haskell.)

Yes a good, but more sophisticated, compiler. Unlike mine!

(** The pure HLL timing might be reduced to ~ 9 seconds using 
'label-pointers' for dispatching, but this limited portability when 
converted to C code, as not all C compilers support them. But it doesn't 
matter as I can use the ASM version for speed.

I believe CPython also makes use of label-pointers when compiled with 
gcc - as happens on Linux - but not when compiled with MSVC, so that 
CPython on Windows is a little slower for that reason. I don't know if 
this is still the case.

Those Python timings were on Windows...)

-- 
bartc


More information about the Python-list mailing list