Traditional HPC languages, Fortran, C and C++, have little native control over hardware capabilities, such as SIMD operations, multi-core availability and pre-fetch instructions. The burden of optimization is therefore laid upon the expert programmer. He/she must optimize general-purpose library routines with close-to-hardware coding or on the compiler, which tries to automatically arm the high-level code with some knowledge of the hardware architecture.

This all changed last fall, however, with the arrival of a new approach to automatic optimization on computing accelerators via Intel’s Many Integrated Core (MIC) architecture. Unlike GPGPUs, the MIC architecture can be programmed with the standard Fortran, C and C++ languages. It understands common HPC parallel frameworks such as OpenMP and MPI. But most importantly, the new suite knows how to compile Fortran, C or C++ code written by a ”mere mortal” to run on the coprocessor as if optimized by a ”ninja”.

Demonstrated automatic optimization capabilities open doors to scientists and engineers wishing to boost the performance of their general-purpose functions using the MIC architecture. A mathematical function, empirical functional relationship, differential equation solution – all can now be expressed in a high-level language and entrusted to the compiler for optimization.

As a bonus, the implementation of a library function in a high-level language will scale forward to future computing architectures in a blink of an eye. That is, in a swing of the compiler’s ”ninjato”.

Learn More

This automatic optimization capability is outlined in a new paper published by Colfax Research.

You’ll see step by step how to construct a library of special functions and make it offloadable to an Intel Xeon Phi coprocessor. Using a C++ language extension, the authors inform the compiler that certain functions are candidates for automatic vectorization in user applications. Finally, they brush up the high-language code of the function to allow the compiler to do its best with optimization. As a result, their implementation of the Gauss error function performs on par with the highly optimized vendor implementation.

Becoming a better parallel coder can also make you smarter in your professional field, according to Michael D’Mello, Program Manager, Tools Immersion Program at Intel. Increasing mastery of programming tools not only ups your development game, but over time can become “an integral part of your workflow and thought process” that yields new insights. Find out how. Watch the interview here. (12:57)

With today’s powerful new multi-core processors, if you’re not vectorizing – breaking data into chunks – you risk leaving 8x or 16X of Intel Xeon Phi’s theoretical peak power on the table and not scaling code efficiently. The solution, according to Intel’s Ron Green, is for programmers to start look at internal parallelization of processor as well as across processors. Join Ron and Go Parallel Editor Joe Maglitta for a thought-provoking discussion about how you can get the most from today’s powerful new parallel hardware. (11:27)

Key topics

• Growing role of vectorization
• Automatic vectorization
• Intel Parallel Advisor 2013 – What’s New
• Finding hotspots
• Defining race conditions and errors
• Moving away from “high handholding”

Related posts

How Programmers Can Handle the New Hardware Complexity (video)

Identifying and Modeling Parallel Software (video)

Product Information: Intel Parallel Advisor 2013 (product)

New Parallel Programming Guide (book)

New Must Read on Parallel Programming (book)

SPEAKER BIO:

Ronald W. Green
Manager, HPC and Fortran Compiler Support, Intel
Conference: Houston, TX 
Sessions

Identifying and Modeling Parallel Software: Intel® Advisor XE 2013

Ronald specializes in massively parallel software development and systems architectures. He has been active in technical computing and high performance computing since 1987, and has participated in getting three systems into the Top 5 of the HPC TOP500 list over the course of his career. Ronald joined Intel in 2005, and currently manages compiler support from Intel’s Rio Rancho, New Mexico facility. Aside from his management responsibilities, Ronald helps run compiler and tools beta programs, moderates Intel® Software User Forums, contributes to compiler online documentation and samples, and helps with future product definition for Intel® Compiler products. Most recently, he has been assisting with the early test and launch of the compiler products supporting the Intel® Xeon Phi™ coprocessor. He holds an M.S. in computer engineering from the University of Southern California.

High performance computing (HPC) has a long history and today is critical to business, research, and science. Clusters consisting of thousands of machines help enable many advances of modern science with both theoretical and practical implications, working 24/7 to enrich the lives of every person on earth.

This article from the latest issue of Intel Parallel Universe magazine describes ways of better understanding performance analysis of an HPC program using the Intel VTune Amplifier XE Amplifier. The techniques were illustrated using an Intel Xeon Phi coprocessor, but apply equally well to an Intel® Xeon® system. One nice benefit is that tuning to improve the parallelism in your application usually yields performance benefits when running on both Intel Xeon processors and Intel Xeon Phi coprocessors: a double win!

Read the complete article here.

