Spm.Python, a commercial product, extends Python with a programming paradigm for solving parallel problems and strives to do so in a pythonic (natural) way. This is achieved by augmenting the serial Python language with parallel concepts like parallel task managers and communication primitives.

In this poster session, we examine the what, why and how this augmentation was done. The context for and solutions to three formerly open technical problems will be discussed, including:

• extensions to the general exception handling infrastructure across many compute resources,

• design of parallel constructs in a way so that serial components are delineated from parallel components, and

• declaration and definition of parallel closures, the building blocks of all parallel constructs.

Parallel exception infrastructure

To quote Wikipedia, "exception handling is a construct designed to handle the occurrence of exceptions, special conditions that change the normal flow of program execution".

As such, the ability to throw and catch exceptions forms the bedrock of the serial Python language. We will review details of how we extended the basic serial exception infrastructure to account for exceptions that may occur across many compute resources.

Our solution is predicated on the notion that parallel managers must take ownership of how serial exceptions are handled across all resources under their control. In other words, unlike in the serial world, the parallel exception handling infrastructure must be customized for each parallel manager.

Decoupling serial components from parallel components

One of the main tenants of the serial software eco-system is the asymptotic parity between the serial compute resources available to the developers and the end-users, which makes possible the easy reporting, reproduction, and resolution of bugs.

With parallel software, this most fundamental of tenants is violated; software engineers need to be able to produce high-quality parallel software in what is an essentially serial environment, yet be able to deploy that software in a parallel environment.

We will describe how SPM.Python addresses this dichotomy by offering easy to relate to parallel primitives. These primitives permit the prototyping, validation, and testing of parallel ideas in the essentially serial development environment, and yet deliver performance when exercised in the parallel environment.

Declaring and defining parallel closures

In SPM.Python, parallel closures are the building blocks of all parallel constructs, and provide the sole means by which one may express how serial components interact with parallel components. The interactions may take place in one of two contexts (a) when creating, submitting, and evaluating tasks, and (b) when creating and processing messages.

However, any usage of a parallel closure within any resource is predicated on a successful, safe, asynchronous and race-free declaration and definition across many compute resources.

We shall describe how SPM.Python solves this fundamental problem by augmenting the traditional concept of serial sequence points.

Conclusion

During the development of SPM.Python, several fundamental problems were solved in order to deliver a scalable parallel version of the serial Python language. At the poster session, the audience will possess an understanding of the technical challenges involved and how they were addressed.