This paper introduces three component technology initiatives within the SciDAC Center for Technology for Advanced Scientific Component Software (TASCS) that address ever-increasing productivity challenges in creating, managing, and applying simulation software to scientific discovery. By leveraging the Common Component Architecture (CCA), a new component standard for high-performance scientific computing, these initiatives tackle difficulties at different but related levels in the development of component-based scientific software: (1) deploying applications on massively parallel and heterogeneous architectures, (2) investigating new approaches to the runtime enforcement of behavioral semantics, and (3) developing tools to facilitate dynamic composition, substitution, and reconfiguration of component implementations and parameters, so that application scientists can explore tradeoffs among factors such as accuracy, reliability, and performance.
The increasing complexity of software systems for computational science and engineering has led to the adoption of a now-common methodology from business and industrial computing: software components. A component in this context is an independently deploy-able unit of software, which can be composed together with other components to form a complete program for solving some class of problems [63]. Components must have well-defined interfaces to allow this composition, but the implementation within the component is not specified. This situation implies programming language independence and, as long as the interfaces do not change, the ability to substitute updated or superior implementations. Other desirable features include scalability of the number of interacting components, scalable parallelism both within and between components, and minimality. In this context, minimality means that the requirements for a unit of software to function as a component are as lightweight and as few as possible.Components are typically regarded as peers, so that no component necessarily must be the driver or main component. All component systems provide some level of encapsulation, the idea from object-oriented programming that limits all interactions with the component to defined interfaces. Those interfaces are called ports, and often a formal interface definition language (IDL) is used to define ports. Because all interactions are through the ports, defining them completely specifies the component's requirements. Conventional libraries may cause programs linking with them to fail when upgraded to a new version, but components implementing the same interface are interchangeable (although they may differ in performance or resource usage, such as memory).The setting in which components are connected is called a framework, which is responsible for instantiating, running, connecting, and stopping components—in general, the full life cycle.
The Common Component Architecture (CCA) is a component model for high-performance computing, developed by a grass-roots effort of computational scientists. Although the CCA is usable with CORBA-like distributed-object components, its main purpose is to set forth a component model for high-performance, parallel computing. Traditional component models are not well suited for performance and massive parallelism. We outline the design pattern for the CCA component model, discuss our strategy for language interoperability, describe the development tools we provide, and walk through an illustrative example using these tools. Performance and scalability, which are distinguishing features of CCA components, affect choices throughout design and implementation. Copyright © 2005 John Wiley & Sons, Ltd.
Component-based design can help manage the complexity of high-performance scientific simulations, where it has become increasingly clear that no single research group can effectively develop, select, or tune all of the components in a given application and that no single tool, solver, or solution strategy can seamlessly span the entire spectrum efficiently. Component approaches augment the benefits of object-oriented design with programming lan- guage interoperability, common interfaces, and dynamic composability. Our work addresses the challenge of how to compose, substitute, and reconfigure components dynamically during the execution of a scientific application. The goal is to make suitable compromises among performance, accuracy, mathematical consistency, and reliability when choosing among available component implementations and parameters. As motivated by high-performance simulations in combustion, quantum chemistry, and accelerator modeling, this paper discusses ideas on computa- tional quality of service (CQoS) — the automatic selection and configuration of components to suit a particular computational purpose. We discuss the synergy between component-based software design and CQoS, with em- phasis on features of the Common Component Architecture that provide the foundation for this work. We introduce the design of our CQoS software, which consists of tools for measurement, analysis, and control infrastructure, and we discuss directions of future work.
Ccaffeine is a Common Component Architecture (CCA) framework devoted to high-performance computing. In this note we give an overview of the system features of Ccaffeine and CCA that support component-based HPC application development. Object-oriented, single-threaded and lightweight, Ccaffeine is designed to get completely out of the way of the running application after it has been composed from components. Ccaffeine is one of the few frameworks, CCA or otherwise, that can compose and run applications on a parallel machine interactively and then automatically generate a static, possibly self-tuning, executable for production runs. Users can experiment with and debug applications interactively, improving their productivity. When the application is ready, a script is automatically generated, parsed and turned into a static executable for production runs. Within this static executable, dynamic replacement of components can be performed by self-tuning applications.
: As the commercial software industry burgeoned, it was clear that increasingly complex software would require a mechanism scaling across people, geography and time. The answer came in the concept of software components. Software components are stand-alone modules that have a prescribed means for composition into an application. Component concepts enable, for example, MS Word documents to appear in MS Powerpoint slides, and has led to the point-and-click user interfaces that inhabit most desktop computers today. The idea of a component in software comes from its root word: composeable. The process of connecting components together into an application can be likened to their electrical component analogue: hook transistors, diodes and resistors together one way, and you have a radio, another way and you have an MP3 player. The Common Component Architecture is a component model created by computational scientists from all of the DOE laboratories to establish a plug and play standard for high-performance computing. Recently the Common Component Architecture has been named on the Top 10 DOE Science Achievements in 2002 list (http://www.sc.doe.gov/sub/accomplishments/top_10.htm). Though computing has been synonymous with the DOE labs long before anyone dreamed of having a computer on their desktop, scientific computing high-performance scientific computing in particular has not benefitted from these advancements. This is because parallel computing, the mainstay of high performance computing, is not amenable to the component software existing in the commercial world. Parallel software requires a model that enables cooperation among thousands of individual processors, a situation not familiar to commercial software vendors. The Common Component Architecture was conceived to fill this gap.
This is a speculative work meant to stimulate discussion about the role of subsumability in self- similar software structures for computational simulations. As in natural phenomena, self-similar fea- tures in framework structures allow the size and complexity of code to grow without bound and still maintain apparent coherence. As in crystal growth, the coherence may be maintained by the application of a repeated pattern, or patterns may, as in fluid mechanical turbulence, be scaled by size and nested. Examples of these kinds of patterns applied to component systems in particular will be given. Conclu- sions and questions for discussion will be drawn regarding the applicability of these ideas to component architectures, complexity, and scientific computing.
Scientific computing on massively parallel computers presents unique challenges to component-based software engineering (CBSE). While CBSE is at least as enabling for scientific computing as it is for other arenas, the requirements are different. We briefly discuss how these requirements shape the Common Component Architecture, and we describe some recent research on quality-of-service issues to address the computational performance and accuracy of scientific simulations.
Overview The SciDAC Center for Technology for Advanced Scientific Computing Software (TASCS) focuses on developing tools, components and best practices for developing high quality, reusable high-performance computing software. TASCS fosters the Co mmon Component Architecture (CCA) through a community forum that involves a wide range of participants. The CCA environment aims to bring compone nt-based software development techniques and tools, which are commonplace in the computing industry, to high performance computing. To do so, several challenges are being addressed including parallelism, performance, and efficient handling of large datasets. The CCA has produced a specification that allows components to be deployed and reused in a highly extensible yet efficient parallel environment. The primary advantage of this component-base d approach is the separate development of simulation algorithms, models, and infrastructure. This allows the pieces of a complex simulation to evolve indepe ndently, thereby helping a system grow intelligently as technologies mature. The CCA tools have been used to improve productivity and increase capa bilities for HPC software in meshing, solvers, and computational chemistry, among other applications. TASCS supports a range of core technologies for using components in high-performance simula tion software, including the Caffeine framework, the Babel interoperability tool, and the Bocca development environment for HPC components. In additio n, the CCA helps provide access to tools for performance analysis, for coupling parallel simulations, for mixing distributed and parallel computing, and for ensuring software quality in complex parallel simulations. These tools can help tame the complexity of utilizing parallel computation, especially for sophisticated applications that integrate multiple software packages, physical simulation regimes or solution techniques. We will discuss some of these tools and show how they have been used to solve HPC programming challenges. The component-based software engineering (CBSE)[1] methodology has been developed to facilitate the understanding, development, and evolution of large-scale software systems. By emphasizing strong encapsulation of code with well defined interfaces between modules, a component approach pr ovides a way of decomposing software into units that are conceptually manageable, and that interact in specific and easily understood ways. These characteristics also facilitate the design and evolution of large, complex software s ystems by distinguishing between the functional specification of a component (fixed or slowly changing) and its implementation (possibly more rapidly changing , or even having multiple implementations). With thoughtful design of interfaces, component approaches can promote software reuse and interoperability. The encapsulation of components makes them useful in …
Boyana Norris合作论文数Mathematics and Computer Science Division;Argonne National Laboratory3
Sameer Shende合作论文数Department of Computer and Information Science, University of Oregon, Eugene, OR1