The puzzle is whether a player’s eight chess pieces (excluding pawns) can attack all squares on a chess board, assuming that the two bishops must be on opposite-color squares.  

Some others and I published a serial algorithm for the problem in 1989.  The algorithm relies on an interesting rejection test that quickly rejects large portions of the search space.  It places more than eight pieces on the board at once and checks whether all squares are under attack, ignoring the blocking effects of the pieces.   If not, then any subset of those pieces cannot attack all squares. The opening paragraph is worth reading for Skiena’s sly remark about pruning – we were surprised that editors of an academic journal kept it.

The paper notes that the original program took 75 minutes in 1988 on a Sun 3/360. Machines have gotten much faster since then.  I lost the original code, but was able to rewrite a parallel version from scratch, without the one-level look-head mentioned in the paper.  The parallel version can solve the same problem in less than two seconds on a high-end 16-core machine (a two-socket Intel(R) Xeon(R) Processor E5-2670L).  

Here I will explain the parallelization of the algorithm.  I’ll assume that you have already at least skimmed over sections 2-3 of the paper to understand the serial algorithm.   

The code is attached.  It is a single source file.  I recommend reading it top to bottom.  Two macros affect its behavior:

• Compile with –DPARALLEL=0 to compile as serial code.   
• Compile with -DBISHOPS_CAN_BE_ON_SAME_COLOR=0 to solve the original problem for which I stated times.

Removing the bishop constraint approximately doubles the work.  I made the harder problem  (unconstrained bishops) the default because enables the program to show some solutions,  and modern machines are fast enough to solve it within my patience limit.   

Parallelization

Parallelizing with Cilk Plus requires only minor changes to the serial code.  The following sections explain these changes.

Fork-Join

The algorithm performs recursive divide-and-conquer.  See the paper for details.  Here is the key routine:

 void Search( const Board& b ) {
    if( !b.reject() ) {
        int i = b.chooseAxis();
        if( i<0 ) {
            // Found a weak solution
            ++WeakCount;
            if( b.strongAttacks().isAll() )
                // Found a strong solution
                if( !b.hasSuperposition() )
                    // Found solution with no superposition.  Print it.
                    Output << b << std::endl;
        } else {
            // Unfold on axis i and search both halves in parallel
            cilk_spawn Search( Board(b,i,0) );
            Search( Board(b,i,1) );
        }
    }
    // implicit cilk_sync
} 

Reducers

There is more parallel magic in routine Search than meets the eye.  Note the two lines “++WeakCount;” and “Output << b << std::endl;”.  Both line operate on global variables unprotected by locks.  If I were writing ordinary multithreaded code, these lines would almost surely lead to missing updates to WeakCount and non-deterministic output.  But the program is deterministic because I declared WeakCount and Output as reducers.

Reducers  are Cilk Plus objects for which different threads get different “views”, and the views are automatically merged in a way to deliver the same result as the equivalent serial program.  The views of WeakCount are partial sums that are automatically added together to get the correct total.  The program checks that the total matches the value (8715) reported in the paper (bishops constrained).  The reducer Output acts like a std::ostream, except that it cleverly merges partial output such that the final output is identical to what the serial version of the program prints.

Scaling

The code scales well because it has a lot of parallel slack (excess available parallelism) and is not memory intensive.  If you have Cilk Plus on your system, I invite you to time the serial versus parallel versions of the code.  Here are the recommended command lines for compiling it with the Intel compiler on Linux* or Windows* using the Intel compiler:

The options presume that your compiler paths are set up for using TBB, which I used for its portable wallclock timing facility.  The option -xHost tells the compiler to optimize for the host machine processor .  Using it gained me about a 15% improvement.  Theoretical analysis of the program’s parallel speedup requires two numbers: 

• Work: The total number of instructions executed. 
• Span: The number of instructions on the critical path.

The ratio work/span is a formal measure of parallelism in the program.  For example, if work=span, the parallelism equals one; that is the program is serial.

My program does relatively little work (only 1,832 instructions on average) between fork/join actions, so it is better to use something called “Burdened Span”, which accounts for synchronization overheads.   

