FASTMATH Scalability Panel Discussion - ahmadia/atpesc-2013 GitHub Wiki

Can you speak a little bit about scalability of large-scale numerical algorithms?

Smith: It's most important to choose a scalable mathematical algorithm than an algorithm that will scale than it is to choose a dumb algorithm on a large machine.

Falgout: You won't necessarily scale well, but the most important thing is the time-to-solution.

Tautges: Scalability comes from avoiding doing any I/O possible. Right now, the high-level I/O libraries are not scaling well for us.

Shephard: Stabilized finite elements and GMRES using diagonally dominant system, so scales to entire machine. Generating meshes right now doesn't scale.

What are you the most excited about? What are you most terrified of?

Smith: Excited about pipelined Krylov methods. IBM has a fantastic reduction network, enormous number of cores, but Cray does not have great reduction. No longer need hard synchronization, some softer synchronizations, no wait times for the reductions. We're not going to be able to use any algorithms that rely on the blocking reduction in the future.

Afraid that we're going to go for the next ten years and not have a consistent programming model for how we program these machines. Programming models A, B, and C might not interoperate well. MPI was fantastic because it collected everything into one programming model everybody could use. If this doesn't happen, we're not going to to get the code reuse we want. The programming model has to "do no harm" to scalability.

Falgout: Most excited about parallel-in-time algorithms.

Not afraid of anything. Sees challenges

Tautges: Did dissertation in 1990 on shared memory parallel computing. Message-passing has dominated since then, but that has been changing in the last 5 years. There's been a development of reusable libraries that help you get top performance on the biggest machines. PISCEES code was developed in a single year, scaled up to thousands of cores, built on top of libraries that allowed fast development. ITAPS interface has been most exciting for him.

It would have taken 6 months in PETSc (Barry Smith)

Also terrified of ITAPS and having to support all of these applications. Doesn't cross 'i's and dot 't's well enough to support a large group of users, is going to have to grow to support users. GPUs are also scary.

Shephard

Most excited by our ability to take things to the level of resolution we need to from applications that can self-adaptively resolve the simulation.

The current generation of accelerators, the Phi's are going to be easier to program than GPUs. Both have complexities that are an issue with respect to the data movement and reorientation. That is problematic when you are going to be constantly changing the data you are working on (within the context of adaptively meshing, constantly changing your data). It's a little worse than that, because machines are very energy-efficient. Doesn't like the BlueGene/Q processors because they don't do great in non-floating-point-heavy situations.

You better make things work well on the stuff that's the 80-90%.