The Economy versus Multicore (or, How Long Can Developers Avoid Multicore?)(cilk.com)
cilk.com
The Economy versus Multicore (or, How Long Can Developers Avoid Multicore?)
http://www.cilk.com/multicore-blog/bid/8348/The-Economy-versus-Multicore
http://www.cilk.com/multicore-blog/bid/8348/The-Economy-versus-Multicore
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.