[Originally posted on The NAG Blog]
It’s a question that absorbs the attention of the technical computing community, especially those working at the leading edge of technology and performance (high performance computing, HPC). What is the next disruptive technology? In other words, what is the next technology that will replace a currently dominant technology? Usually a disruptive technology presents a step-change in performance, cost or ease-of use (or a combination of these) compared to the established technology. The new technology may or may not be disruptive in the sense of discontinuous change in user experience.
Why is identifying disruptive technology so important? First, those who spot the right change early enough and deploy it effectively can attain a significant advantage over competitors as a result of a substantial improvement in technical computing capability or reduction in cost. Second, identifying the right technology change in time can help ensure that future investments (whether software engineering, procurement planning, or HPC product development) are optimally spent.
However, in a field as fast moving as technical computing, spotting the next disruptive technologies of specific relevance to your individual needs can easily become a full time activity (which is why NAG helps to do this for others).
One very credible candidate for disruptive change in HPC right now is GPU computing (or related products that might be in development). However, at the Newport conference recently, the discussion turned to what the next disruptive technology to hit HPC would be (after the possible GPU disruption). One suggestion, made by John West (of InsideHPC fame), was that the next disruptive technology could be in software, especially programming tools and interfaces. This builds on the fact that parallel computing is no longer a specialist activity unique to the HPC crowd – parallel processors are becoming pervasive across all areas of computing from embedded to personal to workgroup technical computing. Parallel programming is thus heading towards a mass market activity – and the mass market is unlikely to view what we have in HPC currently (Fortran plus MPI and/or OpenMP, or limited tools, etc) with much favour. I’m not knocking any of these, but they are not mass-market interfaces to parallel computing. So perhaps the mass market, through volume of people in need – and companies driven by economics will come up with a “better” solution for interfacing with supercomputers.
As a HPC community we lost control of much of our hardware to the commodity market some years ago. Maybe we now face losing control of our software to the commodity community too.
The hpcnotes HPC blog - supercomputing, HPC, high performance computing, cloud, e-infrastructure, scientific computing, exascale, parallel programming services, software, big data, multicore, manycore, Phi, GPU, HPC events, opinion, ...
Showing posts with label software. Show all posts
Showing posts with label software. Show all posts
Tuesday, 23 March 2010
Thursday, 18 February 2010
Exascale or personal HPC?
[Originally posted on The NAG Blog]
Which is more interesting for HPC watchers - the ambition of exaflops or personal supercomputing? Anyone who answers "personal supercomputing" is probably not being honest (I welcome challenges!). How many people find watching cars on the local road more interesting than F1 racing? Or think local delivery vans more fascinating than the space shuttle? Of course, everyday cars and local delivery vans are more important for most people than F1 and the space shuttle. And so personal supercomputing is more important than exaflops for most people.
High performance computing at an individual or small group scale directly impacts a far broader set of researchers and business users than exaflops will (at least for the next decade or two). Of course, in the same way that F1 and the shuttle pioneer technologies that improve cars and other everyday products, so the exaflops ambition (and the petaflops race before it) will pioneer technologies that make individual scale HPC better.
One potential benefit to widespread technical computing that some are hoping for is an evolution in programming. It is almost certain that the software challenges of an exaflops supercomputer with a complex distributed processing and memory hierarchy demanding billion-way concurrency will be the critical factor to success and thus tools and language evolutions will be developed to help the task.
Languages might be extended (more likely than new languages) to help express parallelism better. Better may mean easier or with assured correctness rather than higher performance. Language implementations might evolve to better support robustness in the face of potential errors. Successful exascale applications might expect to make much greater use of solver and utility libraries optimized for specific supercomputers. Indeed one outlying idea is that libraries might evolve to become part of the computer system rather than part of the application. Developments like these should also help to make the task of programming personal scale high performance computing much easier, reducing the expertise required to get acceptable performance from a system using tens of cores or GPUs.
Of course, while we wait for the exascale benefits to trickle down, getting applications to achieve reasonable performance across many cores still requires specialist skills.
Which is more interesting for HPC watchers - the ambition of exaflops or personal supercomputing? Anyone who answers "personal supercomputing" is probably not being honest (I welcome challenges!). How many people find watching cars on the local road more interesting than F1 racing? Or think local delivery vans more fascinating than the space shuttle? Of course, everyday cars and local delivery vans are more important for most people than F1 and the space shuttle. And so personal supercomputing is more important than exaflops for most people.
High performance computing at an individual or small group scale directly impacts a far broader set of researchers and business users than exaflops will (at least for the next decade or two). Of course, in the same way that F1 and the shuttle pioneer technologies that improve cars and other everyday products, so the exaflops ambition (and the petaflops race before it) will pioneer technologies that make individual scale HPC better.
One potential benefit to widespread technical computing that some are hoping for is an evolution in programming. It is almost certain that the software challenges of an exaflops supercomputer with a complex distributed processing and memory hierarchy demanding billion-way concurrency will be the critical factor to success and thus tools and language evolutions will be developed to help the task.
Languages might be extended (more likely than new languages) to help express parallelism better. Better may mean easier or with assured correctness rather than higher performance. Language implementations might evolve to better support robustness in the face of potential errors. Successful exascale applications might expect to make much greater use of solver and utility libraries optimized for specific supercomputers. Indeed one outlying idea is that libraries might evolve to become part of the computer system rather than part of the application. Developments like these should also help to make the task of programming personal scale high performance computing much easier, reducing the expertise required to get acceptable performance from a system using tens of cores or GPUs.
Of course, while we wait for the exascale benefits to trickle down, getting applications to achieve reasonable performance across many cores still requires specialist skills.
Labels:
exascale,
hpc,
NAG,
personal supercomputing,
productivity,
software,
supercomputing
Thursday, 4 February 2010
Don't call it High Performance Computing?
[Originally posted on The NAG Blog]
Having just signed up for twitter (HPCnotes), I've realised that the space I previously had to get my point across was nothing short of luxurious (e.g. my ZDNet columns). It's like the traditional challenge of the elevator pitch - can you make your point about High Performance Computing (HPC) in the 140 character limit of a tweet? It might even be a challenge to state what HPC is in 140 characters. Can we sum up our profession that simply? To a non-HPC person?
The inspired John West of InsideHPC fame wrote about the need to explain HPC some time ago in HPCwire. It's not an abstract problem. As multicore processors (whether CPUs or GPUs) become the default for scientific computing, the parallel programming technologies and methods of HPC are becoming important for all numercial computing users - even if they don't identify themselves as HPC users. In turn, of course, HPC benefits in sustainability and usability from the mass market use of parallel programming skills and technologies.
I'll try to put it in 140 characters (less space for a link): Multicore CPUs promise extra performance but software must be optimised to take advantage. HPC methods can help.
It's not good - can you say it better? Add a comment to this blog post to try ...
For those of you finding this blog post from the short catch line above, hoping to find the answer to how HPC methods can help - well that's what my future posts and those of my colleagues here will address.
Having just signed up for twitter (HPCnotes), I've realised that the space I previously had to get my point across was nothing short of luxurious (e.g. my ZDNet columns). It's like the traditional challenge of the elevator pitch - can you make your point about High Performance Computing (HPC) in the 140 character limit of a tweet? It might even be a challenge to state what HPC is in 140 characters. Can we sum up our profession that simply? To a non-HPC person?
The inspired John West of InsideHPC fame wrote about the need to explain HPC some time ago in HPCwire. It's not an abstract problem. As multicore processors (whether CPUs or GPUs) become the default for scientific computing, the parallel programming technologies and methods of HPC are becoming important for all numercial computing users - even if they don't identify themselves as HPC users. In turn, of course, HPC benefits in sustainability and usability from the mass market use of parallel programming skills and technologies.
I'll try to put it in 140 characters (less space for a link): Multicore CPUs promise extra performance but software must be optimised to take advantage. HPC methods can help.
It's not good - can you say it better? Add a comment to this blog post to try ...
For those of you finding this blog post from the short catch line above, hoping to find the answer to how HPC methods can help - well that's what my future posts and those of my colleagues here will address.
Thursday, 28 January 2010
Are we taking supercomputing code seriously?
[Article by me on ZDNet UK, 28 January, 2010]
The supercomputing programs behind so much science and research are written by people who are not software pros ...
http://www.zdnet.co.uk/news/it-strategy/2010/01/28/are-we-taking-supercomputing-code-seriously-40004192/
The supercomputing programs behind so much science and research are written by people who are not software pros ...
http://www.zdnet.co.uk/news/it-strategy/2010/01/28/are-we-taking-supercomputing-code-seriously-40004192/
Thursday, 12 November 2009
Tough choices for supercomputing's legacy apps
[Article by me on ZDNet UK, 12 November, 2009]
The prospect of hundreds of petaflops and exascale computing raises tricky issues for legacy apps ...
http://www.zdnet.co.uk/news/it-strategy/2009/11/12/tough-choices-for-supercomputings-legacy-apps-39869521/
The prospect of hundreds of petaflops and exascale computing raises tricky issues for legacy apps ...
http://www.zdnet.co.uk/news/it-strategy/2009/11/12/tough-choices-for-supercomputings-legacy-apps-39869521/
Labels:
exascale,
hpc,
leadership,
manycore,
parallel programming,
software,
strategy,
supercomputing,
ZDNetUK
Thursday, 1 October 2009
Should programming supercomputers be hard?
[Article by me on ZDNet UK, 1 October, 2009]
Those who glibly argue for easier programming of supercomputers are broaching a complex issue ...
http://www.zdnet.co.uk/news/it-strategy/2009/10/01/should-programming-supercomputers-be-hard-39763731/
Those who glibly argue for easier programming of supercomputers are broaching a complex issue ...
http://www.zdnet.co.uk/news/it-strategy/2009/10/01/should-programming-supercomputers-be-hard-39763731/
Friday, 20 March 2009
Are supercomputers just better liars?
[Article by me on ZDNet UK, 20 March, 2009]
Supercomputers may be far more powerful than ordinary machines, but that does not make their predictions infallible ...
http://www.zdnet.co.uk/news/it-strategy/2009/03/20/are-supercomputers-just-better-liars-39629474/
Supercomputers may be far more powerful than ordinary machines, but that does not make their predictions infallible ...
http://www.zdnet.co.uk/news/it-strategy/2009/03/20/are-supercomputers-just-better-liars-39629474/
Labels:
hpc,
risk,
software,
supercomputing,
ZDNetUK
Friday, 31 October 2008
Is supercomputing just about performance?
[Article by me on ZDNet UK, 31 October, 2008]
You may think you know what 'HPC' stands for — but conflicting views on what that 'P' really stands for reflect important changes taking place within the field of supercomputing ...
http://www.zdnet.co.uk/news/servers/2008/10/30/is-supercomputing-just-about-performance-39534285/
You may think you know what 'HPC' stands for — but conflicting views on what that 'P' really stands for reflect important changes taking place within the field of supercomputing ...
http://www.zdnet.co.uk/news/servers/2008/10/30/is-supercomputing-just-about-performance-39534285/
Labels:
hpc,
performance,
productivity,
software,
ZDNetUK
Thursday, 14 August 2008
NAG Embarks on a New Business Venture
[Interview with me in HPCwire, August 14, 2008]
by John E. West, for HPCwire
... responding to changes in computing at both ends of the spectrum, [NAG] is positioning itself as the place to go, not just for shrink-wrapped libraries, but also for education and expertise in how to program in parallel, and even for expert advice on how to buy, build and run your own supercomputer. HPCwire talked to Andrew Jones, vice-president of HPC business at NAG, on what he has in mind for this new business and how he sees the future of HPC and parallel programming shaping up ...
http://www.hpcwire.com/features/NAG_Embarks_on_a_New_Business_Venture.html?viewAll=y
by John E. West, for HPCwire
... responding to changes in computing at both ends of the spectrum, [NAG] is positioning itself as the place to go, not just for shrink-wrapped libraries, but also for education and expertise in how to program in parallel, and even for expert advice on how to buy, build and run your own supercomputer. HPCwire talked to Andrew Jones, vice-president of HPC business at NAG, on what he has in mind for this new business and how he sees the future of HPC and parallel programming shaping up ...
http://www.hpcwire.com/features/NAG_Embarks_on_a_New_Business_Venture.html?viewAll=y
Labels:
hpc,
HPCwire,
interview,
John West,
multicore,
NAG,
parallel programming,
procurement,
productivity,
software,
strategy,
supercomputing
Subscribe to:
Posts (Atom)