multi-core software

[Arved Sandstrom]

In other words, without concurrency the latency would be so high that you
would consider the program to be wrong. However you cut it, the real reason
is latency.

For a certain group of applications and user loads I would concede that
point, yes.

For quite a few other situations, you could queue up user requests and
execute them in order, finishing each before proceeding to the next, and
users wouldn't even notice. I wrote a J2SE server a few months ago, to
solve a very specific problem associated with an application running on
a J2EE server, that could handle dozens of users per second using this
strategy. It didn't write it that way because doing so is perverse, but
I could have.

AHS

 

[Arved Sandstrom]

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