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

[BartC]

On 08/03/2016 00:05, Ben Finney wrote:
> BartC <bc at freeuk.com> writes:
>
>> On 07/03/2016 20:47, Chris Angelico wrote:
>>> 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.
>
> The “micro” is not referring to the focus of the operation; that's a
> good thing to do and is a way to produce useful, salient results. Choose
> a specific aspect and design a test case which focusses as narrowly as
> possible on that aspect. Then you can gather data to make meaningful
> statements about that aspect in isolation from others.
>
> What is “micro” about the benchmark you showed is that it doesn't gather
> enough data to be useful. The test should not just do one statement; it
> should do some relevant complete unit of the algorithm. Focussed, but
> interesting: a huge amount of data, or a complex data conversion, or
> something else that qualifies as “real”.

What's the purpose of the measurement? In my case, I'm not just 
measuring, but also implementing: either developing a program (the 
decoder for example) and trying to get it fast, and/or using it to tweak 
some interpreter or other I'm working on. Then I might well want to 
focus on particular single byte-code or some narrow aspect of the program.

>> 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.
>
> Try testing on a large battery of highly varied JPEG images, and getting
> the aggregate results from that. Or something that is more interesting
> (i.e. relevant to the real usage) than one image.

If your efforts manage to double the speed of reading file A, then 
probably the reading file B is also going to be improved! In practice 
you use a variety of files, but one at a time will do.

>> If there was a fast version, then I would have heard about it!
>
> The mistake, I think, is in assuming a “fast version” means anything.

Yes of course it does. As does 'being slow'. Take another microbenchmark:

def whiletest():
|   i=0
|   while i<=100000000:
|   |   i+=1

whiletest()

Python 2.7:  8.4 seconds
Python 3.1: 12.5 seconds
Python 3.4: 18.0 seconds

Even if you don't care about speed, you must admit that there appears to 
be something peculiar going on here: why would 3.4 take more than twice 
as long as 2.7? What do they keep doing to 3.x to cripple it on each new 
version?

(For comparison, my interpreter managed 0.4s, PyPy 0.3s (it's hot on 
loops) and part-optimised C might be 0.07s (fully-optimised would be 0s).)

So you might say that a 'fast' version wouldn't give silly timings like 
the above.

Trying something like the silly loop above on a new language can be 
quite revealing.

-- 
Bartc