multi-core software

[Matthias Blume]

"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?
>>
>> Correctness.
>>
>
> 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
> business.
>
> 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.)

Matthias