Grid Application Development Software

Transcription

1 Grid Application Development Software Department of Computer Science University of Houston, Houston, Texas

2 GrADS Vision Goals Approach Status

3 GrADS Team (PIs) Ken Kennedy Ruth Aydt Francine Berman Andrew Chien Keith Cooper Jack Dongarra Ian Foster Dennis Gannon Carl Kesselman Dan Reed Linda Torczon Richard Wolski

4 E-Science: Data Gathering, Analysis, Simulation, and Collaboration Simulated Higgs Decay CMS LHC

5 What Is a Grid? A collection of distributed, interconnected data bases, instruments, computing and visualization resources, potentially dynamically (re)configured Accessed through a broad range of devices and methods Sharing a common set of services Exhibiting a great diversity in architecture, capabilities, reliability, availability, and predictability Managed and administered independently with a broad range of policies

6 GrADS - A Software Grand Challenge Goals Tools and methodologies for development and performance management of applications leading to predictable performance and high efficiency on Grids Challenges Presenting a high-level application development interface If programming is hard, its useless Designing and constructing applications for adaptability Mapping applications to dynamically changing configurations Determining when to interrupt execution and remap Application monitors Performance estimators

7 GrADSoft Architecture Goal: reliable performance under varying load Performance Feedback Software Components Performance Problem Real-time Performance Monitor Whole- Program Compiler Source Application Configurable Object Program Service Negotiator Scheduler Negotiation Grid Runtime System Libraries Dynamic Optimizer GrADS Project (NSF NGS): Berman, Chien, Cooper, Dongarra, Foster, Gannon Johnsson, Kennedy, Kesselman, Mellor-Crummey, Reed, Torczon, Wolski

8 GrADSoft Architecture Execution Environment Performance Feedback Software Components Performance Problem Real-time Performance Monitor Whole- Program Compiler Source Application Configurable Object Program Service Negotiator Scheduler Negotiation Grid Runtime System Libraries Dynamic Optimizer

9 GrADSoft Architecture Program Preparation System Execution Environment Performance Feedback Software Components Performance Problem Real-time Performance Monitor Whole- Program Compiler Source Application Configurable Object Program Service Negotiator Scheduler Negotiation Grid Runtime System Libraries Dynamic Optimizer

10 Research Strategy Begin Modestly prototype a series of applications using components of envisioned execution system ScaLAPACK Demo, Cactus Demo evolve the definition of performance contracts prototype reconfiguration system with performance monitoring, without dynamic optimization Move from Hand Development to Automated System identify key steps use experience to expand design of software integration and execution systems Experiment use an artificial testbed to test performance under varying conditions move to real applications on the MacroGrid testbed

11 GrADS - Status Testbeds Macro Grid (based on Globus, site resources) Micro Grid (Andrew Chien et. al., simulator) Experiments ScalaPack (GrADS team, Dongarra lead) Cactus (Ed Seidel et. al., GrADS team)

12 GrADS ScaLAPACK Implement a version of a ScaLAPACK library routine that runs on the Grid. Make use of resources at the user s disposal Provide the best time to solution Proceed without the user s involvement Make as few changes as possible to the numerical software. Assumption is that the user is already Grid enabled and runs a program that contacts the execution environment to determine where the execution should take place.

13 How ScaLAPACK Works To use ScaLAPACK a user must: Download the package and auxiliary packages to the machines Write a SPMD program which Sets up the logical process grid Places the data on the logical process grid Calls the library routine in a SPMD fashion Collects the solution after the library routine finishes The user must allocate the processors and decide the number of processors the application will run on The user must start the application mpirun np N user_app The number of processors is fixed by the user before the run Upon completion, return the processors to the pool of resources

14 GrADS Numerical Library Want to relieve the user of some of the tasks Make decisions on which machines to use based on the user s problem and the state of the system Optimize for the best time to solution Distribute the data on the processors and collections of results Start the SPMD library routine on all the platforms Check to see if the computation is proceeding as planned If not perhaps migrate application

