http://stackoverflow.com/a/26959685/1030861


자 visual studio 2013에만 해당된다는건데, 잘 봐바. 지 고집피우자고 링크 안볼 거 같으니까 걍 여기다가 인용한다.


What we have here is actually stranger than just memcpy vs. memmove. It's a case of the intrinsic optimization actually slowing things down. The issue stems from the fact that VS2013 inlines memcopy like thus:


; 73   :        memcpy(store[i % 100], data, sizeof(data));

...
    movups  xmm0, XMMWORD PTR [rdx]

    movups  XMMWORD PTR [rcx], xmm0

    movups  xmm1, XMMWORD PTR [rdx+16]

    movups  XMMWORD PTR [rcx+16], xmm1

    movups  xmm0, XMMWORD PTR [rdx+32]

    movups  XMMWORD PTR [rcx+32], xmm0

    movups  xmm1, XMMWORD PTR [rdx+48]

    movups  XMMWORD PTR [rcx+48], xmm1


The issue with this is that we're doing unaligned SSE loads and stores which is actually slower than just using standard C code. I verified this by grabbing the CRTs implementation from the source code included in with visual studio and making a my_memcpy


시발 저 글이 뜻하는게 뭐냐면, 컴파일러가 memcpy같은 애들을 libc의 구현을 호출하지 않고 그냥 인라이닝 시켜버릴 수도 있는데 (gcc에서는 __builtin_memcpy같은 류로 : https://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Other-Builtins.html), vs 2013에서는 unaligned access instruction인 movups를 이용해서 인라이닝하는 코드를 생성한다는거야. 그래서 실제로 libc의 memcpy를 호출하는것보다도 느리고, 심지어는 *d++ = *s++; 같은 c 코드보다도 느려진다는 거다. 코세 말대로 unaligned access가 aligned access보다 빠르면 저런 일이 생길리가 없지.


그래, 사실 이런거 가져다가 인용한다 해도 코세가 인정할거라고는 생각 안한다. 그래서 이제는 그냥 코세랑 엮이지 말아야겠어. 이 글을 마지막으로 내가 이 주제로 글 쓰는일 없을거다. 그동안 시끄럽게 해서 프갤러들한테 미안하다.


하... 좆나 구글링해서 목구녕에 자료 쑤셔넣어줘도 읽지를 않으니, 말을 해도 못 알아들으니 솔직히 이길 자신이 없다.