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

[BartC]

On 10/03/2016 13:08, Chris Angelico wrote:
> On Thu, Mar 10, 2016 at 11:47 PM, BartC <bc at freeuk.com> wrote:

>> 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.

I don't agree. If I distribute some text in the form of a series of 
ASCII byte values (eg. classic TXT format, with either kind of line 
separator), then that same data can be directly interpreted as UTF-8.

(And as you know, the first 128 Unicode code points correspond with the 
128 ASCII codes. Widening such a data-set so that each 8-bit character 
becomes 32-bit will also give you a set of Unicode code-points.)

Importing a text file from elsewhere is a different problem of course. 
Although out of the thousands of times I must have done this, 
Unicode-related issues have been minimal.

> 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.

Also when the total runtime is negligible anyway. It doesn't matter if a 
program takes 200msec instead of 20msec. (Unless millions of such tasks 
are scheduled.)

> 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".

Generally agree. But also, I often develop an algorithm using a dynamic 
language, because it's much easier and quicker to try out different 
things, before porting the result to a static language.

But during development, it doesn't hurt if the dynamic version isn't 
quite so slow!

-- 
Bartc