Since leaves in the search tree have different depths, estimating the span is a bit tricky.  So I let the Cilk view scalability analyzer (you can get it from the Intel(R) Cilk(TM) Plus SDK at http://www.cilkplus.org/download)  do the work for me.  It reports the following statistics for solving the problem with unconstrained bishops:

   Work :                                162,169,367,032 instructions
   Span :                                58,705 instructions
   Burdened span :                       1,123,705 instructions
   Parallelism :                         2762445.57
   Burdened parallelism :                144316.67
   Number of spawns/syncs:               129,851,246
   Average instructions / strand :       416
   Strands along span :                  43

Summary

Intel Cilk Plus enabled speeding up the puzzle solver with a few changes, and the resulting program scales well and behaves deterministically.

Bio: Arch was the architect of Threading Building Blocks, and was the lead developer for KAI C++. At Shell he worked on seismic imaging on a 256 node nCUBE. He has a Ph.D. in computer science from the University of Illinois. Arch is one of the authors of the book *Structured Parallel Programming: Patterns for Efficient Computation*.

For more information about Intel Cilk Plus, see the website http://cilkplus.org.  

For questions and discussions about Intel Cilk Plus, see the forum http://software.intel.com/en-us/forums/intel-cilk-plus

Download chess-cover.cpp here. 

Join Intel Senior Engineer Gary Carleton and Go Parallel Editor Joe Maglitta for an informative video chat about new challenges facing parallel developers today.

Key issues:  

• How can developers more intelligently architect programs to take advantage of the explosion in hardware capability?
• How can today’s performance analysis and other be used most effectively?
• How can you avoid “parallelism paralysis”?
• Why do we need to rethink the roles of developer and compiler?
• What is “Carleton’s Question”? Why is it important to you?
• How can parallel developers better deal with CPU “hot spots”?

And much more. Tune in, weigh in and check out the tools.

Watch the video to learn more, read the full session abstract and bio, and register here.

Sessions

            Identifying and Modeling Parallel Software: Intel® Advisor XE 2013

            Design: Optimize, Vectorize, and Parallelize—Intel® Composer XE 2013

10:00 – 10:45 a.m.
Identifying and Modeling Parallel Software: Intel® Advisor XE 2013
Abstract: Intel® Advisor XE 2013 is the first tool for novices and experts for adding parallelism to software. In this session, we demonstrate the straightforward Intel Advisor XE workflow. First, the tool surveys or collects performance data and identifies code regions likely to benefit from parallelism. Next, the code is annotated to indicate parallel regions to the Intel Advisor XE analysis utility. Intel Advisor XE will execute the annotated code to model the potential performance gains of running the annotated regions in parallel and report out those potential gains. Finally, Intel Advisor XE models the correctness to identify any potential data conflicts or data races so the developer can choose how to address them. Intel Advisor XE supports C, C++, Fortran, and C#.

11:00 – 11:45 a.m.
Design: Optimize, Vectorize, and Parallelize—Intel® Composer XE 2013
Abstract: Intel® Composer XE 2013 provides the industry’s most advanced optimizing compilers, along with easy-to-use parallel program models and performance libraries designed to extract the maximum performance available from today’s multicore architectures and the new Intel® Many Integrated Core Architecture (Intel® MIC). Intel Composer XE enables programmers of all skill levels to succeed in parallelization and vectorization, the two cornerstones of the multicore revolution. Unlike complex GPU models, parallel programming for multicore Intel® architecture involves straightforward extensions to programmers’ existing skills, making it accessible to everyone. In this presentation, we examine simple extensions to existing C, C++, and Fortran languages to enable parallelization and vectorization.

Ronald W. Green- Manager, HPC and Fortran Compiler Support, Intel

Ronald specializes in massively parallel software development and systems architectures. He has been active in technical computing and high performance computing since 1987, and has participated in getting three systems into the Top 5 of the HPC TOP500 list over the course of his career. Ronald joined Intel in 2005, and currently manages compiler support from Intel’s Rio Rancho, New Mexico facility. Aside from his management responsibilities, Ronald helps run compiler and tools beta programs, moderates Intel® Software User Forums, contributes to compiler online documentation and samples, and helps with future product definition for Intel® Compiler products. Most recently, he has been assisting with the early test and launch of the compiler products supporting the Intel® Xeon Phi™ coprocessor. He holds an M.S. in computer engineering from the University of Southern California.

Decomposing data accesses may allow the compiler to use more advanced features like vector gather and scatter. Though adjacent data elements are preferred in order to maximize the performance advantage of vector loads and stores, sometimes the requirement to access data through indices is unavoidable.  

 Though use of vector gathers and scatters is generally slower than vector loads and stores, they can be beneficial if the amount of vector computation following the creation of the vectors is enough to offset the vector gather time. The compiler will generate vector gathers and scatters as needed, but sometimes it can be challenged by complex data structures. Showing the compiler how to access these complex data structures can help.

Read the rest of the article here.

Download the paper here. (pdf)