Dr. Dobb's Journal - June 2008 - (Page 46)

d06keas_p4ds 4/10/08 1:53 PM Page 46 State of the Art PERFORMANCE PORTABLE C++ continued from page 44 mnemonic, then it is almost like having a namespace for your array data. It is more refactorable because you can move data around within the class, and the class API won’t change, so your code won’t have to change. The first choice has the disadvantage that it is hard to instantiate multiple copies of the object without incurring a huge fixed overhead of memory and class construction time. For instance, if you have 800 arrays in a class implemented using STL vectors, then you are going to pay the penalty of instantiating all the vectors, even if you are Figure 7: Point class/Brick class. cloning the class just for a few of the vectors it contains. Construction/Initialization can also be a problem, especially for subsets of arrays. The second choice has the advantage of extreme flexibility. You can group just a few arrays that are often used together in a class, examples being coordinate vectors or velocity vectors. This is optimal when you want to construct/destruct a lot of temporary objects throughout your run. Small classes are also easier to tune for performance portability. The disadvantage can be reduced readability because almost every variable will effectively have a different namespace prefix. It’s not always fun to write that kind of code, or read it in equations. The readability issue can be mitigated by pulling data out into local temporaries before use, but that can cause code bloat, not to mention the introduction of errors due to cut-and-paste code and typos. Another drawback of many small classes is that if you want to refactor your code, say by moving an array from one class to another, that change will often require changes throughout your code. Now that I’ve covered the advantages/disadvantages of the two extremes, I look at a third choice, which is to group data having similar “topological” characteristics. An indication that arrays may be topologically similar is that they probably have the same length. For example, when working with physics on meshes, velocity components are often defined at the coordinates, so perhaps coordinates and velocities should be encapsulated in the same class. In contrast, particle data may contain coordinates, but you wouldn’t want to necessarily group particle coordinates with mesh coordinates because particles have a completely different function. Particles can move independently from mesh coordinates, and they will probably be created and destroyed more often. Next-Generation Performance Portability TO TAKE FULL advantage of multicore, NUMA, and heterogeneous technologies, lots of code will likely need to be rewritten, especially in the High Performance Computing (HPC) arena. To mitigate the impact of this shift to new architectures, I’m investigating the use of source-to-source translation as a possible salvation. I’ve used a sophisticated tool called ROSE (www.roseCompiler.org) to write a Tiny C language extension that implements the techniques in this article in a way that is transparent to users. All the drawbacks I mention in the article go away, and new features emerge, especially with respect to multidimensional arrays. Users create a single schema file describing the struct/array grouping of array names used within a code. The compiler can then use the schema to generate structs or arrays as appropriate at compile time. The groupings can be hierarchical, thus subtle relationships among groups of arrays can easily be captured. I plan to investigate generating RapidMind, Intel’s Threaded Building Block, or other backend code to complement the performance portable language extension. My hope is that source translation combined with a vector-like language extension might let the power of next-generation architectures be exploited with a minimal amount of effort devoted to code rewrites. —J.K. 46 Dr. Dobb’s Journal l www.ddj.com l June 2008 http://www.roseCompiler.org http://www.entrek.com http://www.entrek.com http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - June 2008

Dr. Dobb's Journal - June 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries There Must Be Contest Conversations Building a Test Harness for RTOS QT and Windows CE Software to Hardware Parallelization Performance Portable C++ Effective Concurrency The Agile Edge Swaine's Flames

Dr. Dobb's Journal - June 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.