xTCA & CompactPCI Systems May 2011 : Page 10

S OFTWARE C ORNER By C URT S CHWADERER Managing the transition to multicore: Part I The movement to multicore is upon us. Multicore processors, with multiple CPU cores on a single chip, promise dramatic performance increases as well as shrink-ing form factors. You can use the cores to increase the compute power for multi-threaded applications, or partition them to different functions running different operating systems. Adopting new innovations into your prod-uct line can be a double-edged sword. Multicore processors enable signiﬁcant performance and scalability increases. On the other hand, blindly forging ahead with a product software move might sig-niﬁcantly delay development for no real advantage unless the engineering team understands the issues and pitfalls of software parallelism and development for multicore platforms. Having struggled with this in the past, I did some research and came across CriticalBlue, a company whose roots are in tools that allow companies to develop customized coprocessor hardware. The tools are intended to make the job of migrating legacy code easier. I caught up with David Stewart, CEO of CriticalBlue, and talked with him about his experi-ence with multicore applications. We discussed the software CriticalBlue has developed that allows companies to map “migrating to multicore” plans. Planned approach pays off in time and cost cuts Founded in 2003, CriticalBlue intro-duced a synthesis tool called Cascade as its ﬁrst product. Cascade is an automated coprocessor synthesis tool targeted at companies doing custom coprocessor 10 development. Companies use the tool to create a programmable coprocessor unit and model how their legacy software will run with the coprocessor. CriticalBlue has developed core compe-tency in matching software to underlying silicon architectures and helping peo-ple migrate legacy software by using a “planned approach.” Following a planned approach, developers: 1. Construct the coprocessor simulation. 2. Run the legacy code in this new environment. 3. Analyze the new performance results. 4. Adjust the software and coprocessor accordingly to get the desired results. Contrast these four steps with a process that calls for a “develop the coproces-sor, make the software changes, then run them together and see if you got what you expected” approach, and you can see the opportunity for substantial time and expense savings. Cascade allows coprocessor developers to analyze the instruction-level parallelism in the application. Once this parallelism is well understood, you can build a coproces-sor that fully exploits that parallelism. Cascade takes care of communication between the processor and coprocessor and makes it as invisible as possible to the software development. David said that many of the Cascade users would use it to successfully build their coprocessor and report signiﬁcant improvement in overall performance, but then mention that the main processor David Stewart CEO, CriticalBlue | May 2011 | CompactPCI, AdvancedTCA & MicroTCA Systems

Software Corner

Curt Schwaderer

