OpenMP Compared to SequenceL
The Problem with OpenMP and Directive Pragmas
OpenMP has been the most common approach Computer Scientists use to manually specify parallelisms in their code to run on multicore processors. To use OpenMP, the programmer must first analyze their code to identify areas of possible – and safe – parallel execution, then manually instruct the compiler (by adding OpenMP pragma directives) to implement them. To do this takes a lot of time, deep analysis, and testing, testing, and more testing to ensure accurate results in all cases. Even the best programmer can get it wrong, in the best case only achieving minimal speedup, or in the worst case creating dangerous race conditions.
While it is technically free to use OpenMP, in practice users typically spend a lot of money on various “point tools” to help identify areas in their code to possibly add directives, aid in debugging, evaluate performance, etc.
The significant problems we face cannot be solved using the same level of thinking we used when we created them.Albert Einstein
Example: OpenMP Compared to SequenceL
This simple example illustrates some of the problems with manual directive approaches and highlights how much easier, safer, and powerful the automated SequenceL approach is. Importantly, with SequenceL the code remains easy to read and write, making subsequent enhancements even faster. An added benefit is SequenceL can also output OpenCL, averting the need to learn and incorporate low-level OpenCL or CUDA code and associated scaffolding to exploit systems with (GP)GPUs.
This block of code defines the 3-body gravitational simulation.
What to parallelize?
Using directive-based approaches like OpenMP, the burden is on the programmer to identify where the program can be safely parallelized. In this simple example, each body can be calculated at the same time to give in theory a 3x speedup.
How to parallelize?
Programmer must then add correct pragmas
But maybe you could parallelize other things…
The grav function may (or may not!) be able to execute independently…
Code Complexity Increasing, Code Intent Lost
Now you have to start re-arranging the code, moving further away from the original description of the algorithm.
Possible Race Conditions!
If the grav function modifies its inputs or calls non thread-safe functions, there could be hard to detect race conditions, leading to incorrect results. This is one of the hardest things to test for in parallel software engineering.
SequenceL: Self-Parallelizes, Race-Free, Readable
With SequenceL, the programmer simply describes the algorithm in “engineering terms” so code clarity and intent remain. The program will self-parallelize when compiled if safe to do so. It will also use Vector (SIMD) instructions where possible, all with no input from the programmer. SequenceL is provably race-free, addressing the top quality issue in parallel software engineering.
With SequenceL the programmer does not add any parallel constructs or pragmas, nor even think about writing parallel code or substituting library calls. This makes it much easier and 10X faster to write, while greatly improving correctness and quality; subsequent enhancements are even more rapid. This ease of reading/writing is by design, due to SequenceL’s origins as an executable specification language for NASA.