blume at hana.uchicago.edu
Wed Jun 10 17:10:03 CEST 2009
"Jeff M." <massung at gmail.com> writes:
> On Jun 9, 9:08 pm, Arved Sandstrom <dces... at hotmail.com> wrote:
>> Jon Harrop wrote:
>> > Arved Sandstrom wrote:
>> >> Jon, I do concurrent programming all the time, as do most of my peers.
>> >> Way down on the list of why we do it is the reduction of latency.
>> > What is higher on the list?
> IMO, that response is a bit of a cop-out. Correctness is _always_ most
> important, no matter what application you are creating; without it,
> you don't have a job and the company you work for goes out of
> But, assuming that your program works and does what it's supposed to,
> I agree with Jon that performance needs to be right near the top of
> the list of concerns. Why? Performance isn't about looking good as a
> programmer, or having fun making a function run in 15 cycles instead
> of 24, or coming up with some neat bit packing scheme so that your app
> now only uses 20K instead of 200K. Performance is - pure and simple -
> about one thing only: money.
Programmer time is vastly more expensive than CPU time, so the
money argument often leads to slow ("low performance") solutions as long
as they are "good enough" because developing a faster solution would
mean spending more valuable programmer time at a cost that cannot
be recovered over the life cycle of the product in question.
That being said, there are plenty of situations where performance
obviously does matter a great deal -- as you correctly pointed out.
(It all depends on the above mentioned "product in question" and the
nature of its life cycle.)
More information about the Python-list