search.noResults

search.searching

saml.title
dataCollection.invalidEmail
note.createNoteMessage

search.noResults

search.searching

orderForm.title

orderForm.productCode
orderForm.description
orderForm.quantity
orderForm.itemPrice
orderForm.price
orderForm.totalPrice
orderForm.deliveryDetails.billingAddress
orderForm.deliveryDetails.deliveryAddress
orderForm.noItems
HIGH PERFORMANCE COMPUTING


project deputy director for the US Exascale Computing Project (ECP), discussed the work going on in the US to prepare for the first wave of exascale-class machines. Diachin also discussed some of the challenges that the ECP face in delivering three exascale systems for the US national labs. ‘The Exascale computing project has


three primary technical focus areas. The first is application development. In this area we have selected 26 design centres, which are focused on the computational motifs that many applications can take advantage of. So, for example, adaptive mesh refinement type kernels, high order discretisation kernels, particle methods, and so on,’ said Diachin. ‘The second major technical area is


software technologies. In this area, we are working very hard to develop an integrated software stack, so that applications can achieve their full potential on the exascale computing platforms. ‘We have 71 different products that are


focused on runtime systems, programming models, math libraries, data visualisation tools and the software ecosystem writ large.’ ‘Finally we have our hardware and


integration area, which is focused on the delivery of our products on the DOE facilities. ‘It’s also been focused on partnerships with six of the US HPC vendors to look at the research and development that was needed for excess scale nodes and system design,’ added Diachin.


Specialised challenges Whereas Fugaku was designed around CPU-only hardware to ensure the general purpose nature of its applications suite, the US exascale systems rely on large numbers of GPU’s to deliver performance. This has thrown up some additional challenges for the ECP – not only because they must cater for GPU technology but because there are several vendors and competing technologies that are being used in the various US exascale systems. The three systems will eventually use GPUs from Nvidia, AMD and Intel and this means that the ECP has to optimise for all three technologies.


‘One of the things that’s very interesting,


in these systems and that’s really been driving a lot of the work within the ECP is the fact that the accelerator node architectures that the United States has been focused on is changing from being an Nvidia only ecosystem to an ecosystem that has a wider variety of GPUs, in particular the exascale systems will have AMD, Intel GPUs … and that’s driving a lot of our work for performance portability,’ explained Diachin. ‘In our application portfolio we have


some 24 applications that were chosen because they were of strategic importance to the Department of Energy,’ Diachin continued. ‘They range in topics from national


security applications such as next generation stockpile stewardship codes to energy and economic security scientific discovery, Earth System modelling and


“To put Fugaku in context, it is equivalent to about 20 million smartphones that run the same code”


healthcare in partnership with the National Institute of Health (NIH).’ ‘With these 24 applications in the six


co design projects we have more than 50 separate codes that have over 10 million lines of code collectively. When the project began many of these codes were focused on MPI or MPI plus open MP and were largely focused on CPU with, with a small number of them starting their work with GPU accelerated computing. So since the beginning of the project in 2016, each code has had to develop a unique plan to make progress toward deployment on the excess scale systems. Moving away from CPU only implementations to performance portable GPU implementations.’ ‘When we talk about preparing


applications for the exascale systems. There is a hierarchy of adaptations that have needed to happen, so what do we need to do at the lowest levels to rewrite and optimise our codes,’ states Diachin. ‘There’s been a lot of data layout that has been done, loop reordering, kernel flattening, and so on. ‘It’s really focused on those lower level


operations that can really improve the performance in different kernels of the application.’ .


18 Scientific Computing World Summer 2021


@scwmagazine | www.scientific-computing.com


Larich/shutterstock


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