|
Workshop on Software Tools for HPC Systems
Final Report |
 
|
|
|
|
|||
 |
|
||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||
|
|
|||||||||||||
Executive Summary
|
In October 1996, we organized the sixth in a series of workshops on software tools for high-performance computing. With funding from the Department of Energy, the National Aeronautics and Space Administration, the National Science Foundation, and the Defense Advanced Research Projects Agency, the goal of this workshop was to explore the feasibility of creating a national software tool testing and evaluation center. The workshop and its theme were motivated by a growing realization that the small size of the high-performance computing market and the rapid pace of technological change have rendered traditional mechanisms for software technology transfer ineffective. Despite continued requests from users, both hardware vendors and independent software developers see little financial incentive for software tool development; tool development costs simply cannot be amortized across sales of tens of high-end systems. Similarly, the research community lacks the financial resources to harden and support valued research prototypes for a large external user base. A software testing and evaluation center offers a possible solution to this conundrum. By identifying and supporting promising software prototypes, a center could serve as a conduit for technology transfer to vendors and as a support center for valued, though not commercially viable, software tools. To explore the issues surrounding possible creation of a software testing and evaluation center, roughly 100 participants, drawn from academia, government, and industry, met for three days in October 1996 at Cape Cod. The workshop was organized as a sequence of sessions that included invited presentations and extensive, directed discussion periods. In turn, the invited presentations were structured as a mix of technical summaries of current software tool research issues and reviews of software tool distribution mechanisms. The discussion periods focused on both new research problems in debugging and performance analysis and on the organizational structure of a possible software testing and evaluation center. The workshop participants all agreed that collaboratively developing robust, user-friendly performance tools for high-performance parallel systems is expensive and intellectually challenging. Moreover, effective tool development requires many mundane activities not normally associated with academic computer science research, namely testing early prototypes with friendly users who are application scientists, developing and testing intuitive user interfaces, and writing manuals and documentation. The workshop attendees concluded that a creating a national, though distributed software tool evaluation and testing center was the only practical solution to the HPCC software tool crisis. Co-located with extant HPCC centers and organized as a cooperating group of developers and support staff, the proposed center would work with academic researchers, application scientists, and vendors to evaluate and test prototype software tools. The center staff would "harden" and support modest number of prototype tools, creating documentation, porting software to multiple platforms, and fostering standard interfaces for tool interoperability. By organizing the center as a set of cooperating groups at HPCC sites, the center structure would capitalize on diverse resources and users and, ideally, capture the best features of current distributed centers. Moreover, the center would fill an important gap between the generation of ideas by the research community and consortia like the Parallel Tools (PTOOLS) group and the dissemination of software by the National High-Performance Software Exchange (NSHE). |
||||||||||||
|
|
|||||||||||||
|
Background and Motivations
|
Though fierce vendor competition for a share of the High-Performance Computing and Communications (HPCC) market has led to rapid architectural innovation and higher peak hardware performance, the software infrastructure for massively parallel systems has not kept pace with the rapid evolution of new parallel architectures. The pace of hardware innovation has stretched academic, laboratory, and vendor software development groups to the limit, forcing them to continually create software tools for changing programming models and new hardware environments. The critical importance of robust, flexible, and efficient software tools has long been recognized and has been a major discussion topic at several national HPCC meetings, including those in Pasadena [3,4] and Pittsburgh [9] and at a series of workshops on software tools hosted by the authors [6,7,8]. These meetings focused on the intellectual difficulties associated with building good tools and, equally importantly, the lack of incentives and infrastructure for tool development and testing. Research ideas can be explored with a small cadre of graduate students, but building robust tools requires both experience with real user needs and a major development effort. Small profit margins and short product life cycles, both leading to small installed product bases, have made it extraordinarily difficult for tool developers to gain the needed experience with user software development idioms and to create and support effective tools. By necessity, tools embody knowledge of the execution environment, identifying performance bottlenecks or logical program errors in terms of application code constructs and their interaction with the execution environment. Because the root causes of poor performance or unexpected program behavior may lie with run-time libraries, compilers, the operating system, or the hardware, tools must gather and correlate information from many sources. Not only does this correlation require interfaces for information access, the need for such information is most often gained only from experience. Experience comes with time, as tool developers understand the common programming idioms, the interactions of application code and the underlying hardware and software, and the user interfaces best suited for relating these interactions in intuitive ways. Simply put, developing good tools takes time, experience and substantial effort; small profit margins and short product life cycles, both leading to small installed product bases, have made it extraordinarily difficult for tool developers to create and support effective tools. Poor Software Tools: An Old Problem Is the dearth of effective software tools a new problem? No, the lack of good software development tools can be traced to the very origins of high-performance computing (e.g., early CDC FORTRAN compilers were very inefficient, and the Cray 1 was delivered with essentially no software). However, as high-performance systems have become more widely available and accessible, the long-standing lack of tools has become more evident. More perniciously, the ferment in the HPCC market has led to short product life cycles, with vendors and application developers repeatedly moving to new architectures and programming models. Often, by the time system software has sufficiently stabilized and there is sufficient knowledge of common programming idioms to permit construction of robust and useful tools, the underlying hardware is no longer performance competitive. Finally, the burgeoning personal computer market continues to raise user expectations to ever higher levels. The widespread availability of high quality, inexpensive desktop software leads users to (a) question the lack of similar tools on high-performance systems and (b) expect interoperability between desktop tools and those on high-performance systems. In short, the software infrastructure for massively parallel systems has been unable to keep pace with the rapid evolution of new parallel architectures. The paucity of basic software tools for application program development, debugging, and performance tuning has limited the use of scalable parallel systems to a small cadre of hardy pioneers willing to brave a wilderness of experimental hardware, immature software, and frequently changing tools. Substantial research money is directed toward study and development of software tools, but as Pancake asked at our 1993 workshop on performance tools, Why don't users use the tools that tool developers develop?" The workshop attendees agreed that the fundamental reasons for this dilemma relate to the lack of incentives for tool development and testing. First, the massively parallel systems market is small, and the real cost of commercial tool development is high. As vendors prioritize development of new systems, functioning hardware, operating systems and compilers receive the highest priority, for machines cannot be shipped without these. However, competitive pressures and development schedule slippage often lead vendors to ship their new systems prematurely, before other infrastructure such as software development tools can be created. Due to these pressures on vendors to ship, the temptation is very high for them to simply "repackage'' internal development tools for external use, even when inappropriate for users. From a financial perspective, developing robust software tools for a parallel system with projected sales of 500 units is nearly as costly as developing software for the burgeoning personal computer market, but without concomitant financial incentives. These same economics preclude creation of a viable third party software industry (i.e., the independent software vendors (ISVs)). One of the workshop working groups addressed the implications of market size for tool development. Second, another potential source of software tools, the academic and laboratory research community, lacks the reward structure, the financial resources, and (often) the skills to develop and support robust software tools. The academic computer science community is rewarded, both tangibly and intangibly, for development of software prototypes and publication of the ideas underlying these, but not for the additional development needed to make these prototypes really usable by the larger HPCC community. Moreover, because there is limited interaction between academic tool developers and potential tool users, prototype tools often lack important features or are simply not useful to application developers. Although there are a plethora of reasons for this situation, most are subsumed under the rubric of limited collaboration and funding. Inappropriate tools often result because application developers, tool developers, and vendors are not intimate collaborators in the tool development process; current academic and commercial realities do not reward such collaboration. Moreover, vendors are reluctant to embrace, extend, and market academic software unless it is already robust, as evidenced by wide use within the application community. Finally, an undue emphasis on peak hardware performance, at the frequent expense of sustained, readily achievable performance, leads to rapid changes in hardware and system software. Poor Software Tools: A Worsening Problem In many senses, the software tool dilemma is worsening. The World Wide Web, distributed metacomputing, and new parallel programming models all pose unsolved problems for software tools. Tools for task and data parallel languages, techniques for real-time adaptive system control, and optimization of heterogeneous metacomputing applications. are all united by the need for greater access to system internals and data and by the need for standard interfaces, both internally and for users. Historically, performance and debugging tools have been developed independently of system software and compilers. This separation reflects both the integration of software from disparate sources (i.e., third party compilers and operating system kernels) and limited support provided by software systems for tool development. For example, operating systems typically provide debugger developers little more than a UNIX ptrace system call for controlling process execution and performance tool developers only a mechanism for accessing a coarse-resolution system clock. Similarly, compilers provide simple symbol table information in object files. For single processor systems, these features are sufficient to build breakpoint debuggers and profilers, though they are far from optimal. For parallel systems and workstation clusters, they are woefully inadequate. At present, few compilers provide access to program transformation data, though debugging and tuning the performance of programs written in task and data parallel languages (e.g., like High-Performance FORTRAN (HPF) [2]) requires both compile-time and run-time data. Relating the dynamic behavior of compiler-synthesized code to the user's source code requires knowledge of the program transformations applied by the compiler and the code generation model. For example, if an HPF compiler generates message passing code for a distributed memory system, understanding how messages relate to array locality is a key to improving performance. Moving beyond tools for explicit parallelism (e.g., via message passing) will require far tighter integration of tools with compilers. Likewise, few operating systems or run-time libraries provide mechanisms for selecting resource management policies or for configuring those policies based on knowledge of application resource demands or dynamic performance data. However, many experiments have shown that tuning policies to application behavior is key to improving performance for irregular applications with complex behavioral dynamics. For example, as part of the Scalable I/O Initiative, researchers have shown that selecting and configuring file system input/output policies to match application input/output patterns and hardware configurations can dramatically increase achievable application input/output performance. The explosion of World Wide Web (WWW) use, together with rapidly expanding interests in distributed data mining and heterogeneous parallel computing, pose a different, though equally thorny, set of tool research problems. New types of debugging and performance tuning tools will be needed to create metacomputing applications that can exploit distributed computation resources (e.g., by distributing a computation across multiple, geographically dispersed parallel systems) and that can mine large data archives in response to complex queries. Measuring network latencies and bandwidths and adapting to changes in network loads will necessitate integration of "standard" tools for parallel systems with distributed network management mechanisms (e.g., like the Simple Network Management Protocol (SNMP)). Support for new programming models, tuning of resource management policies, and management of distributed metacomputations requires interfaces and access to data not readily available via present methods. This will require creation of a new generation of performance analysis and debugging tools that are more tightly coupled with runtime libraries, operating systems, and compilers. In turn, this greatly exacerbates current software tool development problems (i.e., access to data and software interfaces). |
||||||||||||
|
|
|||||||||||||
|
Workshop Context
|
Recognition of the technical, economic, and sociological problems facing the high-performance computing community motivated us to organize a series of workshops on software tools. The most recent workshop was the sixth in a series of workshops organized by Los Alamos National Laboratory and the University of Illinois. Begun in 1988, these workshops have evolved from an initial focus on the technology and research issues underlying creation of performance and debugging tools to an assessment of the technical, political, and economic constraints on high-performance computing software tools. Simply put, the goal of the workshop series is to address the changing roles and expectations for software tools in the high-performance computing and communications domain. The first workshop, held in 1988, occurred just as the national High-Performance Computing and Communication (HPCC) program began. At that time, massively parallel systems were the emerging future of high-performance computing, rather than a current reality. A substantial fraction of the first workshop was devoted to directed discussions of performance instrumentation problems on three broad classes of parallel systems architectures: shared memory, distributed memory, and data flow. During these discussions, vendors, academics, and users spoke frankly and at length about the problems they faced and possible solutions [6]. A second workshop was held in 1989 [8]. Here, researchers described the functionality of prototype performance tools and discussed initial experiences applying the tools in real execution contexts. The third workshop, held in 1991, focused on issues of performance measurement, data analysis, and visualization as they related to large-scale parallel systems. By this juncture, real systems had appeared and were being actively used by a growing cadre of software developers. Reflecting practical experience with software tools and market pressures faced by HPCC vendors, the fourth workshop, held in 1993, shifted its focus to the interplay between technical issues and software "success." The workshop brought together application software developers and tool developers to engage in an exchange of ideas on what are necessary, possible and appropriate performance tools for massively parallel systems. The predominant theme that emerged from the workshop was that software tools, both performance and debugging, were neither widely available nor widely used and that this fact was adversely affecting the entire high-performance computing community. Finally, the fifth workshop, held in 1994, combined both debugging and performance tool groups [7]. Building on the concerns of the previous workshop, the participants were united in their belief that the only practical solution to the paucity of effective software tools for high-performance systems was a community effort to create a software tool testing center. Such a center would work with academic researchers, application scientists, and high-performance computer vendors to evaluate, test, and enhance prototype software tools. In addition, the center would foster both industry standards for tool interoperability and technology transfer of mature software prototype. The sixth workshop, summarized in this report, was convened to explore the technical and logistical organization of a possible software testing and evaluation center. The speakers and technical working group topics were chosen to explore these issues in detail. The workshop began with a keynote presentation by Ken Kennedy on technology transfer paths for HPCC software. The talk discussed the "standar"d model of technology push from research groups to both computing vendors and independent software vendors (ISVs) and the economic conditions that have limited its success. Dan Reed then discussed his experiences with software technology transfer, which echoed Kennedy's comments. He then summarized the recommendations of the fifth workshop and its rationale for a possible software testing and evaluation center. Following this, he outlined the organizers' charges to six workshop discussion groups. |
||||||||||||
|
|
|||||||||||||
|
Attendees and Student Participation
|
To explore the issues surrounding possible creation of a software testing and evaluation center, roughly 100 participants, drawn from academia, government, and industry, were invited to attend the workshop. One of the most successful components of the workshop was the inclusion of graduate students. With support from NSF, we invited software tool researchers and one of their graduate students to attend the workshop as a pair. Each student participated fully in the workshop and its discussion groups and also presented a poster on their work at the evening reception. By involving students in the discussion, we hoped that new research relationships would be established, not only among the researchers, but also among the students. These students are the next generation of computational and computer scientists. It is critical that they form close working relationships; the days when computer science and computational science developed in isolation are past. |
||||||||||||
|
|
|||||||||||||
|
Workshop Discussion Groups
|
Because we have long felt the primary purpose of a workshop should be discussion, not passive listening, roughly half the workshop was devoted to organized discussion via a set of six working groups. Each working group was charged to consider either specific technical issues related to HPCC software tools or a particular set of issues related to organization of a software testing center. These groups addressed the following issues:
|
||||||||||||
|
|
|||||||||||||
|
Working Group Summaries
|
The appendices to this report contain the analyses of these and other questions as reported by the working groups. Below, we summarize the key points of each working group and the general themes that emerged from the workshop discussions. Technical Issues (Performance Tools and Debuggers): Working groups one and six considered the technical problems faced by performance tool and debugging researchers, particularly as software tools evolve from homogeneous parallel systems to include distributed collections of heterogeneous systems. The performance tool group reiterated the observation that there is no single model of successful tool development and deployment. Instead, tools evolve in a variety of ways and originate from many sources. In consequence, they suggested that a software testing center should not supplant current mechanisms for tool development and funding, but rather should augment it by evaluating and enhancing research prototypes. They further noted that the primary challenges faced by performance tool developers are heterogeneity, hierarchy, and scale. The emergence of metacomputing, of scalable systems with thousands of processors (e.g., as in the Department of Energy Accelerated Strategic Computing Initiative (ASCI) systems), and of hierarchical shared memory systems and data parallel programming models all pose new problems for performance tool designers. The debugging working group noted that debugger designers face daunting and conflicting goals: the need to report environment-specific data while also providing a portable, extensible interface. The lack of accepted standards for user interfaces exacerbates tool development and frustrates users who regularly use multiple systems. The group felt that a software testing and evaluation center should foster understanding of user and developer needs via workshops and usability testing. Moreover, the center should encourage standardization, test and evaluate prototypes with real users, and reduce the effort required for vendors and academic researchers to create usable tools. Finally, a center should support useful tools on standard platforms. center Management Issues: Working group two explored possible management and organizational structures for a testing and evaluation center. The group took as its working hypothesis the belief that the centerÍs goals should be to collect, evaluate, enhance, and support key software tools that have minimal potential for commercialization due to market size. The group felt that this hypothesis implied that the center would necessarily focus on a modest number of prototype tools that had established users and that were sufficiently robust to make extension and testing feasible. The working group also considered possible management structures for the center. After discussion, the group concluded that the center should incorporate the best features of the distributed NSF center for Research on Parallel Computation (CRPC) and the Corporation for National Research Initiatives (CNRI). The CRPC model for the center would create a distributed set of collaborating partners to evaluate and enhance selected prototype tools. In contrast, a CNRI model would emphasize a small core staff responsible for establishing mini-consortia to evaluate, enhance, and maintain prototypes. Both models have similar goals, differing primarily in the mechanism for forming partners. The group felt that the center should have a permanent staff co-located with a supporting computing infrastructure. Software Selection and Vendor Participation: Working group three's charter was to explore the criteria used to select software for center development and support and how vendors might participate in the center. After considerable discussion, the group concluded that while a center should encourage vendor participation as much as possible, the primary customers should be the application developers for high-performance systems. This conclusion was based on comments by participating hardware vendors, who noted that hardware generated revenue, not software tools. Hence, any adoption and commercialization of software tools by hardware vendors must be simple and inexpensive. Independent software developers (ISVs) are somewhat more amenable to technology transfer and collaborative software testing and evaluation. Like other groups, this group assumed that the center would test, evaluate, harden, document, and support software tools. In contrast to other groups, however, they assumed the center might also develop new tools. A formal evaluation board would consider proposals and recommend allocation of center resources to (a) testing and evaluation, (b) prototype tool hardening, and (c ) new tool development. This evaluation board would be composed of researchers, vendors, users, and center staff. The group noted that the mission of the proposed center naturally complements both the Parallel Tools (PTOOLS) consortium and the National HPCC Software Exchange (NHSE). The PTOOLS group works to define, develop and promote parallel tools. As such, it can be viewed as a possible source of prototypes for augmentation by the center. Conversely, the NHSE is a distribution service for software, documents, and data. Hence, it is a logical dissemination mechanism for software produced by the center. Intellectual Property Issues: The fourth working group considered the implications of software development and augmentation by temporally and spatially distributed groups and the ownership issues implied by such development. Moreover, participants may include academic researchers, vendors, and national laboratory staff, each with intellectual property (IP) rules defined by their employers and funding agencies. The group considered five different models for software and IP management, ranging from an independent testing center to a software hardening model. After much discussion, the group concluded that the software hardening model, similar to that discussed by other groups, was the most viable and useful. Under the model, the center would accept software testing proposals from the community, identify appropriate prototype tools, enhance and augment the tools, create user documentation, and convert them to usable tools. As with the software selection group, the IP working group identified end users as the primary target rather than HPCC vendors. In consequence, the group assumed that the center would continue to distribute software hardened tools throughout their useful lifetime. To address the intellectual property problems that arise from multiparty development and technology transfer, the HPCC agencies must adopt consistent IP policies. It also recommended that the center serve as a clearing house for IP information and education for the HPCC community. To minimize later problems, the center should insist on a full IP disclosure on tools prior to their adoption by the center and all IP issues should be negotiated in advance. Technical Infrastructure: Working group five considered the resources needed by a national software testing and evaluation center. The group took as its working hypothesis the belief that the center would serve five functions: early evaluation of promising ideas, enhancement of research prototypes to usable levels, creation of reference implementations for key tools, definition of standard tool interoperability conventions, and education of researchers and students. With this basis, the group concluded that a testing and evaluation center must be co-located with one or more national HPCC sites (e.g., Department of Energy laboratories, NSF supercomputer centers, or NASA centers with strong computational programs). To ensure diversity of users and machines, the center should be physically distributed across a small number of HPCC sites. This distribution and co-location would not only enable access to high-performance computing facilities, it would allow center staff to exploit local expertise, both for software testing with real users and interaction with technical support staff. Although co-located, the testing center should be independent of the host organization, with its own funding base and management authority. Finally, the center staff would consist of a group of software tool developers, user support staff, and technical writers. To support software testing and evaluation, the center would also need dedicated computing facilities, though not of the large scale available at national HPCC centers. As a complement, the center would also require access to commercial software development tools and to source code for key HPCC system components. These "crashable" facilities would enable the testing center staff to evaluate and develop prototypes that interact closely with system software and hardware while not interrupting production computation on large systems. |
||||||||||||
|
|
|||||||||||||
|
Workshop Recommendations
|
The workshop participants all agreed that collaboratively developing robust, user-friendly performance tools for high-performance parallel systems is expensive and as intellectually challenging as national challenge science, yet it is often assumed to be "easy," despite the fact that tool developers on new systems face the same software problems as application developers, and their tools must interoperate with multiple applications. Moreover, effective tool development requires many mundane activities not normally associated with academic computer science research, namely testing early prototypes with friendly users who are application scientists, developing and testing intuitive user interfaces, and writing manuals and documentation. Most of the activities are not rewarded by the computer science research community. Activities such as supporting a user community, teaching training classes, and adapting software to new hardware and software releases will not bring tenure, peer adulation, better graduate students or (usually) larger research support; therefore, most academic computer scientists have little incentive to develop a tool beyond the prototype stage. The workshop attendees concluded that a creating a national, though distributed software tool evaluation and testing center was the only practical solution to the HPCC software tool crisis. Co-located with extant HPCC centers and organized as a cooperating group of developers and support staff, the proposed center would work with academic researchers, application scientists, and vendors to evaluate and test prototype software tools. The center staff would "harden" and support modest number of prototype tools, creating documentation, porting software to multiple platforms, and fostering standard interfaces for tool interoperability. These views are not simply those of the workshop organizers or the participants in the most recent workshop. They mirror those expressed at the Pasadena [3,4] and Pittsburgh [9] meetings and at the five performance and debugging tool workshops. The workshop attendees have repeatedly recommended a major project to understand the limitations of current tools, the requirements for future tools, and to exploit this knowledge to transfer useful software prototypes to the application community and to commercial vendors. Clearly, however, one center cannot and should not supplant traditional mechanisms for technology transfer from academia to industry. We envision a more synergistic relationship with these traditional mechanisms. Moreover, it is important to realize that there are many possible definitions of software tool "success" that do not include commercialization. Indeed, as argued earlier, commercialization is extraordinarily difficult, and many valuable tools have no commercial market. Pragmatically, success means that a software tool is useful, tested, documented, and widely used. Hence, the goal of the center would be to serve as the focal point for the software tool development, vendor, and computational science communities to increase the number and breadth of useful and necessary tools and to encourage commercialization. To realize this goal, the workshop attendees and organizers envision four foci. Early Prototype Testing and Evaluation: Typically, academic tool researchers develop simple software prototypes to demonstrate a proof of concept prior to publication. Because most of these projects are small, there are few opportunities to test the ideas with appropriate external users and to learn what aspects of the approach have practical merit. By coupling academic tool researchers with a group of friendly users at supercomputing centers, where there is the infrastructure needed to support early prototypes, the tool researchers can gain early feedback on the practicality of their ideas. Those prototypes that show promise of potential usefulness to application developers could then be further developed with the center's assistance, and where appropriate, in cooperation with one or more vendors. An additional bonus from this stage would be also to gain new research ideas. Mature Prototype Testing and Extension: Smaller numbers of prototypes are sufficiently mature to be used and useful to a user community not co-located with the tool developer. Major reasons for the importance of co-location include tool bugs, lack of documentation, missing features, and support for only a small number of parallel hardware platforms. Proximity to developers increases the likelihood of interaction to aid in overcoming these deficiencies. Tools in this class, however, have passed an initial "usefulness test" by the application community. Hence, the second focus of the center would be to work with users to aggressively test these tools, identify bugs and inadequacies, work with the original tool developers to fix those bugs and add missing features, and (where appropriate) extend the tool to other hardware platforms. Vendor Cooperation and Standards: Both the promising early prototypes and the more useful, mature tool prototypes should have vendors involved in their evaluation and testing early in the cycle if commercialization is at all an option. Not every tool "vetted" by the center will be a candidate for adoption by one or more vendors; however, many would viewed as sufficiently useful to be of interest to vendors of high-performance parallel systems. Software Packaging and Support: Finally, tools deemed useful and worthy of dissemination, but not adopted by one or more vendors, must be documented, packaged for installation at remote sites, and, when problems arise, supported, patched, and upgraded. Although this work is mundane, some entity must assume this responsibility, else even good tools will not be used for long periods. |
||||||||||||
|
|
|||||||||||||
|
Summary
|
The need for "better" software performance analysis and debugging tools (where better means easier to use, more efficient, better integrated, and more informative) for high-performance parallel systems is a well documented and widely recognized need. The Strategic Implementation Plan [1] of the Committee on Information and Communications of the National Science and Technology Council has noted that "Raising the productivity of the software industry through simplifying toolkits can yield significant dividends in the international marketplace and enable more rapid introduction of hardware advances into affordable production systems." Raising the productivity of applications developers through appropriate, easy-to-use software performance and debugging tools creates a larger market for these affordable production systems. Providing a place where these tools can be effectively tested, evaluated and improved can ensure success in the entire high-performance parallel computing industry. |
||||||||||||
|
|
|||||||||||||
|
References |
1. Committee on Information and Communications, National Science and Technology Council, "Strategic Implementation Plan: American in the Age of Information," March 1995 2. Koelbel, C., Loveman, D., Schreiber, R., Steele, G, and Zosel, M., The High-Performance FORTRAN Handbook, MIT Press, Cambridge, MA, 1994 3. Messina, P. and Sterling, T. (Eds.), Pasadena Workshop on System Software and Tools for High-Performance Computing, SIAM, January 1992 4. Messina, P. and Sterling, T. (Eds.), "Second Pasadena Workshop on System Software and Tools for HPC Environments," January 1995 5. Pancake, C., "Collaborative Efforts to Develop User-Oriented Parallel Tools," in Debugging and Performance Tuning for Parallel Computer Systems, Simmons, Hayes, Reed, and Brown (Eds), IEEE Computer Society Press, December 1995 6. Simmons, M. , Koskela, R., and Bucher, I. (Eds), Instrumentation for Future Parallel Computing Systems, Addison-Wesley, 1989 7. Simmons, M. L., Hayes, A. H., Brown, J. J., and Reed, D. A., Debugging and Performance Tuning for Parallel Computing Systems, IEEE Computer Society Press, 1995 8. Simmons, M. and Koskela, R. (Eds.), Parallel Computing Systems: Performance Instrumentation and Visualization, Addison-Wesley, 1990 9. Stevens, R. (Ed.), "Workshop and Conference on Grand Challenge Applications and Software Technology," May 1993 |
||||||||||||
|
|
|
||||||||||||
|
|
|||||||||||||
