The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[BartC]

On 23/03/2016 06:09, Ben Finney wrote:

> The problem is that Bart simultaneously is a beginner at Python, and
> expresses astonishment that everyone shrugs when Bart's
> dreadfully-written code performs so badly.

My interests differ from most people here writing Python.

For example, I'm interested in byte-code (any byte-code) and what can be 
done with it. Investigating how well it performs in 'extreme' cases 
means executing algorithms predominantly in byte-code, not measuring how 
well some library function (in some unspecified language) can cope with 
the algorithm.

And doing it 'Pythonically' can lead to suggestions such as the 
following the other day:

  c, psource = psource[0], psource[1:]

(where psource is a very long string), which even I could tell, from 
knowing what goes on behind the scenes, wasn't going to work well 
(duplicating the rest of the string roughly every other character).

A couple of years ago I had a project which tried to use a universal 
syntax to express algorithms, and translating it into various languages. 
The following code was generated for Python.

(/This/ is also quite a good way of learning a language, by figuring out 
how to implement a specific feature in one language, in another. Another 
way is to try and implement it...)

'N-Sieve' benchmark:

# Python source output
import sys
import math
import copy

def nsieve(m):
   flags = ([1]*(m+1))
   count = 0
   for i in range(3,m+1):
     if flags[i]:
       count += 1
       j = (i+i)
       while (j<=m):
         if flags[j]:
           flags[j] = 0
         j = (j+i)
   sys.stdout.write(str("Primes up to "))
   sys.stdout.write(str(m))
   sys.stdout.write(str(": "))
   sys.stdout.write(str(count))
   sys.stdout.write("\n")
   return count

def start():
   nsieve(5120000)
   nsieve(2560000)
   nsieve(1280000)

start()

(The sys writes are used as it was easier than figuring out how to 
reliably control spacing and newlines using 'print'. The m+1's I think 
are there because the algorithm I used was 1-based).

In the case of this project, the source syntax was intended as a wrapper 
around actual Python; it was not a language in its own right. (Although, 
these simple benchmarks could generate Python, Lua or Lisp from the 
exact same source. I know zilch about Lisp, except what I had to figure 
out to make this work, and which I promptly forgot again. But the 
resulting code ran perfectly!)

But I'd be more interesting now in translating another actual language 
to Python. Now, the resulting Python is likely to be low-quality, with 
extra code needed to match the source semantics. Then performance could 
well be a factor not entirely offset by the novelty of watching Python 
flawlessly execute a program not written in Python.

> Good faith is contradicted by asserting knowledge of Python, complaining
> about how some deliberately non-idiomatic Python code is performing
> poorly, dismissing suggestions for improvement — specifically in the
> context of someone who admittedly knows so little about Python.

Someone could be interested in cars, mechanics and performance without 
wanting to know the most Pythonic way to get from Kings Cross to Heathrow.

-- 
Bartc