The Software Architecture Impact of the Multi-Core Processor Trend

Posted by Mark Figley on Sep 25, 2007

Sections

Development,

Architecture & Design

Topics

Java ,

Architecture ,

Performance & Scalability

Tags

Threading ,

Parallel Programming

The Java Developer's Journal has a great article about how software developers are going to be impacted by the industry trend towards multi-core and massively parallel processors. From the article:

As software developers we have enjoyed a long trend of consistent performance improvement from processor technology. In fact, for the last 20 years processor performance has consistently doubled about every two years or so. What would happen in a world where these performance improvements suddenly slowed dramatically or even stopped? Could we continue to build bigger and heavier, feature-rich software? ... The truth is, single threaded performance improvement is likely to see a significant slowdown over the next one to three years. In some cases, single-thread performance may even drop. The long and sustained climb will slow dramatically.

The name of the source magazine notwithstanding, the article is an interesting read even if you aren't a Java shop. As you might guess, the authors don't just leave you with that despairing thought above. The article goes on to explain how we will need to adjust the architecture of our software to continue sustained growth:

... the industry is looking to multi-core and multithreaded processor designs to continue the performance improvement trend. These designs don't look to improve the performance of single threads of execution, but instead to run many and sometimes massive numbers of threads in parallel. ... As a developer, it will be important for you to learn the skills necessary to develop applications that can run with high performance on these increasingly parallel processors. Since single-thread performance isn't likely to improve at historical rates, the developer will have to look to concurrency to improve performance for a given task.

The rest of the article provides an introductory-level overview to strategies for parallel programming, starting with Amdahl's Law:

As you get started with parallel programming, the first rule to become familiar with is Amdahl's Law. Amdahl's Law says that speeding up your program is limited by the part that's not running in parallel. For example, if a profile reveals that 20% of the time is spent in code that can only run sequentially on one processor, then the best speed increase you can possibly get, even with perfect parallelization of the rest of your program is 5x, no matter how many processors you throw at it. Load imbalance is a similar problem. If you've divided your code into N subtasks, the time taken to execute them is not 1/N. Rather the time taken is the maximum of the execution times of the subtasks.

And then flows into concurrency issues and Thread programming, focusing on the Java language constructs for parallel programming. The article wraps up by announcing a new language developed by IBM called X10 which adds higher-level constructs to the Java language specifically for parallel application development. It seeks to simplifiy concurrent programming by providing simplified semantics for managing both concurrent operations and the distribution of data associated with those operations.

X10 can't really be considered an internal DSL because its syntax is not valid Java syntax. It is closer to AspectJ (pre version 5) in that it uses the Java language as a basis and then builds a new, distinct language from there.

1. Back to top

   it's nothing to do with java programmers

   by ding jack

   Java programmers work on JVM.
   Do you mean the Java Virtual Machine has multi-core now?
   multi-core or multi-cpu or multi-host will be abstracted by cluster or something.

   Reply

2. Back to top

   I/O will makeup the difference

   by Bill Burke

   I think I/O performance will make up the difference we aren't getting with raw single threaded performance. The solid state drives that are coming out look promising and will only get better.

   Reply

3. Back to top

   Only matters to systems developers...

   by Raffi B

   Being someone who have developed business-oriented applications for large corporations for the past 9 years, I can tell you that I had very rarely little exposure with parallel processing simply because the majority of the business applications built today run on middleware platforms, such as app servers and messaging MOM's, which manage threads and concurrent processing internally. As a business apps developer, it makes practical sense to remove yourself from implementing non-functional requirements that fall into the realm of performance and throughput. Developers that implement middleware need to be more concerned about this stuff.

   Reply

4. Back to top

   Re: Only matters to systems developers...

   by Rickard Öberg

   Yes, that would be the ideal situation. Considering the trend towards symmetric yet partitioned systems (where each node can do everything, but not all data is hosted everywhere), I think development frameworks should adjust to this reality.
   
   Fortunately there are domain constructs that could help us here, since the notion of Entity Aggregates provide a good abstraction for what set of objects should be handled as one unit. But frameworks needs to take advantage of this in order to really make good use of it.

   Reply

5. Back to top

   it's nothing to do with java programmers?

   by Luis Garcia

   Of course its about Java programmers. Regardless of the JVM's ability to "make benefit for glorious multi-core processor", you as the programmer need to understand how to best take advantage of multi-core processing in your application. After all its the sub-system that doles out processing, not the JVM.

   Reply

• Older >