<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 6, 2015 at 10:42 AM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
>> This is for a perfect cache model -- each byte of the data structures<br>
>> needs to be fetched from DRAM only once.<br>
>><br>
><br>
> I meant uncached, in which you count # Vecs for any operation you are<br>
> doing.<br>
<br>
</span>Wrong, you're describing a perfect cache model [1].  The initial data<br>
does not reside in cache, but you only need to fetch each byte from DRAM<br>
once.  The reality for larger problem sizes is that the entire wavefront<br>
is not resident (e.g., perhaps because matrix entries evict vector<br>
entries) and thus a single SpMV needs to re-load some vector entries.<br>
For heavier matrices, this does not significantly change the bandwidth<br>
requirements.  If the access pattern is predictable (i.e., you often get<br>
lucky if you choose a locality-preserving order) then the perfect-cache<br>
pure bandwidth model is good.<br>
<span class=""><br>
> If you count # Vecs for the whole program, then you have perfect<br>
> cache.<br>
<br>
</span>[1] Or we have different definitions of "perfect cache", but I don't<br>
think it's useful to discuss DRAM bandwidth if all data is resident in<br>
cache, so I'm referring to perfect caching of inputs that are not<br>
resident in cache.<br>
</blockquote></div><br>Yes, this is a language problem only.</div><div class="gmail_extra"><br></div><div class="gmail_extra">  Matt<br clear="all"><div><br></div>-- <br><div class="gmail_signature">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></div>