<div dir="ltr">On Tue, Sep 24, 2013 at 2:45 AM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Karl Rupp <<a href="mailto:rupp@mcs.anl.gov">rupp@mcs.anl.gov</a>> writes:<br>
<br>
>>> This can obviously be done incrementally, so storing a batch of<br>
>>> element matrices to global memory is not a problem.<br>
>><br>
>> If you store element matrices to global memory, you're using a ton of<br>
>> bandwidth (about 20x the size of the matrix if using P1 tets).<br>
>><br>
>> What if you do the sort/reduce thing within thread blocks, and only<br>
>> write the reduced version to global storage?<br>
><br>
> My primary metric for GPU kernels is memory transfers from global memory<br>
> ('flops are free'), hence what I suggest for the assembly stage is to go<br>
> with something CSR-like rather than COO. Pure CSR may be too expensive<br>
> in terms of element lookup if there are several fields involved<br>
> (particularly 3d), so one could push (column-index, value) pairs for<br>
> each row and making the merge-by-key much cheaper than for arbitrary COO<br>
> matrices.<br>
<br>
</div>I think CSR vs. COO is a second-order optimization to be considered<br>
after the 20x redundancy has been eliminated and a synchronization<br>
strategy has been chosen (e.g., coloring vs redundant storage and later<br>
compression).</blockquote><div><br></div><div>Yes. I do not understand Karl's suggestion about CSR/COO. My take-away from Owens'</div><div>talk at Brown was that synchronization is too expensive/complex and that we should</div>
<div>always do redundant storage+compression.</div><div><br></div><div>Please please please lets have an example where this takes > 5% of simulation time. I</div><div>do not really believe it is alright to work on something that takes < 50%.</div>
<div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> This, of course, requires the knowledge of the nonzero pattern and<br>
> couplings among elements, yet this is reasonably cheap to extract for a<br>
> large number of problems (for example, (non)linear PDEs without<br>
> adaptivity). Also, the nonzero pattern is rather cheap to obtain if one<br>
> uses coloring for avoiding expensive atomic writes to global memory.<br>
<br>
</div>At this point, I don't mind having the nonzero pattern set ahead of time<br>
using CPU code.  It's reassembly in time-dependent problems with no<br>
adaptivity or occasional adaptivity that I'm more concerned with.<br>
</blockquote></div><br>-- <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
</div></div>