Common Component Architecture for High Performance Computing CCA

Common Component Architecture for High. Performance Computing CCA Working Group info: Rob Armstrong, rob@sandia. gov http: //www. acl. lanl. gov/cca-forum

What’s the problem? 9 HP computing has as much need for component arch’s as common computing does l l Complex and hard to program algorithms, data structures. Time-to-market is the consideration (e. g. SSI, ASCI curves). 9 Currently little reuse of code. l l attempts: Pet. Sc, POET, POOMA most HP applications are written from the ground up for a single purpose.

HP Component Architecture meets a critical DOE need that is not and will not be addressed by Silicon Valley.

The Common Component Architecture Requirements 9 Simple l l l to adopt to understand to use 9 Support a composition mechanism that does not impede high-performance component interactions. 9 Language interoperability l l Fortran, C, C++, Java interface introspection 9 Meant to live with and rely on other component frameworks to provide services. . . l and other complicated, hard-to-implement stuff.

The problem with existing Component Architectures 9 Overall: l l hi-latency connection is OK for loosely-coupled app’s: network OK for component composition not OK for high-performance app’s. 9 Specifics l l Java. Beans: composition only by events/listener. COM: no real interoperability, not vendor neutral. CORBA 2: no component model. CORBA 3 components: OK but complicated, only for loosely-coupled app’s. 9 Seek to supplement existing CA’s with an HP add-on.

Who are we? 9 Researchers in the HP components field that are dedicated to forming an open standard for HP components. l addressing the concerns of HPC. 9 Originated from DOE’s DOE 2 K program l l has its place in ASCI: Software Integration Curve. participation from universities.

CCA Active Participants * 9 Dennis Gannon (Indiana U) 9 Randall Bramley (Cal Tech) 9 Andy Cleary, Scott Kohn, Brent Smolinski (Livermore) 9 Kate Keahey, Pete Beckman, Bill Humphrey, Pat Fasel, (Los Alamos) 9 Rob Armstrong, Robert Clay, Carl Melius, Noel Nachtigal (Sandia) 9 Al Geist, Jim Kohl (Oak Ridge) 9 Lois Curfman Mc. Innes, Barry Smith, Paul Hovland Brian Toonen (Argonne) 9 Steve Parker (U Utah) 9 John Wu (Lawrence Berkeley) 9 Jarek Nieplocha (Pacific Northwest Labs) * Contact Rob Armstrong (rob@sandia. gov) if interested in joining the CCA mailing list.

Scientific IDL provides OO interoperability to C, C++, Java, Python, Fortran 77/90 9 Follows a Java-like interface model that will “glue” languages together with a minimum performance hit l expected overhead: ~2 -3 virtual function calls 9 IDL interoperability library supports interface introspection l l Necessary for run-time discovery of objects by frameworks Allows interfaces to be “recognized” by the framework without having specific advanced knowledge.

No plan for world domination. . . 9 do not try to organize complexity top-down. 9 Provide a medium of exchange 9 believe in Adam Smith’s invisible hand. . .

What have we come up with? 9 Scientific IDL spec. l l provides language interoperability only - not part of the component arch. per se. introspection. 9 Metaphor from visual programming (e. g. AVS) l l l instead of data-flow ports are linked with interfaces Provides/Uses design pattern 0. 5 CCA specification: http: //z. ca. sandia. gov/~cca-forum/port-spec

Port model hooks up an interface from one component to another

Ports preserve the high-performance of direct connections plus versatility of distributed object systems 9 Allows for directly connected interfaces: the next component is one function call away. 9 Adapters will create network-distributed objects out of the same components without altering them.

Generalized ports and the provides/uses design pattern for coupling components Component 1 Component 2 1 add. Provides. Port( Port register. Uses. Port("A") , "A") CCAServices Port 3 Port 2 CCAServices 4 Port = get. Port("A")

