multi-core software

[Arved Sandstrom]

Jeff M. wrote:
> 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.
> 
> Programs that use more memory require more money for the hardware of
> every user. Programs that run slower eat more time per day. If you
> have 100,000 users, all doing an operation once per day that takes 20
> seconds, being able to shave 5 seconds off that saves 5.78 man-days of
> work. Hell, for some applications, that 20 seconds is just startup
> time spent at a splash screen. Just imagine if every Google search
> took even 5 seconds to resolve, how much time would be wasted every
> day around the world - ignoring the fact that Google wouldn't exist if
> that were the case ;-). Obviously Google engineers work incredibly
> hard every day to ensure correct results, but performance better be
> right up there at the top of the list as well.
> 
> Jeff M.

Point taken, but I primarily work on internal government and corporate 
applications. Might be hundreds or thousands of users at any given time, 
but not typically tens or hundreds of thousands. Hundreds or thousands 
of users translates to at least an order of magnitude less 
"simultaneous" users. Ops people that I talk to who monitor apps I've 
worked on, or similar apps, rarely report any such where the application 
itself is presenting a sluggish aspect to users because it's stressing 
out processors, or consuming gargantuan memory.

Typically when latency problems come up, it's because the app has to 
talk to other servers - databases, LDAP, print servers etc. In other 
words, the network is coming into play. In fact when we do work on 
performance, it's typically about minimizing calls to the database or 
other services.

AHS