사실 깜짝 놀라긴 했다. 저 정도로 느리진 않을텐데? 라고 생각했거든.


그래서, 윈도 깔고 vs 2015 깔고 직접 해봤어. 하 진짜 내가 이짓을 왜 하고 있나 몰라.


내가 썼던 글에 gcc의 -fno-tree-loop-distribute-patterns 옵션 얘기를 했었는데, 얘가 코드를 보고 memcpy를 부르면 되겠다 싶을때 지맘대로 memcpy 호출로 바꿔버리는걸 막아주는 거거든.


근데 VS 에서도 똑같은 짓을 하더라고.


내 생전 x86 어셈블리는 처다보도 안할랬는데 vs에 디버거에 생전 안하던 짓을 한다 덕분에.


일단 my_memcpy_byte_only 부터 까보자.


   183: void *my_memcpy_byte_only(void* __restrict dest, const void* __restrict src, std::size_t n)

   184: {

...
00007FF770D44183  je          my_memcpy_byte_only+29h (07FF770D44199h)  

00007FF770D44185  call        memcpy (07FF770D45628h)  

00007FF770D4418A  lea         rax,[rbx+rdi]  

...


내가 x86 잘 모르긴 하는데 call이라는 인스트럭션이 memcpy를 호출하는 건 확실한것 같아뵌다??


my_memcpy_unaligned도 까보면,


   164: void *my_memcpy_unaligned(void* __restrict dest, const void* __restrict src, std::size_t n_byte)

...
00007FF770D441DC  shl         r8,3  

00007FF770D441E0  call        memcpy (07FF770D45628h)  

   172: 


내 눈이 니 눈마냥 리신이 된게 아니라면 얘도 memcpy 호출하는게 확실한것 같은데.


내가 구현한 my_memcpy는 뒤져봐도 memcpy를 호출하는 부분이 잘 안뵈네.


코세야. 내가 짠게 vc++ libc의 memcpy보다 느린건 뭐 부끄럽지만 사실로 인정할게.


근데 그렇다고 내 코드가 unaligned access가 aligned access보다 빠르다는 증거는 되지 않는단다. 내 글에도 써놨었는데 진짜 쫌만 대가리가 돌아갔으면 저게 unaligned access가 빨라서 그런건지 memcpy 호출로 바껴서 그런건지 한번쯤은 생각해봤을 것 같은데말야.


내가 vs를 거의 안만져봐서 vs에 해당 옵션이 있는지 잘 모르겠다. 스택오버플로에 질문글(http://stackoverflow.com/questions/36424839/how-to-prevent-vc-from-emitting-calls-to-memcpy) 싸놨는데 vs에서도 memcpy 호출로 대치하는걸 방지하는 옵션이 있으면 그거 켜보고 다시 수행해서 올릴게.


마지막으로, 뭐 남의 코드 품평해놓고 니 코드는 안올리는건 어디서 배워먹은 상놈 집안 매너니? ㅋㅋㅋㅋ 뭐 예상은 했지만 진짜로 그럴줄은 몰랐네. 내 예상에 지 코드를 안올리는 이유가 사실은 지가 작성한 코드가 없거나, 아님 지도 지가 짠거 보니까 얼라인먼트를 맞추고 있다거나 둘 줄 하나 같은데, 한번 올려보렴.