memmove faster than memcpy for small N

Posted Sep 5, 2018 23:03 UTC (Wed) by jreiser (subscriber, #11027)
In reply to: C considered dangerous by quotemstr
Parent article: C considered dangerous

The key is "for small N". The glibc implementation of memcpy favors speed for non-small N, and has several checks and conditional branches before doing much "useful work". The penalty for a mis-predicted conditional branch is often about 12 cycles. The implementation of memmove has fewer initial checks (mostly for overlap or not), and starts doing "useful work" sooner. For small N, the fewer mis-predicted conditional branches enable faster memmove.

memmove faster than memcpy for small N

Posted Sep 5, 2018 23:45 UTC (Wed) by quotemstr (subscriber, #45331) [Link] (3 responses)

That makes no sense. A memcpy could turn those branches into unconditional jumps and avoid any mispredict penalties.

memmove faster than memcpy for small N

Posted Sep 6, 2018 3:42 UTC (Thu) by jreiser (subscriber, #11027) [Link] (2 responses)

Code, please. I'll bet a beer that your code will be slower for small N (or incorrect.)

memmove faster than memcpy for small N

Posted Sep 6, 2018 6:55 UTC (Thu) by liw (subscriber, #6379) [Link]

I think both sides need to provide code and benchmarks to settle this question. Hypotheticals and claims based on mental models only go far. Even arguing based on code is insuffident, given how complex an issue performance analysis can be.

I tried writing a benchmark. GCC optimised it away.

memmove faster than memcpy for small N

Posted Sep 6, 2018 7:14 UTC (Thu) by quotemstr (subscriber, #45331) [Link]

No, you write the code. I'm not the one making the absurd claim. A program is never made slower by converting always-taken conditionals into jumps.