Want to be the first one on your block to have a program running on Intel’s new Xeon Phi coprocessor. There’s a good in-depth article and how to go about this over at Dr. Dobb’s Journal. Author Rob Farber goes through the different programming models available to would-be Phi developers and how to squeeze out the maximum performance

Farber points out the Phi is essentially an x86 manycore SMP processor and supports the various parallel programming models — OpenMP and MPI, in particular. That means that most applications can get up and running with a recompilation, using Intel’s own developer toolset.

But according to a previous analysis by Farber, the limited memory capacity on the devices will limit performance for typical OpenMP and MPI applications. According to him, to get performance out of the hardware, you need to make sure you are taking advantage of coprocessor’s many cores and its muscular vector unit. “Massive vector parallelism is the path to realize that high performance,” writes Farber.

Although there are 60 cores available on the Phi hardware Dr Dobb’s obtained (a pre-production part, apparently), four-way hyperthreading allows for up to 240 threads per chip. During testing it was determined that the application should have at least half of the available threads in use. It is tempting to think that non-vector codes could also benefit from the Xeon Phi, powered by thread parallelism alone, but Farber thinks that such applications will not be performance standouts on this platform.

Since the Phi is a PCIe device with just a few gigabyte of memory, it’s also important to minimize data transfer back and forth between the CPU’s main memory and local store on the coprocessor card. That means doing as little data shuffling as possible and making sure the coprocessor has enough contiguous work to do using local memory. In fact, Farber maintains the a lot of the design effort to boost performance on the Phi will revolve around minimizing data transfers.

The article goes through an example of an OpenMP-based matrix code using the various programming models — native (entire app runs on the Xeon Phi), offload (the host CPU runs the app; the compute intensive parts are offloaded), and host (the CPU does it all) — and provides the performance results in each case.

In this case, the native model delivered the best performance, but not all that much better than the offload model. The host model was significantly slower — on the order of 50 percent. Real applications though, with more complex data transfer requirements, are apt to be behave differently.

In any case, if you aspire to be a Phi developer, the whole article is worth a read.