I was fortunate to have the opportunity to host a panel discussion on application development and multi-core at CommunityOne West this year. It was a fantastic opportunity to meet and work with software experts who are in the trenches and every day working on parallel programming solutions. The basic question here was: "How do I get started in taking advantage of multi-core processors?" To answer this question, everybody involved brought unique experiences and perspectives to the table. In the above link, you can see a view of AMD's roadmap - from our perspective, you should take away that from the desktop to the server, multi-core will be king.
Check out the AMD Developer Inside Track video for a snapshot of three of our partners from this panel and myself answering the question of how to start taking advantage of multi-core processors.
After these events I often get asked the same how-to-get-started question, but with more detail. Someone will say, "Okay, but let me tell you about this..." - so we talk it over. The questions I ask usually include at least some of the following:
- Who do you work for?
- What field are you in?
- What are you trying to do?
- Where is your code spending the most time now?
- What are your primary bottlenecks (CPU, I/O, Memory)?
- Do you need to scale up, or scale out?
- Are you trying to reduce response time?
- Are you trying to increase throughput?
- Where and how big is your data?
- What are your data dependencies?
- Are you using a managed runtime environment?
- What tools are you using?
- Are you open to using other tools?
- Will you be able to rewrite code?
- Who have you talked to in researching your problem?
- Do you have an n-tier infrastructure?
- What hardware are you using right now?
- What are your hardware upgrade plans?
These questions help decompose the problem and also provide a high-level view. I find these discussions often touch on a mix of abstract principles combined with some specific practical advice. Below, I have some basic getting-started suggestions which I've mapped to the above questions, along with my perspectives on how they bear on the problem. For simplicity's sake, I've decided to map a question once to a single suggestion, though it may really have multiple applications.
|
Suggestion
|
Relevant Questions
|
Perspectives
|
|
Identify your problem domain.
|
Who do you work for?
What field are you in?
|
Telecommunications, financial services, manufacturing, scientific programming & HPC, web services, database, ERP/CRM, BI: for these and many other segments there is typically an ecosystem of software tools for building products and solutions, in many cases with significant experience in parallelism.
|
|
Don't be afraid to ask for advice -- talk to your community of experts.
|
Who have you talked to in researching your problem?
|
Your community of experts can be found at conferences, in online forums, and at your tools vendors.
|
|
Clearly define your performance problem and the associated metrics.
|
What are you trying to do?
Do you need to scale up, or scale out?
Are you trying to reduce response time?
Are you trying to increase throughput?
|
This is critical in explaining the problem to yourself and others. This should be an easy to understand and simple statement that includes a baseline.
|
|
Analyze and identify primary bottlenecks.
|
Where is your code spending the most time now?
What are your primary bottlenecks (CPU, I/O, Memory)?
Where and how big is your data?
What are your data dependencies?
Do you have an n-tier infrastructure?
|
If you don't know the answers to these questions then you need to do some analysis. Diagram your infrastructure. Use performance analysis tools found in your OS and from your tools vendors. There are usually a few places in your code where most of the time is spent.
Like any optimization effort, you'll analyze first, re-measure, and re-analyze throughout your parallelization effort.
|
|
Review alternate algorithms.
|
Will you be able to rewrite code?
|
After some initial analysis you should take a high-level look at your overall algorithm. It may not be the best choice. It also may place constraints on how easily you can parallelize.
|
|
Review current tools and look for acceptable alternates.
|
Are you using a managed runtime environment? What tools are you using?
Are you open to using other tools?
Will you be able to rewrite code?
|
This is often closely related to the problem domain and associated business requirements. Maybe you can take a new Fortran compiler that supports parallelization with OpenMP, or maybe you need to focus on a new math library.
|
|
Review current hardware and evaluate new hardware.
|
What hardware are you using right now?
What are your hardware upgrade plans?
|
Along with looking at the architectural and tools aspects of your software, think about how much you could improve your basic situation with new hardware, be it one of more RAM, more or faster CPUs, or bigger or faster disks.
|
In conclusion, I want to emphasize that after carefully stating your problem and doing some initial analysis, that you try new implementations with caution. Measure with appropriate precision, and make sure your measurements are repeatable. Only then can you be sure that your work is worthwhile. Finally, take a look at the AMD Developer Central for parallelization articles, our CPU analysis tool CodeAnalyst, and our performance libraries.
Be sure to check out the first AMD Developer Inside Track video featuring three of AMD's software tools partners giving their perspectives on taking advantage of multi-cores.
-Tracy Carver, Software Developer and Evangelist, AMD
-------------------------
The information presented in this document is for informational purposes only and may contain technical inaccuracies, omissions and typographical errors. Links to third party sites are for convenience only, and no endorsement is implied.
Edited: 08/18/2009 at 01:05 PM by devcentral
