The long percolating discussion over ‘co-development’ and how best it should be undertaken has gained new urgency in the race towards exascale computing. At a workshop held at ISC2016 last month – Form Follows Function: Do algorithms and applications challenge or drag behind the hardware evolution? – several distinguished panelists offered varying viewpoints. Yesterday, session organizer Tobias Weinzierl posted a summary synopsis of the workshop discussion on arXiv.org.

Weinzierl (Durham University) and co-organizer Michael Bader (Technische Universität München) are active participants in the ExaHyPE project (An Exascale Hyperbolic PDE (partial differential equation) Engine [1], funded by EU’s Horizon 2020 program). ExaHyPE focuses on the development of new mathematical and algorithmic approaches to exascale systems – initially for simulations in geophysics and astrophysics. During the four-year project, researchers from institutions in Germany, Italy, United Kingdom, and Russia will develop novel software for performing simulations on exascale supercomputers.

Seven European supercomputing projects were invited to the workshop to “share their views on the interplay of hardware and software evolution,” giving the workshop a distinctly European flavor. Among the speakers and organizations represented were:

• Jack Dongarra (The University of Manchester, also University of Tennessee)
• Raphael Leger (INRIA)
• Peter Messmer (NVIDIA)
• Mark Parsons (Edinburgh Parallel Computing Centre)
• Marie-Christine Sawley (Intel)
• Philipp Schlatter (Royal Institute of Technology, KTH)
• Xavier Vigouroux (Atos Bull).

Weinzierl wrote that technology roadmaps are dominated by predictions on hardware. “At the same time, hardware-software co-design is a frequently cited phrase. It suggests that software development can have an impact on the hardware evolution. It can actively shape. The workshop members clarified in their talks to which degree this assumption holds in the context of their projects, what the interaction of hardware and software development looks like and weather the interplay is positive and should be fostered or manipulative and slows down scientific progress?”

He also noted pointedly, “As the workshop invited European projects, this document has a strong European flavour. This is important to keep in mind given that we discuss aspects of co-design—in a business that is dominated by US vendors. Furthermore, almost all invited projects emphasize aspects of simulation software development and integration into classic simulation workflows. We do not really discuss co-design in a co-design setting: all statements on co-design are made from a scientific computing’s software point of view. Last but not least, some statements are on purpose pointed.”

Here’s an excerpt from Weinzierl’s summary report (the report itself is brief and best read in full (link below)):

Running in circles: Does co-design happen (outside co-design projects)?

• “Any discussion on hardware-software/software-hardware influence has to start from a clarification whether such a cycle does exist and what it looks like. The workshop opened with a presentation by Jack Dongarra who sketched such a cycle. LINPACK [3] with its emphasis on vectors fits to a particular type of machine. It was written at a time when it had been important to tackle the thorny fact that floating point operations are expensive. LAPACK [4] anticipates the advent of caches where keeping the floating point units busy gains importance. ScaLAPACK’s [5] design was kicked off by multi-node machines with MPI, while the dusk of BSP triggers the development of Magma [6] and Plasma [7]. The latter are subject of study in the NLAFET project [8]. Mark Parsons gave another example as he outlined how the availability of 3D XPoint non-volatile memory [9] laid the foundations of the NEXTGenIO project [10] 2 studying how to use additional memory layers between main memory and hard disk.

• 

  “While it is easy to follow how hardware development triggers new algorithmic work—our own ExaHyPE [1] project hypothesising that hardware will suffer from severe performance fluctuations is an example for this, too—Jack pointed out that the (Top 500) benchmarks in turn grew downstreamingly into a directing role for the hardware evolution, as they make vendors tune their machines towards these benchmarks; though this has never been the intention behind them in the first place as he emphasised. Other examples for the influence back are the increasing IO demands of today’s software as sketched before, or GPGPU modifications as Peter Messmer illustrated at hands of the Escape project [11]: atomics and double precision would not have made it into GPUs that fast if there had not been a demand of these features from the scientific computing side. After all, machines are procured because of scientific software needs. So while we see software written from scratch around every ten years because of transformative hardware developments, in-between software continuously influences the hardware evolution; mainly by acting as benchmarks or as they escalate bottlenecks.”

Weinzierl wrote, “Most workshop participants were skeptical whether the cycle of influence is a good one the way we experience it right now: It orbits around weaknesses and demands. It is backward looking. Mark articulated that he is worried that the evolution even does not take the well-known Amdahl numbers into account [13]: “I believe strongly in co-design but it happens extremely rarely”.

As noted early, Weinzierl’s summary report is short and best read in full. Here’s a link to the report: http://arxiv.org/pdf/1607.02835v1.pdf

References

[1] www.exahype.eu
[2] www.exascale.org/mediawiki/images/2/20/IESP-roadmap.pdf
[3] www.netlib.org/linpack
[4] www.netlib.org/lapack
[5] www.netlib.org/scalapack
[6] icl.cs.utk.edu/magma
[7] icl.cs.utk.edu/plasma
[8] www.nlafet.eu
[9] www.micron.com/about/emerging-technologies/3d-xpoint-technology
[10] www.nextgenio.eu
[11] www.hpc-escape.eu
[12] www.isc-hpc.com
[13] www.microsoft.com/en-us/research/publication/rules-of-thumb-in-data-engineering
[14] exaflow-project.eu