On Sat, Dec 5, 2009 at 3:50 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@59a2.org">jed@59a2.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Fri, 4 Dec 2009 22:42:35 -0600, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
> generally we would have one python process per compute node and local<br>
> parallelism would be done via the low-level kernels to the cores<br>
> and/or GPUs.<br>
<br>
</div>I think one MPI process per node is fine for MPI performance on good<br>
hardware because the HCA reads and writes from registered memory without<br>
involving the CPU, but I'm not sure it's actually a better model.<br>
<br>
How do you envision implementing MatSetValues()?  If there is only one<br>
MPI process per node, would there be another full level of domain<br>
decomposition based on threads?  Otherwise you need a concurrent<br>
MatSetValues which would make proper preallocation essential and make<br>
cache coherence a very sensitive matter.<br></blockquote><div><br>I need to understand better. You are asking about the case where we have<br>many GPUs and one CPU? If its always one or two GPUs per CPU I do not<br>see the problem.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
And the huge algorithmic issue: triangular kernels are the backbone of<br>
almost every preconditioner and are inherently sequential.  If only one<br>
process per node does MPI, then all these algorithms would need<br>
three-level implementations (decompose the per-node subdomains into<br>
per-core subdomains and use a different concurrency scheme at this<br>
smaller granularity).  The use of threads on the many cores per node<br>
potentially offers more performance through the use of lock-free shared<br>
data structures with NUMA-aware work distribution.  But separate memory<br>
space is much more deterministic, thus easier to work with.<br></blockquote><div><br>Hmm, still not quite getting this problem. We need concurrency on the GPU,<br>but why would we need it on the CPU? On the GPU, triangular solve will be<br>
just as crappy as it currently is, but will look even worse due to large number<br>of cores. It just has very little concurrency. We need a better option. It is not<br>the only smoother. For instance, polynomial smoothers would be more concurrent.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I have trouble finding decent preconditioning algorithms suitable for<br>
the fine granularity of GPUs.  Matt thinks we can get rid of all the<br>
crappy sparse matrix kernels and precondition everything with FMM.<br></blockquote><div><br>That is definitely my view, or at least my goal. And I would say this, if we are just<br>starting out on these things, I think it makes sense to do the home runs first. If we<br>
just try and reproduce things, people might say "That is nice, but I can already do that<br>pretty well".<br><br>   Matt<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Noteh that all Python implementations have a global interpreter lock<br>
which could also make a single Python process the bottleneck.<br>
<font color="#888888"><br>
Jed<br>
</font></blockquote></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener<br>