U.S. To Build Two Flagship Supercomputers for National Labs
nvidianews.nvidia.com
nvidianews.nvidia.com
At LLNL it was constant, and everyone I interacted with had something to say about being at or near the #1 spot in the top 500 list (with Sequoia at the time), and advice on projects to try and get time. I went on a tour of the facility too, and it was really neat to get some perspective on the physical aspects of it all.
I've been at ORNL since February, and haven't heard Titan mentioned once. Partially I think this is due to the more cohesive overall mission of LLNL vs. ORNL, but I think geography plays a role as well.
The labs have fairly similar numbers of employees, but with one major difference; ORNL is spread out over a pretty large area and LLNL is a single square mile. Perhaps as a result of that, groups at ORNL feel a bit more insular. Heck, I've been to the "main" cafeteria once here, because I work on an edge of the campus, but at LLNL I went every day because it was easy to get to.
I wonder if a more compressed area results in a more useful utilization of huge assets like HPC because there are a lot more connections to be made between different departments. Then again, I also got the feeling that at LLNL it was a carrot they could try and dangle to draw people out of the valley. ORNL doesn't really have that same local competition for talent.
EDIT: And the article even specifically mentions the difference in lab missions by noting the new computers' uses: security vs. open science.
[1]http://books.google.com/books/about/To_the_End_of_the_Solar_...
For example, the National Ignition Facility (the warp core in Into Darkness) was created partly too provide a source of fusion that could be used to verify the computer models used to simulate nuclear weapon stability. Ie, write a general enough model to see what happens in the fusion bit of a nuke, then apply the model to something like what the NIF does, and then actually test it in the NIF. If the NIF experimental outcomes are in agreement with the model predictions, then we now have higher confidence that the model predictions with regards to the actual nukes are useful.
I am/was affiliated with CASL and used it for some of my research work. It's a nice system and we got amazing performance, it would have taken literally years to run the same calculations back on the cluster at my university. We didn't really take full advantage, though, as we weren't using the coprocessors. But I guess our mission is computational science, so maybe that's why we heard so much about it.
I just saw the most interesting presentation the other day. Tom Evans' group is apparently working on these nice new methods to solve linear systems via Monte Carlo sampling. It's one of the projects in pursuit of exa-scale systems. The Monte Carlo algorithms are interesting because while they're a lot slower in terms of CPU hours, they do much better in terms of scaling and resiliency at those sorts of extremes.
What I would like to see though, is also a return to an increase in absolute processing speed. GPUs and more nodes are great for simulating larger systems of molecules and atoms, but they are actually worse for simulating longer timespans. For example, one of my projects was a small carbon crystallite of 136 atoms. I ran that one on my laptop because it would have taken just as long on Titan.
Problems like protein folding require a sequential series of operations where each step depends on the last one. Right now, the solution to this is specific ASIC systems (like Anton) but then that is a lot of money invested into a machine that can only be used for one purpose.
Regardless, most of my work is size bound rather than time bound, so Summit will be great!
For a number of reasons, that's basically not going to happen. CPU single-threaded performance is still increasing slowly, but probably not by enough to satisfy your simulation needs.
In a lot of these cases, the only practical solution (assuming you can't spend the money on custom hardware) is to go back to the code and optimize the hell out of it. Partly this means clever low-level optimizations, but it might involve switching to programming models that help make better use of the hardware. For example, S3D, a combustion simulation which was one of the acceptance tests for Titan, runs about 2x faster under Legion (my research project) compared to the previous OpenACC code hand-tuned by Cray and NVIDIA engineers [1].
If that sounds interesting to you, feel free to contact me, and if you'll be at SC next week maybe we can meet up.
The American National Labs seem to have the experience and patience to implement new systems that work well enough and deliver on a dollar/flop ratio.
That way instead of doing a "big bang" upgrade such as this, you just upgrade individual nodes as the technology allows and are almost always "current."
PS - I find their usage of the term "energy independence" hilarious. That was a term coined largely to justify fracking and other environmentally damaging practices in the US. I'm glad to see it has been over-used so much now third parties are using it to justify other projects...
Scaling.
A very easy out for me to explain is imagine if you could only simulate two molecules in a Molecular Dynamics simulation and both had to have 100 atoms or less. There's plenty of opportunity, sure. But what if you wanted to simulate an entire strand of RNA interacting with a protein? There are techniques and stable approximations to avoid the O(n^2) complexity of a molecular dynamics simulation but the next-generation hardware allows you to run the same simulations with the same limitations at a much bigger scale, or the previous-sized problem without as many assumptions. edit: There are other considerations of course; I am vastly oversimplifying with this example.
Also, the more simulations you can run the more uncertainties you can account for in Monte Carlo computations, so models can evolve to contain more details and less assumptions.
adding response to: > That way instead of doing a "big bang" upgrade such as this, you just upgrade individual nodes as the technology allows and are almost always "current."
The problem is that programming targeting a supercomputer usually involves taking advantage of specific features of the hardware to get the bleeding edge performance. Mixing and matching hardware quickly makes deployment of the code difficult in addition to writing the code to reliably squeeze every ounce out of every chip.
Things like physics simulations, weather etc., have a lot of interaction between any divisions you could try to draw to be able to split the information between nodes. To work with these problems you need a faster interconnect between processors than ethernet provides, infiniband seems a popular choice but I'm no expert on the details of their architecture. These problems also need to move in relative lockstep meaning loosely connected systems don't work as well or at least don't provide any real advantages. Node homogeneity makes these tightly coupled processing nodes easier to manage.
Occasionally there will be upgrades to a super computer but generally they're run 24/7 until they're too far behind the technology, both in speed and lower power consumption, that it becomes cheaper to completely replace it than to try to do an upgrade that will replace more than half the cluster's total electronics to begin with.
And sometimes even more than bandwidth, inter-node latency, which is where Inifinband really shines over ethernet. Calculations which have high levels of node-to-node dependencies are pretty much the difference between super computers and the type of stuff that large internet companies compute on.
I hear (but don't personally know) that Google-style large data center installs are moving towards the CLOS-style networks that have been popular in HPC for a long time. These network topologies give equal bandwidth between any pair of nodes, as well as nearly equal latency.
Many datacenters are adopting HPC technologies to reach the scale they need.
Now, suppose your a scientist who want's to simulate a hurricane. You create a model for the first step (second, minute, or nanosecond) and can send that to a computer, but what do you send to the next computer. It needs results from the first simulation to run, but in that case you might as well just keep running the simulation on the same computer. Clearly to use a cluster your going to need to break up your simulation into pieces and send each part to a separate computer. But, now after each step all the nodes need to talk to all the other nodes to keep the simulation in sync. Worse the more chunks you separate the problem into the more parts need to be talking to other parts.
This is also why supercomputers tend to have equal strength nodes. Having one node finish before the other is pointless as it needs results from other nodes to continue. In the end you need not just massive bandwidth but also low latency. If a step takes 1/1000th of a second to run but then needs to wait a full second to run the next step then your simulation get's 1 step per second not per 1/1000th of a second.
You also want to back up each node so if one of them crashes you don't need to re run the simulation from scratch.