그건 병신아 SIMD 비용이야.

mmx 시절 EMMS 코드 처럼 무시무시하게 몇천 클럭 쳐먹는 경우는 아니지만,

core context 는 정리해야 된다고.

4096 바이트 미만을 복사할땐 char 단위 for문 복사가 젤 빠른 경우가 많아.

(그래봐야 memcpy와 수십~1~200 클럭 차이)


char 단위라고 하면 물론 입력조건이 aligned 인거지 멍청한 녀석아.


그래서 내가 unaligned 조건을 이야기한거고,

그래서 케바케로 구현해야 한다는거다. unaligned 는 최적화를 위한 선택! 바보야.


즉 그 근거는 니가 최적화를 위해 unaligned 선택은 개소리다 라고 한 주장을 절대 뒷받침해주지 못해.


무슨 내용인지도 모르면서 인용하는 꼬라지 보소. ㅋㄷ

허접한 스펙충.


니 글 마지막 줄이 웃겼다.


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


걍 존나 구글링이나 하고 사셔. 스펙 한 번 보고 실험 한 번에 추론 한 번 하면 끝날것을.

지가짠 코드 결과도 정리 못하는 지식과 대가리 가지고 누구한테 자료 쑤셔넣어준다는건지.

진중권이 쓴 수사법 카피하면 니가 진중권 입장이라도 된 것 같냐?( 좆+목구녕+쑤셔넣어 는 또 뭐냐? 초딩도 아니고 )

솔까말 최적화 공부는 나보다 니가 해야지.

데이타 딱 보고 잘못된 실험이다 알 수 있는 정도는 경험을 가져야 하지 않겠음?


표준은 바뀐다.

하드웨어도 바뀐다.

컴파일러도 점점 똑똑해 진다.

하지만 최신 표준을 100% 따르는 컴파일러는 거의 없다.

그 말은 프로그래밍 관련 정보와 지식은 유통기간이 있다는거야.

니가 지금 존나 열심히 공부해서 얻어내는 지식의 절반 이상은 이내 쓸모없는 역사가 된다.

정보를 소비하기 보다 만들어내는 요령을 얻어야 하는 이유고,

하다 못해 보다 rigid 한 지식을 얻어야 하는 이유다.

컴파일러가 프로그래머의 코드를 통해 문맥을 잘 이해하게 하는데는 좀 더 요령이 필요하다.

구체적이고 직접적인 표현들로 연산의 흐름을 명시해줄 때,

그 표현에 갇혀 문맥을 요약하지 못하는게 아직까지의 컴파일러다.

그건 존나 스펙 판다고 깨닫게 되는게 아님.

C/C++ 언어의 표준은 변화하지만, 연산과 관련한 문법 자체는 무척 고전적이다.

그래서 STL 이나 functional 에 그나마 가까운 표현이 C++ 표준에 들어오는거고,

표준에 있다면 컴파일러가 보다 덩치큰 흐름에 대해 문맥적으로 접근할 수 있으니까,

당장은 아니더라도 향후 새로운 컴파일러를 통해 더 최적화될 여지가 있는 코드를 작성할 수 있다.

아직까지는 궁극의 최적화를 하고 싶으면 intrinsic 이나 IPP 같은 라이브러리를 써야지.

궁극 까진 아니더라도 어느정도의 최적화와, 컴파일러 제작자들의 노력을 쉽게 흡수하고 싶다면,

STL, 확장문법들, 적극적으로 써 줘야지.

나도 OSX 나 모바일 플랫폼으로의 호환성을 유지하면서 최적화에 효과적인 코딩을 하기 위해

순수 C++ 문법으로 보다 잘 최적화되게 하는 방법을 실험해왔다.


인터넷은 잘못된 정보와 지도의 천국이다.

정확한 정보라 하더라도 컨텍스트가 네 경우와 다르면 바로 쓸 수 없는 데이타다.

그게 적확한 정보가 필요한 이유고,

상당수의 적확한 정보는 니가 코딩을 통해 컴퓨터와 대화할 때 얻을 수 있다.

그래서 너보고 짜보라고 했던거야.

네가 짜본것 처럼 아는척 했지만,

결과가 뭐야? 넌 그 흔한 memcpy 구조 조차도 제대로 알만큼 짜본적 없음. 내 말이 틀려?

그 말은 구조체와 구조체를 대입할 때의 복사 메카니즘도 똑바로 모른다는 이야기임.


지형과 지도가 다르면 지형을 믿어라. - 스위스 군대 격언 -