AMD has open sourced more than 3,000 routines in its AMD Performance Library for multi-threaded programming.
These routines, which will make it easier to build media and other applications for multi-core processors, have been posted under the Apache license on SourceForge.net.
With more than 170,000 registered projects and almost 1.8 million registered users, SourceForge.net is the world’s largest open source software development Web site.
Ongoing Process
AMD engineers will continue contributing to the project, known as “Framewave version 1.0.”
“We’re going to add additional routines to the library, so it’s not like we’re going to just put it out there,” Margaret Lewis, AMD’s director of commercial solutions and software strategy, told LinuxInsider. “Getting the community to move to multi-threaded computing is a big challenge and we need to get everybody involved.”
Why multi-threaded computing? The answer lies in a combination of physics and money.
“You can only push the physics of silicon so far before running into thermal and other limits to increasing performance and power,” In-Stat analyst Ian Lao told LinuxInsider. Traditionally, speeding up single-core computers involved increasing the CPU’s clock speed, but this leads to higher demands for power and cooling. Moving to multi-core processors is the answer, because “each of these cores can run at slower clock speeds,” but overall performance is increased, Lewis said.
To maximize the performance of multi-core processors requires multi-threaded code.
“Going multi-core won’t automatically raise application performance,” Forrester analyst James Staten told LinuxInsider. “Single-threaded applications that are not multi-core-ready will not benefit much from the new generation of processors.”
Enterprises may have to redesign their applications to fully leverage multi-core boxes, Staten warned.
Spreading the Knowledge
Designing multi-thread applications is not going to be an easy task because “It’s a radically different model,” Lao warned.
So, silicon vendors like AMD and Intel (which went open source a year ago with its TBB project) are going open source to leverage the huge pool of open source developers and spread knowledge of how to write multi-threaded applications, Lao said.
“By opening this up, you not only get independent developers but also software engineers of the future at educational establishments to think about and develop multi-threaded, multi-core applications,” Lao added.
“This is a good move and a necessary one,” Forrester’s Staten said. “The more contributors there are to the open tools market, the faster the tools will mature. This is a welcome move that benefits the overall developer community.”
It’s in the interest of silicon vendors to work very closely with software developers, Lao said. “I see companies like AMD, Intel, and Via getting to the point where they have to open their software up to developers because they’re outstripping the capabilities of the software guys,” he added.
Intel’s TBB vs. Framewave
More than a year ago, Intel opened up a C++ runtime library to the community at large.
Known as TBB, or Threading Building Blocks, this uses common C++ templates and coding style, and abstracts the low-level threading details needed for optimal sub-core performance.
TBB is now on version 2.0.
Isn’t AMD late to the game after its perennial competitor?
“I didn’t know there was a contest,” Lewis said. “We’ve had this code available for three years and are choosing this particular time to move to open source because there’s many different things you need to do to move from proprietary to open source and we’ve been doing that.”
Framewave has been available in beta on SourceForge.net since December, Lewis pointed out.
TBB and Framewave are taking different routes to the same destination, Lewis said. “Intel’s stuff helps you write an application from the ground up, while ours provides highly optimized and threaded routines that developers can use in their applications to provide multi-threaded capabilities,” she added.
Programmers can customize and further optimize Framewave code for various platforms. “We have several operating environments that run with our processors — Linux, Windows, Solaris and VMware,” Lewis said.