The concept of co-design is based on the belief that the quality of design will improve if all the stakeholders’ interests are taken into consideration as part of the design process.Industry thought leaders have been saying for several years now that “co-design” is a key enabler – a critical component that will drive our ability to actually build a useable exascale system.
But the very topic of co-design naturally takes us down the path of different opinions and perspectives as groups with different interests start to collaborate.
This is not new. Co-design is a popular and accepted approach in mobile phone development where the perspectives of hardware and software design have been brought into the co-design process for several years. And co-design theory has been taught for many years and is actually a development of “systems thinking” an approach well understood by many scientists and the subject of dozens of textbooks.
The best way to describe systems thinking – and the approach of co-design – was, in my opinion, best stated by Charles West Churchman, a former UC Berkeley Professor who stated that the process “begins when first you view the world through the eyes of another.” Sounds like a great lesson for any relationship.
In collaborative hardware software co-design, the designers are challenged to consider trade-offs in the way the hardware and software components of a system will work together to exhibit a specified behavior, given a set of performance goals and technology.
But, in a highly competitive market segment such as HPC, where huge financial investments are required up front just to start the exploration of alternative technology direction, organizations are going to be understandably reluctant to throw proprietary intellectual property into the collaborative co-design bucket.
So, in all likelihood – there’s always something being held back – as each of these commercial organizations eventually wants to have a leg up on its competitors.
In theory – co-design makes a lot of sense. In reality – it’s very difficult to have effective co-design activity among organizations whose growth and survival requires them to compete with each other for funding and revenue.
Not Everyone Plays Nice in the Sandbox
The promise of co-design is the pot of gold at the end of the rainbow – hardware design that understands every aspect of the software, and an architecture that takes full advantage of the hardware and enables highly efficient applications. HPC utopia.
HPC has always struggled with hardware and software imbalance. Co-design, in theory, could provide the balance necessary to achieve unparalleled performance and efficiency gains in petascale and exascale systems.
Co-design has many believers and champions. And why not? Who wouldn’t want utopia? But there are just as many who feel the dream of co-design, as it applies to exascale R&D, is a hopeless quest.
The primary misconception around co-design is the premise that competing companies, research organizations and even governments have any incentive to collaborate. No one company can take this on – and no one government agency is able to fund the massive effort and development costs we face in achieving exaFLOPS. For exascale to be a practical reality, the hardware design must take into consideration the architecture and the architecture and system software must take full advantage of and push the hardware to its limits. Codes must somehow be developed or adapted to manage billion-way parallelism. But companies and organizations must compete to survive – and intellectual property is money in the bank. Commercial organizations are willing to cooperate, collaborate and contribute to co-design only so far. Eventually, they will pull back – or hold back the designs and information that they feel could give them a competitive edge.
Another misconception is that co-design for exascale is well underway. There have been many meetings and even announcements of co-design centers collaborating with research labs. But very little has actually been done beyond the early discussions and political posturing. The commitment to exascale, in general, is consistent around the globe. The commitment to the necessary funding is another story. Yes, there have been some interesting developments around reducing overhead, improving parallelism and hiding the latency, but progress is being made only in a handful of places where strong industry leaders have simply taken the bull by the horns to get things done. Long-term, solidly funded, well organized, coordinated and managed programs to deliver results are struggling to get proper funding. This is particularly true in the U.S.
And finally, there is the misconception that a technology and product roadmap exists that will get us to exascale. Think about it. Reducing power per op by a factor of 100 – at least. Has anyone seen the roadmap that gets us to that point? Stating it as a goal – and saying that we know we need to get there – is not a roadmap. The bottom line is no one has a clue as to how we can possibly deliver an exascale machine that will only consume 20MW of power. To this point, Intel’s declaration of exascale leadership, covered in this issue, has become a credibility issue for the company.
Who Do We Believe?
The topic of co-design is becoming as mutated as the old discussions of grid computing, and in some cases, as confusing as discussions of cloud. People use co-design as a convenient synonym for collaboration. And co-design is not restricted to exascale discussions. Co-design can have huge implications for petascale applications. But co-design requires change. Change for the vendors and change for the users, and it can’t be driven from the vendor’s perspective of a future product roadmap.
As an example, the industry is still at odds over heterogeneous computing environments, and the discussions of commodity vs. proprietary solutions are as colorful and heated as ever. ISC brought the flames to a new height.
Dr. David Kirk, NVIDIA Fellow, stated this opinion, “The biggest challenges are software (both applications and tools) and power and x86+AVX (or any SIMD extension) loses on both. Decoding x86 instructions burns power for no gain and SIMD extensions make programming unnecessarily difficult. Exascale itself is not really hard. Exascale at 20MW is really hard.”
Intel disagrees of course and believes they have the magic formula with their MIC (Many Integrated Core) architecture and they’ve tied their exascale plans to the fact that they started shipping their Knights Ferry development kits to a handful of organizations. They have referred to this early development phase as co-design. Not surprisingly, they lose a few credibility points for this categorization.
Based on our first-hand experience, and many interviews conducted at ISC’11, we believe this topic is interesting and controversial enough that we have included a special feature piece written around the community’s reaction to Intel’s declaration of exascale leadership presented at ISC’11.
For related stories, visit The Exascale Report Archives.
Comments