Managing the transition to multicore: Part I The movement to multicore is upon us. Multicore processors, with multiple CPU cores on a single chip, promise dramatic performance increases as well as shrinking form factors. You can use the cores to increase the compute power for multithreaded applications, or partition them to different functions running different operating systems. Adopting new innovations into your product line can be a double-edged sword. Multicore processors enable significant performance and scalability increases. On the other hand, blindly forging ahead with a product software move might significantly delay development for no real advantage unless the engineering team understands the issues and pitfalls of software parallelism and development for multicore platforms. Having struggled with this in the past, I did some research and came across CriticalBlue, a company whose roots are in tools that allow companies to develop customized coprocessor hardware. The tools are intended to make the job of migrating legacy code easier. I caught up with David Stewart, CEO of CriticalBlue, and talked with him about his experience with multicore applications. We discussed the software CriticalBlue has developed that allows companies to map “migrating to multicore” plans. Planned approach pays off in time and cost cuts Founded in 2003, CriticalBlue introduced a synthesis tool called Cascade as its first product. Cascade is an automated coprocessor synthesis tool targeted at companies doing custom coprocessor Development. Companies use the tool to create a programmable coprocessor unit and model how their legacy software will run with the coprocessor. CriticalBlue has developed core competency in matching software to underlying silicon architectures and helping people migrate legacy software by using a “planned approach.” Following a planned approach, developers: 1. Construct the coprocessor simulation. 2. Run the legacy code in this new environment. 3. Analyze the new performance results. 4. Adjust the software and coprocessor accordingly to get the desired results. Contrast these four steps with a process that calls for a “develop the coprocessor, make the software changes, then run them together and see if you got what you expected” approach, and you can see the opportunity for substantial time and expense savings. Cascade allows coprocessor developers to analyze the instruction-level parallelism In the application. Once this parallelism is well understood, you can build a coprocessor that fully exploits that parallelism. Cascade takes care of communication between the processor and coprocessor and makes it as invisible as possible to the software development. David said that many of the Cascade users would use it to successfully build their coprocessor and report significant improvement in overall performance, but then mention that the main processor And coprocessor were not executing at the same time. The CPU software simply fed the data to the coprocessor, which can do the job much faster. This process results in some gain but not as much as might have been expected, and the need to increase performance further led to the need to run in parallel. Once relationships between tasks, datafl ow through the application, data dependencies, critical sections, and the like are identifi ed, the code could be updated (or re-factored) to enable it to run in parallel. The next version of Cascade added a front end that performs analysis of the code and identifi es data dependencies and areas where the code could be parallelized between the CPU and the coprocessor. Sound familiar? For those of us moving to multicore, does the previous section sound eerily familiar? As I listened to David talk about Cascade, it called to mind the very similar issues and challenges of my development experiences with multicore. David and others at CriticalBlue also saw these parallels and a match with the company’s core competencies when it came to multicore development challenges. That prompted them take the leap from Cascade and coprocessor synthesis to Prism, a software analysis and planning tool. Prism is an instrument that enables development teams to plan and migrate to multicore platforms while achieving the Expected results. CriticalBlue launched Prism in 2009. David mentioned that CriticalBlue leveraged its historical customer base in order to gather product requirements. Five overwhelming requirements came to the fore. First, developers want to stick with known, standard, familiar development languages. Second, they want to be able to integrate the new system into their Integrated Development Environments (IDEs). Third, developers want to maintain their standard development fl ows. Fourth, CriticalBlue heard in no uncertain terms that developers do not want the tool to touch or manipulate their code in any way, such as by synthesizing code or parallelizing code automatically. Fifth, developers see tremendous value, however, in an analysis tool that educates them about what’s going on in the code – one that identifi es data dependencies, code structure, execution fl ows, and critical sections. Once these things are isolated, the developer can go back to their code within their IDE and make the changes. Overall, developers want to be guided through the process but don’t want the tool to do it for them. They need to understand the changes being made in order to effi ciently maintain and advance the code base being updated for multicore. Multicore decision is the fi rst step David made a really interesting point about where Prism falls within the planning and development process. “Most companies fall into a trap where they fi rst make the decision to use multicore, perhaps even making the specifi c processor decision,” he said. He added, “then they use Prism to help them along that path. This is fi ne of course, but developers get the most out of Prism when they use it to help make the multicore decision.” He advised “your fi rst step should be to do some multicore performance analysis on your existing code, fi nd out what kind of performance increases can be expected, and learn how much time making code changes will take. This process provides guidance about what multicore processor would be a good fi t for the application.” It’s possible that once the analysis is done, developers may fi nd that going to multicore doesn’t make sense because the algorithms are simply too sequential in nature. Or during the research phase, you might fi nd unexpected dependencies in the code that will require more time than you thought to make code changes. Maybe future product capabilities will require updates so that the transition to multicore makes more sense. All this adds up to the ability to make good decisions about how and when to transition without disrupting development schedules while minimizing risk. David summed it up well, “Do an orderly transition (to multicore) at a time it suits you. You won’t want to wait until the emergency situation happens, then have to do something. Be ahead of the game, so you can plan. Build a migration methodology. Educate the development teams. The companies following these steps are the ones that we see being the most successful with multicore.” Stay tuned for Part II A look at the timely (and also complex) topic of multicore continues in the next Software Corner. In Part II I will walk through the steps to using Prism and relay my experiences doing so. Until then, here’s wishing you a graceful migration to multicore! For more information, contact Curt at cschwaderer@opensystemsmedia.com.

Previous Page Next Page

Publication List
Using a screen reader? Click Here