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

[Chris Angelico]

On Thu, Mar 10, 2016 at 11:47 PM, BartC <bc at freeuk.com> wrote:
>> have no interest
>> in run time speed as they are fully aware that they'll be wasting their
>> precious development time, as they know that their code will be waiting
>> on the file, the database or the network.  What have you failed to grasp
>> about that?
>
>
> Tell that to the people who have been working on optimising compilers for
> the last couple of decades. Why bother making that inner loop 10% faster,
> when the program will most likely be blocked waiting for input anyway?
>
> You just don't get it.
>

Both of you "just don't get" something that the other sees as
critically important. Before this thread gets to fisticuffs, may I
please summarize the points that probably nobody will concede?

1) Unicode support, intrinsic to the language, is crucial, even if
BartC refuses to recognize this. Anything released beyond the confines
of his personal workspace will need full Unicode support, otherwise it
is a problem to the rest of the world, and should be destroyed with
fire. Thanks.

2) Interpreter performance, and the performance of code emitted by a
compiler (distinct from "compiler performance" which would be how
quickly it can compile code) makes a huge difference to real-world
applications, even if MarkL refuses to recognize this. While it
doesn't hurt the rest of the world to have a slow implementation of a
language, it does _benefit_ the world to have a _faster_
implementation, as long as that doesn't come at unnecessary costs.

3) There is a point at which performance ceases to matter for a given
application. This point varies from app to app, but generally is
reached when I/O wait time dwarfs CPU usage. A language which has
reached this point for the majority of applications can be said to be
"fast enough", not because its developers do not care about
performance (particularly regressions), and not because further
improvements are useless, but because there are other considerations
more important than pure run-time speed.

4) Burying the bulk of something away in external API calls is a great
way to make the real performance improve, but makes performance
*measurement* harder. This matters to benchmarking and to real-world
usage in different (almost, but not entirely, contradictory) ways.

When people want better performance out of a number-crunching Python
program, they have a few options. One is to rewrite their code in C or
Fortran or something. Another is to make small tweaks so the bulk of
the work is handled by numpy or Cython. A third is to keep their code
completely unchanged, but run it under PyPy instead of whatever they
were previously using (probably CPython). Generally, rewriting in
C/Fortran is generally a bad idea; you pay the price over the whole
application, when optimizing a small subset of it would give 99% of
the performance improvement. That's why actual CPython byte-code
interpretation performance isn't so critical; if we can change 5% of
the code so it uses numpy, we keep 95% of it in idiomatic Python,
while still having the bulk of the work done in Fortran. CPython has
other priorities than performance - not to say that "slow is fine",
but more that "slow and dynamic opens up possibilities that fast and
static precludes, so we're happy to pay the price for the features we
want".

ChrisA