Hi, Aron,<br>Can you please give link of Barry's talk about multigrid memory access patterns (u just mentioned)?<br><br>thanks<br><br><div class="gmail_quote">On Wed, Nov 18, 2009 at 10:26 AM, Aron Ahmadia <span dir="ltr"><<a href="mailto:aron.ahmadia@kaust.edu.sa">aron.ahmadia@kaust.edu.sa</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Does anybody have good references in the literature analyzing the memory access patterns for sparse solvers and how they scale? I remember seeing Barry's talk about multigrid memory access patterns, but I'm not sure if I've ever seen a good paper reference. <br>
<br>Cheers,<br><font color="#888888">Aron</font><div><div></div><div class="h5"><br><br><div class="gmail_quote">On Wed, Nov 18, 2009 at 6:14 PM, Satish Balay <span dir="ltr"><<a href="mailto:balay@mcs.anl.gov" target="_blank">balay@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Just want to add one more point to this.<br>
<br>
Most multicore machines do not provide scalable hardware. [yeah - the<br>
FPUs cores are scalable - but the memory subsystem is not]. So one<br>
should not expect scalable performance out of them. You should take<br>
the 'max' performance you can get out out them - and then look for<br>
scalability with multiple nodes.<br>
<font color="#888888"><br>
Satish<br>
</font><div><div></div><div><br>
On Wed, 18 Nov 2009, Jed Brown wrote:<br>
<br>
> <a href="mailto:jarunan@ascomp.ch" target="_blank">jarunan@ascomp.ch</a> wrote:<br>
> ><br>
> > Hello,<br>
> ><br>
> > I have read the topic about performance of a machine with 2 dual-core<br>
> > chips, and it is written that with -np 2 it should scale the best. I<br>
> > would like to ask about 4-core machine.<br>
> ><br>
> > I run the test on a quad core machine with mpiexec -n 1, 2 and 4 to see<br>
> > the parallel scaling. The cpu times of the test are:<br>
> ><br>
> > Solver/Precond/Sub_Precond<br>
> ><br>
> > gmres/bjacobi/ilu<br>
> ><br>
> > -n 1, 1917.5730 sec,<br>
> > -n 2, 1699.9490 sec, efficiency = 56.40%<br>
> > -n 4, 1661.6810 sec, efficiency = 28.86%<br>
> ><br>
> > bicgstab/asm/ilu<br>
> ><br>
> > -n 1, 1800.8380 sec,<br>
> > -n 2, 1415.0170 sec, efficiency = 63.63%<br>
> > -n 4, 1119.3480 sec, efficiency = 40.22%<br>
><br>
> These numbers are worthless without at least knowing iteration counts.<br>
><br>
> > Why is the scaling so low, especially with option -n 4?<br>
> > Would it be expected to be better running with real 4 CPU's instead of a<br>
> > quad core ship?<br>
><br>
> 4 sockets using a single core each (4x1) will generally do better than<br>
> 2x2 or 1x4, but 4x4 costs about the same as 4x1 these days. This is a<br>
> very common question, the answer is that a single floating point unit is<br>
> about 10 times faster than memory for the sort of operations that we do<br>
> when solving PDE. You don't get another memory bus every time you add a<br>
> core so the ratio becomes worse. More cores are not a complete loss<br>
> because at least you get an extra L1 cache for each core, but sparse<br>
> matrix and vector kernels are atrocious at reusing cache (there's not<br>
> much to reuse because most values are only needed to perform one<br>
> operation).<br>
><br>
> Getting better multicore performance requires changing the algorithms to<br>
> better reuse L1 cache. This means moving away from assembled matrices<br>
> where possible and of course finding good preconditioners. High-order<br>
> and fast multipole methods are good for this. But it's very much an<br>
> open problem and unless you want to do research in the field, you have<br>
> to live with poor multicore performance.<br>
><br>
> When buying hardware, remember that you are buying memory bandwidth (and<br>
> a low-latency network) instead of floating point units.<br>
><br>
> Jed<br>
><br>
><br>
<br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>