<div class="gmail_quote">On Tue, Sep 11, 2012 at 11:35 PM, JL VT <span dir="ltr"><<a href="mailto:pentalis@gmail.com" target="_blank">pentalis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><div class="gmail_quote">On Tue, Sep 11, 2012 at 4:26 PM, Sven Langkamp <span dir="ltr"><<a href="mailto:sven.langkamp@gmail.com" target="_blank">sven.langkamp@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div class="gmail_quote"><div>On Tue, Sep 11, 2012 at 12:21 PM, JL VT <span dir="ltr"><<a href="mailto:pentalis@gmail.com" target="_blank">pentalis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<p>I have overclockable memory but I'm fairly sure we are not bottlenecked by memory, nowadays nearly nothing is.</p>
<p>But I can still test, I can test at 1333 mhz and 1866 mhz (just an example) and see if there is a chance. Is there any other way to check for a memory bottleneck?</p></blockquote></div><div>It's more like the oppsite. Most of the time the cpu is waiting for data. Your RAM is much slower than the cache, cache misses are usually really expensive.</div>




<div><br></div><div>In the vc branch for example the masking for autobrush spends 2/3 of the time doing memcpy. That's just copying the color into the dab.</div><div><div></div></div></div></blockquote></div>
<br></div><div>Before purchasing my RAM I looked at a long list of benchmarks on Tom's hardware done on different types of software, and the only time the effect of faster RAM was really noticeable was on artificial benchmarks. Everywhere else, like games, encoding, video editing, it didn't go past 7% speedup, even going from 1333 Mhz to 2100 Mhz, or single to dual, or dual to quad channel. That's why I think it's not a memory problem. And if it was, maybe we can program things differently; after all, if other graphical software isn't affected by memory speed, why are we?.</div>


</blockquote></div><br><div>That just shows that an existing program isn't going faster with faster RAM. In both cases there program would do the same, just the memory access is a little faster. In our case you have two version of the same algorithm and one does more memory access than the other.</div>
<div><br></div><div>Beside the one expensive memcpy in the masking, I think it's not that bad at the moment. Priority should still be vectorize the composite op.</div>