Where are we going? • Solving the Mx. M and Mx. N problem • SC 99 reference implementation of CCA with Equation Solver Interface ESI component. • experiments with the architecture.

Bone. Yard

generates “glue” code for supported languages IDL Interface Description IDL Database Language Mappings Compiler Details IDL Caller Language currently C and f 77 C++, Java soon called by library user Library Language IDL Compiler Stub Glue Code (e. g. code written in C) Skeleton Glue Code wraps library implementation

Ports can be used to characterize potential links to other components 9 Each CCA Component has l A list of “input” Ports where • An input g. Port defines an interface to services provided by the component. l A list of “output” Ports where • An output g. Port is the interface to a set of services required by the component. l Other “self-identification” features • allow component containers to probe the component properties. This may be rolled into its own g. Port. Server Input. Port Client Output

CCA is a component architecture that does not dictate frameworks or runtime 9 We are trying to create components that are usable under a variety of frameworks; 9 We are not making a new framework implementation. l l l provide a means for discovering interfaces, similar to IUnknown. specifically exclude how the components are linked, that is the job of a framework. provide language-independent means for creating components from existing and future languages.

Where are we? Details of the CCA specification. . . 9 Overall: http: //www. acl. lanl. gov/cca-forum 9 draft Port spec in RFC stage: http: //z. ca. sandia. gov/~cca-forum/port-spec 9 draft IDL spec in RFC stage: http: //www. llnl. gov/CASC/babel 9 CCA Demo applet & plug-in: http: //z. ca. sandia. gov/~cca-forum/cca-demo/ 9 Multiple test codes already exist. 9 Working on repository/naming issues.

Programmer can create a new Port by tying methods to a Port Pea Pod Usercreated Port port Port (1) Add pea to pod component (2) Create input and output port objects via introspection (3) Connect components

Conclusions 9 Philosophy: Not trying to “own the world. ” Trying to provide a “coin-of-the-realm” -- a medium of exchange -- that promotes an HPC software economy. 9 Overall: http: //www. acl. lanl. gov/cca-forum 9 Draft Port spec in RFC stage: http: //z. ca. sandia. gov/~cca-forum/gport-spec 9 Draft IDL spec in RFC stage: http: //www. llnl. gov/CASC/babel 9 CCA Demo applet & plug-in: http: //z. ca. sandia. gov/~cca-forum/cca-demo

SPMD view. . . 2 Different processes 2 2

What is a software framework and components 9 Component Concepts l l Autonomous interchangeable parts Links between components that create an application Builders Framework provides context or environment to components

Characteristics of Component Arch’s 9 Composition Phase 9 Run Phase

Language interoperability is a critical first step towards software interoperability 9 Software re-use is often hampered by language barriers l l DOE labs use many languages (f 77, f 90, C, C++, Java, Python) can be difficult for some languages to call others (f 77 to C++) 9 We are developing IDL technology for interoperability l l interface definition language (IDL) describes calling interface tools automatically generate code to “glue” languages A. Cleary, S. Kohn, S. Smith, B. Smolinski, Language Interoperability Mechanisms for High-Performance Scientific Applications, SIAM Interoperability Conference, 1998. f 77 f 90 C IDL C++ Python Java

CCA Ports employ a Uses/Provides design pattern for connections One component uses an interface provided by another. At the containing framework’s option: • Allows direct connections. • Allows connections through remote proxies all with the same components

Where we are going. . . 9 Port and IDL spec’s need to be solidified l l time and testing are now the big contributors to the spec. Publication: Web, HPDC in Aug, San Diego, demo SC 99. 9 CCA as a standards body l soliciting, accepting/rejecting proposals of interfaces and implementations for inclusion into the core CCA.

Command-line applet that implements the specification 9 link together pretend components to do string manipulations 9 Source code available

