Software Development in HPC environments: A SE perspective

1. Software Development in HPC environments: A SE perspective Rakan Alseghayer

2. Agenda • Introduction • The Community • Differences • HPC Echo system • Overview of Roles • SD at the HPC Management • SD at the user level • What SE community can provide to scientists (users)? • Conclusion • References

3. Introduction • HPC environments are rapidly increasing since the past 20 years. Source: [3]

4. Introduction • Why HPC, and why Supercomputers? • Need for high computation and computational science. • Supercomputers are used in many application and domains, some are: Space exploration (“Roadrunner” at National Laboratory Los Alamos), nuclear weapon testing, and brute force code breaking, etc. • This resulted in a diverse community of users and developers (mostly scientists) from different backgrounds • Result? • Lack of software practices and engineering.

5. The community • Interesting to compare and contrast with the traditional software engineering community. (e.g. Users, both. Think different env.) Source: [1]

6. Differences • “Some” of the differences between the computational science and SE: • OO was never suitable for HPC, due to the high adoption of C and Fortran as a de-facto of programming language. • Frameworks are extremely difficult to be adopted by scientists and HPC developers. Instead, most prefer to develop their own written frameworks. Why? • Easier than fitting a problem into the existing framework. • IDEs are rarely used due to the nature of “batch –queued” systems, since computations are done in job submitting style. If they are, then remote execution on batch-queue system must be supported.

7. Overview • An important aspect of the HPC software development is that there are two major parties involved: the user (application developer) and the HPC manager (system developer). • Each party has their own responsibility and duties to maintain in order to build a functioning productive HPC system.

8. HPC Echo-system • The HPC system can be viewed as the following layered strata: • Where the middle (blue) layers are concerned with the HPC managers, and the top level is the part where the application developer is concerned with. Finally, the last layer is the hardware developer concern (not our scope here).

9. Where is the interest SE? • HPC Software Engineering can be seen from two different perspectives again, User, and HPC management. • HPC management has shown a big interest in adopting SE practices (Lawrence Berkeley NL) • A lot of maintenance and redundant tasks • Call for reusability?

10. Where is the interest SE? • Although effort reduction is on demand, not much interest from the users “scientist” community in SE. Why? • The goal is have publishable results. Not efficiency. (computational scientists vs. computer scientists). • Increasing performance is a goal, but not to sacrifice everything for performance.

11. SD in HPC Management • Waterfall doesn’t work in HPC • Near the application level. (tools - libraries) • Standard is test-driven development • Tight development loop: requirements, development and documentation, evaluation, test, deploy. • Orientation towards minimized maintenance • Work with vendors for early testing at customers site. • Thorough testing: unit, functional, system, integration, AT SCALE (time dedication). • Instrument codes at the application level are tested too for development and acceptance. • End-to-end testing using codes.

12. SD in HPC Management • Challenges: • Testing AT SCALE. • Resiliency! Need an approach towards the system as a whole (software and hardware) • Getting an understanding of the interaction between the layers. • Retiring software and systems. (who is responsible? New libraries, etc) • Managing executable and compilers when everything has to be recompiled. • Lack of tools for simulating new architectures in the HPC set. (as opposed to NWs)

13. SD in the User Level • Assuming that the user is welling to adopt the new paradigms. Challenges? • Scepticism to new technologies. A plus if it is compatible with older technology. • Debugging and validation is extremely difficult due to the nature of the computation. (think time of execution and allocation of resources! • Remote access changes the rules of the game. Different spectrum of tools.

14. Solutions to scientists? • What can we (SE community) provide to the application level users? • Practices and processes. • Apply existing paradigms to HPC and tune them to fit (research). • Publicize the success stories. • Education • At the university level, develop SE coerces, for computational scientists. • Reuse-in-the-large • Frameworks built on a well known technologies and libraries will be adopted faster.

15. Conclusion • This area has begun to gain interest very recently (the third SC SE workshop is this November!) • More scientist are involving in the software development. Rise for an interdisciplinary field? HPC Bioinformatics? HPC for astronomy? • Rise of new frameworks (e.g. Spark) • HPC managers can surely involve in educating the users through frequent work shops and training coerces (thanks PSC). • HPC paradigms in SE coerces?

16. Thank you! Questions? 

17. References Victor R. Basili, Jeffrey C. Carver, Daniela Cruzes, Lorin M. Hochstein, Jeffrey K. Hollingsworth, Forrest Shull, Marvin V. Zelkowitz, "Understanding the High-Performance-Computing Community: A Software Engineer's Perspective", IEEE Software, vol.25, no. 4, pp. 29-36, July/August 2008, doi:10.1109/MS.2008.103 Report of the 3rd DOE Workshop on HPC Best Practices: Software Lifecycles. “HPC Best Practices: Software Lifecycles”. http://www.top500.org/