Pyhon 2.x or 3.x, which is faster?

[BartC]

On 07/03/2016 20:47, Chris Angelico wrote:
> On Tue, Mar 8, 2016 at 7:19 AM, BartC <bc at freeuk.com> wrote:

>> What can be more perfect for comparing two implementations?

> rosuav at sikorsky:~$ python2 -m timeit -s 'from fp import Float'
> 'Float("1234.567")'
> 1000000 loops, best of 3: 1.84 usec per loop
> rosuav at sikorsky:~$ python3 -m timeit -s 'from fp import Float'
> 'Float("1234.567")'
> 100000 loops, best of 3: 2.76 usec per loop
>
> Look! Creating a floating-point value is faster under Python 2 than
> Python 3. What could be more perfect?

> This is like a microbenchmark in that it doesn't tell you anything
> about real-world usage.

Microbenchmarks have their uses, when you are concentrating on a 
particular aspect of a language. But I tried your code, calling Float a 
million times, and 2.7 took 8.3 seconds; 3.4 took 10.5 seconds. But that 
is meaningless according to you.

(3.1 took 8.5 seconds. What happened between 3.1 and 3.4 to cause such a 
slow-down? Do you think it might be a good idea for /someone/ at least 
to take pay some attention to that, before it grinds to a halt 
completely by version 4.0?)

(I tried near-equivalent code on my byte-coded language. It took 0.7 
seconds. Then I tried a fairer test, as I use a bit of ASM to help the 
interpreter along: I created a C source version of the interpreter, 
compiled it with Tiny C, which generates some of the worst code around, 
and ran it again on the byte-code. It took 3 seconds; still faster than 
either of the Pythons!)

Anyway, is reading a jpeg not real world usage? It's a task normally 
done with a compiled language, but can also be a good test for an 
interpreted one.

> You write *real world* code and then profile that. You get actual real
> programs that you actually really use, and you run those through
> timing harnesses.

Sorry, but that is useless. It tells you that slow, interpreted 
languages can be viable with certain kinds of usage. Everyone knows that 
(I've been creating applications which balance compiled code and 
interpreted code since about the mid-80s).

If you want an interpreted language to take on wider range of tasks, 
then you need to make it faster, and that means measuring how efficient 
it is at executing algorithms itself, not measuring how long some 
library in a different language takes to execute.

> CPython 2.5 and 2.7 are very different. Even 2.7.0 and 2.7.11 are
> going to differ in performance. And that's without even looking at
> what core devs would refer to as "other Pythons", which would include
> IronPython, Jython, PyPy (well, you got that, but you're treating it
> as an afterthought), MicroPython, Brython, wpython, Nuitka,
> Cython..... these are *other Pythons*.

What are you suggesting here? That all these Pythons are going to be 
faster or slower than each other? I would guess that most of them are 
going to be roughly the same, other than PyPy. If there was a fast 
version, then I would have heard about it!

> the
> performance of array.array() is far from stable. It's not a core
> language feature; you're using it because it's the most obvious
> translation of your C algorithm,

I'm using it because this kind of file reading in Python is a mess. If I 
do a read, will I get a string, a byte sequence object, a byte-array, or 
array-array, or what?

Are you saying there array.array will not work on some implementations? 
In that case it's more of a mess than I thought!

> not because it's the best way to use
> Python. So I say again, your measurement has little to no significance
> to real-world code.

Real world use of Python appears to be as a scripting language and for 
glue code, with most of the real work done in libraries implemented in 
native code. I acknowledge that. And I understand that the 10-20% 
difference between Py2 and Py3 will largely disappear for these kinds of 
uses.

But I also said I am interested in using the languages to directly 
implement programs and algorithms not just for scripting. Then you need 
to be able to measure what the core language is capable of.


-- 
Bartc