

The Economy versus Multicore (or, How Long Can Developers Avoid Multicore?) - threadman
http://www.cilk.com/multicore-blog/bid/8348/The-Economy-versus-Multicore

======
ShabbyDoo
I voted this article up to bash it.

One quote:

[With "multicore",] a credit card company can run a sophisticated credit
scoring model on millions of accounts, or a financial services firm can
rebalance a larger volume of client portfolios overnight."

Ummm...who isn't doing these things in a multi-threaded/multi-process way
today? Those using COBOL on a mainframe who have bigger problems? Almost
anyone running a web server and processing requests is already able to take
advantage of a 16 processor system. Databases are already good at running on
these boxes, but faster IO and more memory are probably better ways to achieve
marginal improvement in the DB space today (said as no expert).

I understand the use cases for (1) really big simulations that are written in
a single-threaded way and (2) desktop apps. I'm not an expert in either of
these, so I can't comment.

What I find idiotic is the presumption that a large percentage of server
processes can't run well as-is on multi-core boxes. I'm a Java guy
(pragmatically, not by religion), and anyone running on a J2EE server w/o some
single-threaded homespun thingy can probably scale up reasonably given more
cores presuming that they can already scale horizontally. Yes, there are
exceptions -- mostly with poorly-designed in-house software, but it's the two
cases listed above where the most work likely exists.

