Cache Friendly Code

안녕하세요.

오늘 적을 내용은 최적화에 관련되서 간략히 적을까 합니다.

• Code 최적화는 모던 데스크탑 구조에서는 의미가 없다
• 유지 보수 관점에서 관리 비용이 낮은 코드가 고객의 입장에서는 맞다.
• 성능이슈는 프로세서 가격이 떨어지면 자연히 없어질 문제다.
• 변수명, 중복함수사용, String or stringbuilder..등등의 문제 언급함은 무의미 하다.

사정상 졸업은 못했지만,

처음으로 Cache friendly code의 컨셉을 잡아준 수업중 일부를 구글에서 검색 했습니다.

Pdx.edu 네요.

SI를 하면서 Cache를 활용한 코드에 관해서 이야기를 하면 10명중 9.7명은 죄다 모르는 이야기 입니다.

하지만 염연히 존재 하는 최적화 방식입니다.

오랜만에 보는 메모리 마운틴이네요.

대략 L1 캐쉬의 속도가 L2에 비해 월등히 높으며 L2는 메모리 보다 높음을 알수 있습니다.

현재 i7-4950k 제 CPU의 경우 캐쉬가 8M가 이니, Temporal locality 만 잘되도 많은 퍼포먼스 향상은 당연히 볼수 있습니다.

 

하지만 문제는 Modern OS 와 Processor 입장은 좀 다르다는 겁니다.

이러한 원론적인 언급은 Naver, daum 보다는 stackoverflow 에 월등히 많습니다.

그중 일부를 발췌 합니다.

 

http://stackoverflow.com/questions/20835357/understanding-how-to-write-cache-friendly-code

답변중 핵심은 이러 한 내용입니다.

.. Desktop processors are design with the philosophy of running "bad code" fast so a lot of investment is made in improving "bad code" performance because the vast majority of desktop applications aren't written by people who understand branching issues or cache models..

.. 데스크탑 프로세서는 Bad code를 빠르게 실행할 목적으로 디자인 되었으며, Bad code 실행을 위해 많은 투자가 이뤄집니다. 왜냐면 대부분의 데스크탑 어플리케이션은 캐쉬 모델 및 브렌칭 이슈를 이해하지 못하는 사람들의 의해 만들어졌기 때문입니다..

 

즉, 개떡같이 말해도 찰떡같이 알아 듣는 compiler 및 processor 가 오히려 칩 제조사의 목적입니다. Compiler 는 눈에 띄게 발전한게 없으니 CPU제조사측에서 더 개떡 같은 machine code를 최적화 시키기 위해서 노력하는거겠죠.

 

그렇다면 Cache Friendly code란 무엇인가?

애매 모호한 개념이지만, L1 캐쉬를 잘 이용하면 일단 메모리(RAM)를 활용하는 잘 짜여진 알고리즘 보다,

더 빠른 결과를 얻을수 있다 정도로 이해 하고 있습니다.

즉, 고급 인력의 노하우를 어느정도 상쇄 시킬수 있는 영역이 있다는게 제 이해의 종착점 입니다.

 

http://stackoverflow.com/questions/16699247/what-is-cache-friendly-code

.. Cache 는 비용이 비싸기에 더 좋은 caching 방식을 찾는 이유이다.. 대역폭을 늘리는건 쉽지만, 대기 시간 없이 살수는 없다..

Cache 의 제조 비용이 현 RAM과 동일해지면 CPU의 캐쉬양이 엄청나게 커져서 RAM이 줄어 들지 않을까 합니다.

1. 임시 보관, 2. 인근 보관.

 

• 한번 실행된 application 은 재실행시 최초 실행보다 빨리 실행되는 이유가 caching 이 되었기 때문입니다(1)
• 연속되어 연결된 파일들은 (조각모음) 조각 조각 떨어져 있는 파일들보다 빠릅니다.(2)

 

위의 2개의 핵심 컨셉이 caching이 된거로 보면 됩니다.

 

이제 VES(C# CLI , JAVA VM)의 관점에서 보게 될 경우,

CPU에서 바로 실행되는 , 바이너리가 아닌 가상 실행 코드(C#, JAVA에서 사용되는 컨셉)의 경우 위의 Cache Friendly Code 작성이 가능할까요?

답은 거의 불가능 하다 입니다.

 

이유는 간단하지만, CPU에서 실행되는건 가성 코드를 번역해서 실행하는 실행 코드(VES의 바이너리) 이기 때문입니다.

그나마 VES가 가상 코드의 패턴을 분석해서 최적화를 도와 준다면 모르겠지만, 일반 프로그래머 입장에서 그렇게 디테일하게 작성할 가능성은 희박합니다.

 

일단 Cache friendly 의 컨셉을 대다수가 모를 뿐더러, 설령 안다 치더라도 많은 부분의 실행 코드(JIT 제외) 는 CPU에서 직접 처리되는 것 보다 HOST(VES)를 통해서 실행되기 때문입니다.

 

상황이 이러한데, 아직도 성능상의 이슈를 변수명, refactoring 안된 코드, for문안의 변수 명등등으로 언급하는건 넌센스로 보입니다.

 

오히려 사용자( SW 구매자)의 관점에서 중복 및 반복이 되는 코드 일 지라도 유지 보수 비용이 적게 드는 코드가 오히려 최적화에 가깝다라는 결론입니다.

 

전공자, 비전공자 모두 그릇된 컨셉에 의해서 아직도 그 망령을 벗어 나지 못하는데요.

더 이상 이러한 방식의 논의는 시간 낭비다란걸 기억했으면 합니다.

 

Profession Software development 에서 언급된 내용중 기억나는 부분이 있는데요.

CS 전공자는 너무 알고리즘에 치중해서 SW Engineering 에서 필요한 기술을 못배웠고, 자기 목을 조이는 행위다..

 

스티브 맥코널이 지적한 내용이지요.

 

그리고 한참동안 까먹었던 컨셉인데, 캐스팅, 박싱 언박싱 관련되서도 trade off 할 영역이 있습니다.

개발 일정이 정해지었고, 스펙이 고객도 모르는 상황에서 성능을 고려 하면서 코딩을 해야 할까요?