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

Mark Lawrence breamoreboy at yahoo.co.uk
Thu Mar 10 07:15:13 EST 2016


On 10/03/2016 11:50, BartC wrote:
> On 10/03/2016 07:30, Mark Lawrence wrote:
>> On 10/03/2016 00:58, BartC wrote:
>
>>> You think a bloody great compiler is a microbenchmark?!
>>
>> I have no interest in the speed of the compiler, I am interested in the
>> run time speed of the applications that it produces which is what has
>> been discussed thus far.
>
> Perhaps you missed the fact that this compiler is written in the very
> language it compiles. The code generated /is/ the application. And
> compilers are real applications that people use all the time.
>
>>>>> A compiler is another good 'pure language' task because, apart from
>>>>> input and output at each end, all the computation is self-contained.)
>>>>
>>>> I've no idea what this is meant to mean.
>>>
>>> It means the task doesn't do any function calls to external libraries.
>>
>> Meaning that in this dreadful place called the real world it's less than
>> useless in many cases.
>
> Suppose you were on the development team that writes the optimising
> stages of a C compiler. You need to test the performance of the code it
> produces so that you can compare one optimisation with another. Would you:
>
> (a) Test only the code that is generated by your compiler
>
> (b) Include also the runtime of third-party libraries consisting of
> unknown code, written in an unknown language, with an unknown compiler
> and with unknown optimisation settings?

What has an optimising C compiler got to do with the run time speed of 
Python, which in many cases is perfectly adequate? I'll repeat for 
possibly the fourth time, the vast majority of people 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?

>
> You seem to be suggesting that (b) is a valid way of measuring the
> performance of a language.
>
>> Yes I am, as you appear to know squat.
>
> I don't think I've ever traded insults on usenet or any public forum.
> I'm too nice a chap. But today it's rather tempting!
>
>>> But, yeah, I was writing international applications decades ago. I'm not
>>> working for anyone now and don't need to bother.
>>
>> So your new language doesn't bother with unicode then?
>
> Yes, it has provision for it. But I've not got round to implementing it.
> Other things have more priority. Or are more interesting. As I said,
> I've had all that fun before.
>
> If I desperately needed to use Unicode today, then something can be
> arranged either with the language or around it. It's not a big deal.
>

Laughable.  It's 2016, but "then something can be arranged either with 
the language or around it".  It's not what you personally want, it's 
what the entire world wants.  If you think that your language is going 
to take over the world without unicode support, just because it's faster 
than Python, I seriously suggest that you see a trick cyclist, and 
rather quickly.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence




More information about the Python-list mailing list