Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Mark Lawrence <breamoreboy@yahoo.co.uk>
Newsgroups: comp.lang.python
Subject: Re: Pyhon 2.x or 3.x, which is faster?
Date: Thu, 10 Mar 2016 13:18:15 +0000
Lines: 59
Message-ID: <mailman.128.1457615949.15725.python-list@python.org>
References: <mailman.238.1457265255.20602.python-list@python.org> <nbknir$avu$1@dont-email.me> <mailman.49.1457383632.10335.python-list@python.org> <nbkvq2$j5s$1@dont-email.me> <mailman.7.1457395587.15725.python-list@python.org> <nbl81v$hii$1@dont-email.me> <mailman.16.1457399576.15725.python-list@python.org> <nblapf$ofi$1@dont-email.me> <mailman.28.1457405184.15725.python-list@python.org> <nbmbnp$hsi$1@dont-email.me> <mailman.45.1457453433.15725.python-list@python.org> <nbn871$8np$1@dont-email.me> <56df6761$0$1588$c3e8da3$5496439d@news.astraweb.com> <mailman.72.1457512871.15725.python-list@python.org> <nbp36e$560$1@dont-email.me> <mailman.96.1457558042.15725.python-list@python.org> <nbqaja$5g5$1@dont-email.me> <mailman.98.1457566570.15725.python-list@python.org> <nbqgmi$mha$1@dont-email.me> <mailman.108.1457595070.15725.python-list@python.org> <nbrms1$26p$1@dont-email.me> <mailman.123.1457612163.15725.python-list@python.org> <nbrq7b$eeu$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
In-Reply-To: <nbrq7b$eeu$1@dont-email.me>
Precedence: list
Xref: csiph.com comp.lang.python:104513

On 10/03/2016 12:47, BartC wrote:
> On 10/03/2016 12:15, Mark Lawrence wrote:
>> On 10/03/2016 11:50, BartC wrote:
>
>>> 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
>
> The vast majority aren't implementing the language!

No, they are complete weirdos called USERS.  Have you ever met any?

>
>> 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.

At last you manage to get something correct, I do not get your obsession 
with run time speed.  For the fifth time, the vast majority of users 
simply do not care.  If it is fast enough, job done.

I have dealt with some complete dumbos in the years that I've been 
online, but when it comes to thickos you're right up there with the RUE, 
and I can assure you that this is meant to be an insult.

To your way of thinking run time speed is the sole issue with 
programming, and trivial details like accuracy are irrelevant. "Look, 
Python has taken a whole minute to process this data, but BartC has done 
it in one nanosecond". "Yes, but Python is 100% accurate, BartC is 100% 
inaccurate". "Who cares, only speed counts".

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence