high-performance computing ➤
Some HPC experts such as Kramer believe that there won’t be radical changes to the programming models used for high-end HPC systems, while others including Mark Parsons, executive director of the Edinburgh Parallel Computing Centre at the University of Edinburgh, believe that in order to develop applications for exascale systems the industry must invent new methods, algorithms, and tools. A number of the open-source scientific codes that are being run on NCSA’s Blue Waters petascale system are being updated to cope with the latest high-end HPC technologies, and Kramer is confident that some of these codes can make the transition to exascale systems. But he goes on to say that the programming model needs to become more flexible, and that the compute-synchronise approach needs to change in order to cope with jitter in the system. Tomas Sterling, professor of informatics
and computing at the Indiana University (IU) School of Informatics and Computing, also serves as associate director of the PTI Center for Research in Extreme Scale Technologies (CREST). He believes that, throughout this decade, there will be two approaches to developing applications for exascale systems. On the one hand, many users want to avoid disruption to existing codes and therefore look for ways to evolve
these codes towards exascale. But longer term, Sterling believes that there will be a paradigm shiſt in exascale applications, similar to those seen as vector, SIMD, and cluster systems appeared, requiring a refactoring of algorithms and applications to support dynamic, adaptive behaviours and to improve both efficiency and scaling. Sterling also points out that the TOP500 list (the ‘pop charts’ for supercomputers) has two very distinct regions. Te performance range across the lower 80 per cent of the list
DUE TO THEIR
MASSIVE SIZE, EXASCALE SYSTEMS WILL ALWAYS SUFFER FROM DEGRADED COMPONENTS
is less than a factor of three, while the top 20 per cent has a performance range of almost two orders of magnitude. So while we are looking towards exascale and talking about petascale, most users are still content with terascale applications. Dieter Kranzlmüller is professor
of computer science at the Ludwig- Maximilians-Universität (LMU) Munich and member of the board of the Leibniz Supercomputing Centre (LRZ) of the
Bavarian Academy of Sciences and Humanities. Kranzlmüller reports that the recent Extreme Scaling Workshop concluded that there are many technical issues that still require work, if codes are to be effective at petascale. Hybrid codes (using both MPI and OpenMP) tend to be slower than pure MPI codes, but they can scale better to a large number of cores. Pinning threads to cores (which can be beneficial to performance) can also be a bad idea unless the programmer really knows what he or she is doing, while parallel IO remains a challenge for many applications. Kranzlmüller thinks that more radical approaches such as PGAS languages (partitioned global address space) are worth further investigation. Ramirez of BSC agrees that PGAS languages should be considered to assist fault tolerance and scalability, and to avoid data replication. He goes on to say that, due to their massive size, exascale systems will always suffer from degraded components, and that the performance jitter caused by this mean that the dynamic reallocation of workload is important if high performance is to be maintained. But he sees a huge barrier to the adoption of new technologies such as PGAS. As long as MPI programs continue to work, users will not demand PGAS from vendors, and vendors will not support it. To move to
➤
26 SCIENTIFIC COMPUTING WORLD
@scwmagazine l
www.scientific-computing.com
Creativ000/
Shutterstock.com
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53