By definition components are software modules that are composable. . . 9 Component - Encapsulated software object that provides a certain functionality or service and can be used in conjunction with other components to build applications A component consists of l an API (abstract interface) and l one or more component implementations l common behavior among these components 9 CCA uses a peer component model - No particular component assumes it is “in charge” of the

ESI is a multi-lab effort writing an equation- solver component specification DOE initiative, building on previous efforts. SNL LLNL LANL ORNL LBL CSU Chico U. Indiana Ben Allan, Robert Clay, Lee Taylor, Alan Williams Colin Aro, Andy Cleary, Rob Falgout, Juliana Hsu Mike De. Long, Robert Ferrell, Wayne Joubert Barry Smith, Lois Curfman Mc. Innes Noel Nachtigal, Jack Dongarra John Wu Kyran Mish Randy Bramley 9 technical forum: if-forum@z. ca. sandia. gov (http: //z. ca. sandia. gov/esi)

Equation Solver Interface (ESI) group is defining interfaces for solvers

The goal of CCA group is enable applications constructed entirely of components Physics Modules Optimization Grids Adaptive Solution Diagnostics Discretization Steering Algebraic Solvers Visualization Derivative Computation Data Reduction Parallel I/O Collaboration

g. Ports connect component interfaces in a data-flow-like way 9 Needs to work for tightly coupled and dist. objects l tightly coupled for performance • allow overhead approx. a virtual function call l transparently marshal args and return values • transparency over various networks and environments 9 g. Ports is intended to provide a more efficient and scalable component connection mechanism l Input/Output g. Ports can call each other explicitly and directly.

Where we are now. . . 9 draft g. Port spec in pre-RFC stage: http: //z. ca. sandia. gov/~cca-forum/gport-spec 9 draft IDL spec in pre-RFC stage: http: //www. llnl. gov/CASC/babel 9 Multiple test codes already exist. l experiments with the Common Component Architecture. 9 Working on repository/naming issues. l Most likely to be developed from LDAP or JNDI.

Where we are going. . . 9 g. Port and IDL spec’s need to be solidified l l l a formal RFC must be accomplished for both IDL and g. Ports. will be tested in the working group’s own frameworks and refined from real-world experiences. the work will be published and advertised in appropriate places. 9 Repository/Naming Issues Addressed l Make appropriate hooks into the spec. to import a “standard” registry/repository/naming scheme.

Conclusion 9 CCA is our only hope l Here is the list of pan-lab HP software integration groups: • ESI - Equation Solver Interface specific only to this one field • CCA 9 The outside world is componentizing and integrating software, we cannot remain in the one-lab-one-code mode forever. l DOE has special needs with regard to HP software that the outside world is not addressing. http: //www. acl. lanl. gov/cca-forum

Programmer can create a new Port by tying methods to a port Pea Pod Usercreated Port port Port (1) Add pea to pod component (2) Create input and output port objects via introspection (3) Connect components

Rob: Paul’s from Barry CCA Plans: A Big Picture Non-linear solver component Multi-component interoperability Linear solver component Vector component

structured multigrid preconditioner from hypre package hypre { class stencil { static stencil New. Stencil(in int dim, in int size); int Set. Stencil. Element(in int index, in array<int> offset); }; class grid { static grid New. Grid(in mpi_com com, in int dimension); int Set. Grid. Extents(inout array<int> lower, array<int> upper); }; class vector { static vector New. Vector(in mpi_com, in grid g, in stencil s); int Set. Vector. Box. Values(/* long argument list omitted */); }; class matrix { /* matrix member functions omitted */ }; class smg_solver { int Setup(inout matrix A, inout vector b, inout vector x); int Solve(inout matrix A, inout vector b, inout vector x); }; );

Common Component Architecture Working Group http: //www. acl. lanl. gov/cca-forum Rob Armstrong rob@sandia. gov

What we are doing 9 The problem l l l Many incompatible frameworks. Much replication of s/w effort. Brave new world of network grids presents many opportunities & challenges to interoperability. 9 The solution l l A component arch. enabling interoperability between modules for scientific computing. Not defining a new framework, but a standard that will work within many frameworks.

Who we are 9 Participants design and implement components/frameworks for their respective institutions. l know component arch’s and HP computing meeting DOE lab needs. 9 Venue: Meet every 3 months.

The goal of CCA group is enable applications constructed entirely of components Physics Modules Optimization Grids Adaptive Solution Diagnostics Discretization Steering Algebraic Solvers Visualization Derivative Computation Data Reduction Parallel I/O Collaboration

Where we are now. . . 9 draft Port spec: http: //z. ca. sandia. gov/~cca-forum/port-spec 9 draft IDL spec: http: //www. llnl. gov/CASC/babel 9 Multiple test codes already exist. l Command-line demo: http: //z. ca. sandia. gov/~cca-forum/cca-demo 9 Working on repository/naming issues. l Will use the existing Ports mechanism to access these and other services.

Scientific IDL provides OO interoperability to C, C++, Java, Python, Fortran 77/90 9 Follows a Java-like interface model that will “glue” languages together with a minimum performance hit l expected overhead: ~2 -3 virtual function calls 9 IDL interoperability library supports interface reflection l l Necessary for run-time discovery of objects by frameworks Allows interfaces to be “recognized” by the framework without having specific advanced knowledge of active components

CCA Ports employ a Uses/Provides design pattern for connections One component uses an interface provided by another. At the containing framework’s option: • Allows direct connections. • Allows connections through remote proxies all with the same components

Where we are going. . . 9 Port and IDL spec’s need to be solidified l l time and testing are now the big contributors to the spec. Publication: Web, HPDC in Aug, San Diego, demo SC 99. 9 CCA as a standards body l soliciting, accepting/rejecting proposals of interfaces and implementations for inclusion into the core CCA.

CCA Active Participants * 9 Rob Armstrong, Robert Clay, Carl Melius, Bill Mason (Sandia) 9 Dennis Gannon (Indiana U) 9 Randall Bramley (Cal Tech) 9 Andy Cleary, Scott Kohn, Brent Smolinski (Livermore) 9 Kate Keahey, Pete Beckman, Bill Humphrey, Pat Fasel, (Los Alamos) 9 Al Geist, Noel Nachtigal (Oak Ridge) 9 Satish Balay, Lois Curfman Mc. Innes, Barry Smith, Paul Hovland, Lori Freitag (Argonne) 9 Steve Parker (U Utah) 9 Brent Milne (Lawrence Berkeley) 9 Jarek Nieplocha (Pacific Northwest Labs) * Contact Rob Armstrong (rob@sandia. gov) if interested in joining the CCA mailing list.

g. Port model hooks up an interface from one component to another

User applications can now invoke hypre routines from both C and Fortran 77 C Test Code Fortran 77 Test Code hypre_vector b, x; hypre_matrix A; hypre_smg_solver; integer b, x integer A integer smg_solver b = hypre_vector_New. Vector(com, grid, stencil); . . . x = hypre_vector_New. Vector(com, grid, stencil); . . . A = hypre_matrix_New. Matrix(com, grid, stencil); . . . b = hypre_vector_New. Vector(com, grid, stencil). . . x = hypre_vector_New. Vector(com, grid, stencil). . . A = hypre_matrix_New. Matrix(com, grid, stencil). . . smg_solver = hypre_smg_solver_new(); hypre_smg_solver_Set. Max. Iter(smg_solver, 10); hypre_smg_solver_Solve(smg_solver, &A, &b, &x); hypre_smg_solver_Finalize(smg_solver); smg_solver = hypre_smg_solver_new() call hypre_smg_solver_Set. Max. Iter(smg_solver, 10) call hypre_smg_solver_Solve(smg_solver, A, b, x) call hypre_smg_solver_Finalize(smg_solver) The end user is completely unaware that IDL tools were used