Skip to main content

On the edge

One of the more difficult aspects of coding stencils or other neighbourhood-based operations is working out what should happen at the edge of the grid. Parallel array languages such as ZPL have expended significant effort to provide mechanism to make coding edge effects easier.

PM handles edge effects by making use of optional data types - containers that can hold either a value (e.g.: an integer) or null. Optional types have many uses, including the representation of unbounded data structures in a pointerless language. A number of operators are defined for optional types, most usefully |.  x|y returns the value contained in x if that value is not null. Otherwise y is returned. 

Binary communicating operators (x@[neighbourhood] or x@{neighbourhood}) always return optionally-typed values, with off-edge cells set to null. Combined with the | operator, this makes dealing with edge-effects straightforward.

The following code fragment demonstrates how PM handles edge effects in practice. It solves the 2D steady-state heat transfer problem for a rectangular box whose four walls are maintained at temperatures boundary1..boundary4. A simple solution to this problem involves repeatedly replacing the temperature in each grid cell with the average of its four immediate neighbours until no further change occurs (Jacobi Iteration).

 for cell in [1..N,1..M] do  
      temp := 0.0  
      repeat   
           newtemp := (  
               temp@[-1, 0]|boundary1  
              +temp@[ 1, 0]|boundary2  
              +temp@[ 0,-1]|boundary3  
              +temp@[ 0, 1]|boundary4  
           )/4.0  
         diff := abs(newtemp-temp)  
         temp = newtemp  
      until max::diff < tolerance  
 endfor

This algorithm is a popular example used for discussing and benchmarking parallel systems. Example code is available online for ZPL, MPI and Chapel (amongst others.)

Comments

Post a Comment

Popular posts from this blog

‘Tis the season

… to give an end-of-year update of what is happening with the PM language. It is a long time now since I wrote a PM blog. However, behind the scenes there has been a lot of work done on the guts of the compiler with new inference and optimisation passes added and others taken apart, polished, and put back together again. New language features have also been implemented, including methods, improved object lifetime management and, most importantly, a radically simplified approach to coding stencils. The handling of stencils was one aspect of PM-0.4 with which I was least happy. Since these are a key requirement for nearly all numerical modelling, I have long been looking for a way to make their coding as straightforward as possible. However, this has been one of the greatest challenges in terms of implementation, since the amount of code restructuring need to make a stencil operate efficiently (separating out halo computation, overlapping computation and halo exchange, tiling and the in...
Post a Comment
Read more

Compile time, run time, coffee time

[ Please note that in the following discussion I will be using PM 0.5 notation, which is slightly different to PM 0.4 and also in some flux as PM 0.5 is still in development. ]   Many programming languages (and most newly developed ones) include some form of compile-time programming, ranging from simple preprocessors ( #define , #if in C) to fully blown macro systems capable of re-writing the abstract syntax tree during compilation (Rust, Julia, etc .). In line with its philosophy of keeping things as simple as possible, but not simpler, PM takes a middle road with compile-time programming supported primarily through the type system. There is nothing too radical here – this is not an area where the language aims to break new ground.  The PM approach centres around the use of compile-time types. Many languages use special types to denote literal values and PM follows this trend. Literal integers, reals, strings and Booleans each have their own types: literal(int) , litera...
Post a Comment
Read more

WYSIWYG

PM was in part inspired by ZPL , a parallel array language. One of the key goals of the ZPL project was to provide a “What You See Is What You Get” (WYSIWYG) approach to parallel communication – in particular as this related to communication overhead. This was achieved using a range of operators that explicitly invoke parallel communication on distributed arrays. For example, the @ operator moves the elements of an array by a fixed displacement while the # operator provides for more general element permutation. A programmer would know that the former operation is much less expensive than the latter. To shift a distributed array by a fixed displacement, computational nodes only need to exchange information for edge cells that have moved into the region governed by a different node. However, general permutation requires all nodes to request and then receive data from arbitrary other nodes and for this exchange to be globally synchronized. The ZPL # operator thus needs avoiding unless ...
Post a Comment
Read more