HIGH PERFORMANCE COMPUTING


getting more efficiency out of the hardware”


g


in one basket, all the difficult things, and then you are left with something that is much more efficient,’ Kaxiras added. Kaxiras, a professor at Uppsala University, explained initial attempts aimed at using dynamic voltage and frequency scaling (DVFS) to optimise energy efficiency. ‘The problem with DVFS is that if you change the voltage frequency for your program, you could gain some efficiency, but then you would lose performance,’ said Kaxiras. ‘The idea with decoupled


access-execute is why don’t we move all the accesses into one big phase that is entirely memory bound and move compute to an execute phase, which then becomes CPU bound. If these phases are big enough, you change the voltage and frequency on each one of these phases separately.’ The research initially


explored running these phases on different cores, but the team has now moved to investigate the use of accelerators. ‘The talk I gave highlights the


realisation that this Decoupled Access-Execute ties very well with accelerators. If you can successfully decouple all of this difficult code, then essentially your compute code becomes just a pure dataflow


calculation that you can map on to vector units or custom accelerators or anything else you can think of,’ concluded Kaxiras.


Diversifying the HPC ecosystem At the end of the first day of the conference, Arm and some of its partners in the HPC market took to the stage for the HPC panel session to discuss HPC software and hardware differentiation and the company’s direction for exascale.


The initial discussion


between the panel focused on the pursuit of exascale in the face of Moore’s Law. As we approach the material limits of transistor design, future developments are becoming increasingly complex and expensive, and this means that Moore’s law may no longer hold to the same timeframe as previous years. Scott Hara, director of


product management HPC solutions at Qualcomm, opened proceedings with his comment that he did not think a lot would change as we approach exascale. ‘Early on, performance was driven by the processor node but I do not think we have seen a strong correlation between performance and process since the 1990s.’ ‘I think our performance


14 Scientific Computing World October/November 2017


”There will be more emphasis placed on


increases have happened through architectural advances or changes and I feel that this is how we are going to get from where we are today to exascale in 2020 to 2024,’ continued Hara. ‘I also don’t think our transistor budget will change very much and that puts a burden on our architecture teams to put in place the features needed to accelerate, in a performant and power efficient way, the important codes that we have to run on these large-scale systems.’ Kevin Pedretti, principal member of technical staff for scalable system software at Sandia National Laboratories, agreed that architectural advances would be key to future development: ‘To a large degree I think that is right, leading up to exascale I think we are on a path and it looks like we will get there, but, longer-term, it’s clear that our exponential increases cannot go on forever. ‘In the past, we have had kind of a free lunch with Moore’s Law performance increasing for free and that has been tailing off recently and will continue to tail off. I think that is going to make architecture more important. ‘I also think that there will


be more emphasis placed on getting more efficiency out of the hardware. Both application developers spending more time trying to expose the parallelism and also in intelligent runtime systems and even operating systems to automatically – or try as best it can – to map the application’s parallelism to what is available in the hardware.’ Jon Masters, chief


Arm architect at Red Hat, commented: ‘The problem that we have had is that computing has been more or less cheap, especially from a software point of view. We have been able to get lazy over the past couple of decades. If you talk to programmers these days, they are abstracted from how machines work – we have been very fortunate.’ Masters pointed out that,


as Moore’s law comes to an end, the HPC industry needs to care a lot more about the underlying hardware. ‘That is good. I come from


a software company, now traditionally we sit in one box and the hardware guys sit in a different box and we never talk to each other. I am a big fan of not doing that and working together. I think we have an opportunity here to right some wrongs from the past couple of decades and come together to solve problems in an innovative way.’ Eric Van Hensbergen,


director of HPC at Arm, highlighted the need for HPC companies to work together to overcome the challenges of exascale, but also to help bring diversity and competition to the HPC hardware stack: ‘Intel has made a game out of building this vertical stack that is all them. Memory, software, storage they are becoming an old-style system integrator in that they build everything. My job of getting Arm into HPC has been easy, because almost no one wants that. Everyone wants an open field


”We purposefully stay out of certain areas to allow our partners to innovate”


with lots of competition and diversity, because we all need something a bit different.’ Hensbergen continued:


‘The Arm ecosystem is the opposite end of the spectrum. We purposefully stay out of certain areas to allow our partners to innovate. We do not acquire them and then acquire their competition and combine them to remove diversity. We are here to enable diversity, because it is core to our business model. ‘You can still compete with each other but we will create the ecosystem and the diversity and the customers can see the value in that.’


@scwmagazine | www.scientific-computing.com


Designmaestro/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