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

[Steven D'Aprano]

On Fri, 25 Mar 2016 12:01 am, BartC wrote:

> But there are all sorts of micro-micro-benchmarks that can concentrate
> on a single byte-code. For example, how long does it take to call an
> empty function with no parameters? Just putting such a call into a
> simple loop can be effective:
>
> Python 3 (on Windows) might take 200ns. Clisp is 1300ns (interpreted,
> presumably). Ruby 170ns. Lua 80ns. Mine 10-20ns. Unoptimised C is 4ns,
> but this is not executing code indirectly as most of the rest have to.

"Might"? Are you making those numbers up?

> [Timings include loop overheads that need to be factored out.]

Then those numbers are pointless. The Python figure, for example, might be
199ns for the loop overhead and 1ns for the function call, or 1ns for the
loop overhead and 199ns for the function call. Or anything in between. How
do you know which is which?

> So there might be room for improvement, but those faster languages are
> also simpler. 

Right.

Let's compare two almost identical looking lines in Python and C:

y = x + 1

y = x + 1;


Apart from the semi-colon, they do exactly the same thing, right?

Well, no. Not even close.

In the case of C, the line is limited to working with some specific type
(say, an int32). Even there, if the addition might overflow, the behaviour
is undefined and the compiler can do anything it wants (including time
travel, or erasing your hard disk).

In the case of Python, the line will work with a potentially infinite number
of types: int, float, complex, Fraction, Decimal, subclasses of all the
above, custom numeric types, and anything else that quacks like a number.
There's no undefined behaviour: at worst, you will get an exception.
There's no integer overflow: you can set x = 10**100 and add one to it, and
the result will be mathematically exact.

Even though the two lines *look* the same, they are as different as chalk
and cheese. If you wrote C code that had the same semantics as the Python
code, chances are it wouldn't be much faster than Python.

This shouldn't be surprising. Python, or at least the standard CPython
interpreter, is written in C. It is, effectively, a DSL ("Domain Specific
Language") for C: all the things which are hard in C, like memory
management, polymorphic code, not segfaulting, etc., are handled for you.

So yes, faster languages are often simpler. They are fast because they do
less. As the saying goes, the fastest code is the code that isn't run.



> Is Python's richness or dynamism the main factor here? If 
> so there is probably little to be done; if not... This is where the fun
> starts.
> 
> But I understand that most people aren't interested in this kind of sport.

Checkout the benchmark game:

http://benchmarksgame.alioth.debian.org/




-- 
Steven