433.aspx

What happened to the 10 GHz CPU?

Herb Sutter has an interesting article on hitting the speed limit of CPUs that will be published in Dr. Dobb's Journal. Moore's Law applies to the number of transistors on a CPU and continues to be valid (at least for some more time) but we're stuck at 4GHz for a while to come.

Our work just keeps getting more interesting! CPU's will continue to get more powerful as they will add more concurrency capabilities, but sluggish programs will have to be rewritten to take benefit of the hyper threading and multicore CPUs. Adding more threads isn't a free lunch though. As Herb Sutter points out, concurrency has its costs:

• it's hard to write multi threaded programs. It is very easy to introduce deadlocks or forget to protect variables so you corrupt data under stress. If you always lock everything, you end up with close to single threaded performance. Choosing when, and what, to lock, is a skill acquired with experience (as is good OOP).
  
• some applications are difficult to make multi threaded
  
• synchronization etc. has its costs

I currently work on the server side (web and infrastructure services), so I'm lucky as I have designed the applications to be multi threaded from the start. Making a server multi threaded is easier, conceptually, than a client application. It's easy to imagine a group of threads managing requests for many clients. It takes a mental shift for most developer to optimize client applications by splitting time consuming tasks, like sorting large lists, among multiple threads. Most developers still have to face the basic concurrency issue in .NET in GUI applications and have a long way before they master concurrency.

I am not worried about server side scaling (yet), as there are plenty of options:

• Scale out with Windows Load Balancing. This can be used by many applications, not only traditional web applications. Works very well for stateless applications
  
• Scale out with Data Partitioning/request routing. Depending on the data the request is routed different set of servers.
  
• Scale up by adding more CPUs
  
• Asynchronous programming: queue whatever can be queued and execute it later

I particularly agree with this statement:

Efficiency and performance optimization will get more, not less, important

Another thing to keep in mind for those of us with "The holy title of software architect" :-)

Via [Larry Osterman's WebBlog]