SIMD Parallelism using Array Notation

Are you a C or C++ programmer who has ever envied APL or Fortran 90's array expressions? Read on. If you don't know what array expressions are, then you really should read on, to find out what you should have envied. In any case, the envy is over, because Intel Parallel Composer 2011 brings array expressions to C and C++.

Background

A while back I wrote about the Three Layer Cake pattern for parallel programming. The pattern is a way of organizing programs to fully exploit modern multi-core chips. Two of the layers are:

fork-join: harnesses multiple hardware threads.

SIMD: harnesses SIMD instructions.

The compiler in Intel Parallel Composer 2011 extends C++ to directly support these two layers. The extensions are called Intel® Cilk Plus. They are:

Cilk notation for specifying fork-join parallelism.

Array notation for specifying SIMD parallelism.

This blog introduces the array notation, with a Seismic Duck kernel as the example. I'll introduce Cilk notation in another blog. The two notations are independent. Indeed, the array notation is valuable with other threading packages too, such as Threading Building Blocks, or just for writing faster serial code.

Quick Introduction to Array Notation

The array notation extension is reminiscent of APL and Fortran-90 style array expressions. The expression:

a[index:count]

denotes an array section starting at index with count elements. Scalar operations can be used on conformable array sections in an intuitive manner. Operations between scalars and array sections work too; scalar extende in the obvious way (like in APL or Fortran 90). Examples:

Section notation also permits expressions of the form array[index:count:stride], reductions, and shorthands that I will not into here. I'm presenting just enough to pique your interest. To learn more about it, follow this link to the compiler documentation.

Example

I've described in other blogs how seismic wave propagation in Seismic Duck depends on updating a "tile", a small subarray that fits in cache. Here is the scalar code that dominates execution time. It updates a tile with uniform A and B coefficients:

To improve the speed on compilers that did not automatically generate SIMD code from the scalar loops, I wrote the key loops with SSE intrinsics, so that calculations are done four wide instead of one at a time. The resulting code looks like this:

The downside of the change is obvious - it's hard to read. And this was a simple case because logic elsewhere guarantees that jLast-jFirst is a multiple of 4. Otherwise, dealing with the extra iterations would have further obfuscated the code.

For this particular example, explicit SSE intrinsics are not actually necessary with a compiler that automatically vectorizes (convert to SIMD instructions). Indeed, recent compilers that I tried seem to be able to do so. (Though one older compiler from 2008 did not.) But I was careful to cater to the optimizer. I declared the arrays Vx, Vy, and U as static file-scope arrays in the source code, not pointers. That's not trendy OO programming, but it lets the compiler easily prove absence of aliasing, and thus absence of loop carried dependences that could thwart vectorization. It's not always practical to cater this way to the optimizer. Furthermore, array notation has its own elegance. So I'll use the kernel as a running example anyway.

The array notation in Intel® Cilk Plus lets me state my intent ("SIMD parallelism!") to the compiler more bluntly. Below is an array notation version of the example:

The array notation has let me clearly convey the parallel nature of the updates. I had to add the setup of i, j, m, n. But that's an accident of history. Elsewhere the code computes { iFirst, iLast, jFirst, jLast} from the equivalent of {i, j, m, n} because the former simplified writing the C++ for loops. If I adapt the rest of the code to use array notation, then { iFirst, iLast, jFirst, jLast} will disappear and {i,j,m,n} will be setup in their place.

Of course I'm still depending on a clever optimizer to eliminate the temporary subarrays. For example, the subexpression:

a*(U[i:m][j+1:n]-U[i:m][j:n]);

conceptually generates two temporary array sections, for the results of - and *. In practice, the Intel compiler is good at eliminating those temporaries. (It's had years of practice doing so for Fortran 90.) But even if some temporary sections remained, the parallelism is still clear. The compiler does not have to deduce parallelism from dependence analysis of serial for loops.

Concise notation is nice, but how about the performance? When compiled by the Intel compiler and run on the Core-2 Quad system in my office, the array notation variant performed faster than my hand-coded SSE. [Your mileage may vary. See optimization disclaimer here.] I dug through the object code to figure out why. It turns out that updating Vx, Vy, and U in separate loops does better than with a single loop. I found out that the hand-coded SSE does as well if changed to use separate loops to update the three arrays. Anyway, I'm happy that the array notation matches the best that I can do by hand for this example.

Summary

The array notation is a concise way to express SIMD parallelism. I'm hoping it catches on with other compilers. In another blog I'll introduce the application of Cilk fork-join parallelism to Seismic Duck.