Software Development in HPC environments: A SE perspective Rakan Alseghayer

Preview:

Citation preview

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)

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.

13

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.

14

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?

15

Thank you!

Questions?

16

References

1. 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

2. Report of the 3rd DOE Workshop on HPC Best Practices: Software Lifecycles. “HPC Best Practices: Software Lifecycles”.

3. http://www.top500.org/

17

Recommended