15 Grid Environment for this Experiment 4 cliques 43 boxes UCSD Quidam, Mystere, Soleil PII 400Mhz 100Mb sw Dralion, Nouba PIII 450Mhz 100Mb sw UIUC amajor-dmajor PII 266Mhz 100Mb sw opus0, opus13-opus16 PII 450Mhz Myrinet U Tennessee cypher01 cypher16 dual PIII 500Mhz 1 Gb sw U Tennessee torc0-torc8 Dual PIII 550Mhz 100 Mb sw ferret.usc.edu 64 Proc SGI mhz Mhz jupiter.isi.edu 10 Proc SGI lunar.uits.indiana.edu

16 Components Used Globus version Autopilot version 2.3 NWS version 2.0.pre2 MPICH-G version ScaLAPACK version 1.6 ATLAS/BLAS version BLACS version 1.1 PAPI version GrADS Crafted code Millions of lines of code and installed on the GrADS Macro Grid

17 Heterogeneous Grid TORC CYPHER OPUS Type Cluster 8 Dual Pentium III OS Red Hat Linux SMP Cluster 16 Dual Pentium III Debian Linux SMP Cluster 8 Pentium II Red Hat Linux Memory 512 MB 512 MB 128 or 256 MB CPU speed 550 MHz 500 MHz MHz Network Fast Ethernet (100 Mbit/s) (3Com 3C905B) and switch (BayStack 350T) with 16 ports Gigabit Ethernet (SK- 9843) and switch (Foundry FastIron II) with 24 ports IP over Myrinet (LANai 4.3) + Fast Ethernet (3Com 3C905B) and switch (M2M-SW16 & Cisco Catalyst 2924 XL) with 16 ports each

18 Performance Model vs Runs

19 Overheads

20 Grid ScaLAPACK vs Non-Grid ScaLAPACK, Dedicated Torc machines Time (seconds) Time for Application Execution Time for processes spawning Time for NWS retrieval Time for MDS retrieval 0 Grid Non- Grid N=600, NB=40, Grid Non- Grid N=1500, NB=40, Grid Non- Grid N=5000, NB=40, Grid Non- Grid N=8000, NB=40, Grid Non- Grid N=10,000, NB=40, 2 torc procs. Ratio: torc procs. Ratio: torc procs. Ratio: torc procs. Ratio: torc procs. Ratio: 1.29

21 ScaLAPACK across 3 Clusters Time (seconds) OPUS OPUS, CYPHER OPUS, TORC, CYPHER 2 OPUS, 4 TORC, 6 CYPHER 8 OPUS, 4 TORC, 4 CYPHER 8 OPUS, 2 TORC, 6 CYPHER 6 OPUS, 5 CYPHER 8 OPUS, 6 CYPHER 8 OPUS 5 OPUS 8 OPUS Matrix Size

22 Largest Problem Solved Matrix of size 30, GB for the data 32 processors to choose from UIUC and UT Not all machines have 512 MBs, some little as 128 MBs PM chose 17 machines in 2 clusters from UT Computation took 84 minutes 3.6 Gflop/s total 210 Mflop/s per processor ScaLAPACK on a cluster of 17 processors would get about 50% of peak Processors are 500 MHz or 500 Mflop/s peak For this grid computation 20% less than ScaLAPACK

23 UHFFT Library Organization UHFFT Library Library of FFT Modules Initialization Routines Execution Routines Utilities FFT Code Generator Mixed-Radix (Cooly-Tukey) Split-Radix Algorithm Prime Factor Algorithm Rader Algorithm Unparser Scheduler Key: Optimizer Initializer (Algorithm Abstraction) Fixed library code Generated code Code generator

24 Summary Goal: Build programming systems for the Grid that enable ordinary users to develop and run applications in this complex environment Execution of applications must be adaptive In response to changing loads and resources Software support is challenging Must manage execution to reliable completion Must prepare a program for execution Should support high-level domain-specific programming For breadth of user community Research strategy involves developing a series of prototypes Evolve the infrastructure based on lessons learned