<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 14, 2018 at 6:15 PM, 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="">Richard Tran Mills <<a href="mailto:rtmills@anl.gov">rtmills@anl.gov</a>> writes:<br>
<br>
> On Tue, Feb 13, 2018 at 8:48 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
><br>
>> Richard Tran Mills <<a href="mailto:rtmills@anl.gov">rtmills@anl.gov</a>> writes:<br>
>><br>
>> > I haven't experimented very thoroughly with it (hmm... should probably do<br>
>> > such experiments), but I believe that, once matrix rows become<br>
>> sufficiently<br>
>> > long, then SELL doesn't provide an advantage over AIJ.<br>
>><br>
>> What is the performance model that explains why SELL doesn't benefit<br>
>> from long rows?  It's clear for large blocks where BAIJ can be compiled<br>
>> to vectorized loads and stores, but much less clear when AIJ is<br>
>> producing basically scalar code.<br>
>><br>
><br>
> Hmm. I may be mistaken in my statements about long rows and AIJ -- I think<br>
> it might be the case that every matrix with long rows for which I've seen<br>
> the decent performance with AIJ was something that uses and benefits from<br>
> the Inode versions of the routines.<br>
<br>
</span>Have you tested that Inodes are an improvement?  I've seen the opposite<br>
(by about 5%) on some recent Intel.<br></blockquote><div><br></div><div>I have not tested this. I should give this a try and look into what is going on, either way.<br><br></div><div>--Richard<br>[...]<br></div></div></div></div>