Skip to content

Comment on Intel's take on GCC's memcpy implementation

Comments

Someone tell me if I am mistaken - but it looks like the main difference between GCC's and Intel's memcpy() boils down to gcc using `rep movsl` and icc using `movdqa`, the latter having a shorter decode time and possibly shorter execution time?

No, the problem is with x86-64, which apparently doesn't use `rep movsl`; as far as I can tell, GCC's x86-64 backend assumes that SSE will be available, and so only has a SSE inline memcpy. However, in the kernel SSE is not available (as SSE registers aren't saved normally, to save time), so this is disabled. With no non-SSE fallback (such as `rep movsl` on x86), gcc falls back to a function call, with the performance impact this implies.

From the sound of it, the function call was not the issue, so much as the function that gets called is old and non-optimal with modern tools.

rep movsl moves data 32 bits at a time, while movdqu/movdqa moves data 128 bits at a time. The advantage is not only in decoding -- the data paths in modern Intel processors are really 128bit, so movdqu/movdqa gets 4 times the throughput out of the system. (Until you run out of L1 cache, after which you really slow down.)

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.