<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 11, 2009, at 3:27 AM, Rodolph Perfetta wrote:</div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>If you know about the alignment, maybe use structured load/store<br>(vst1.64/vld1.64 {dn-dm}). You may also want to work on whole cache lines<br>(64 bytes on A8). You can find more in this discussion:<br><a href="http://groups.google.com/group/beagleboard/browse_thread/thread/12c7bd415fbc">http://groups.google.com/group/beagleboard/browse_thread/thread/12c7bd415fbc</a><br>0993/e382202f1a92b0f8?lnk=gst&q=memcpy&pli=1 .<br><br><blockquote type="cite">Even if it's not faster, it's still a code size win which is also<br></blockquote><blockquote type="cite">important.<br></blockquote><br>Yes but NEON will drive up your power consumption, so if you are not faster<br>you will drain your battery faster (assuming you care of course).<br><br>In general we wouldn't recommend writing memcpy using NEON unless you can<br>detect the exact core you will be running on: on A9 NEON will not give you<br>any speed up, you'll just end up using more power. NEON is a SIMD engine.<br><br>If one wanted to write memcpy on A9 we would recommend something like:<br> * do not use NEON<br> * use PLD (3-6 cache lines ahead, to be tuned)<br> * ldm/stm whole cache lines (32 bytes on A9)<br> * align destination</div></blockquote><br></div><div>Thanks, Rodolph.  That is very helpful.</div><div><br></div><div>Can you comment on David Conrad's message in this thread regarding a ~20 cycle penalty for an ARM store following a NEON store to the same 16-byte block?  If the memcpy size is not a multiple of 8, we need some ARM load/store instructions to copy the tail end of it.  The context here is LLVM generating inline code for small copies, so if there is a penalty like that, it is probably not worthwhile to use NEON unless the alignment shows that the tail will be in a separate 16-byte block.  (And what's up with the 16-byte divisions?  I thought the cache lines are 64 bytes....)</div></body></html>