가끔.. 정말 가끔.. 캐쉬를 신봉하시는 분들이 계십니다. 언제나 어디서나 누구에게나 캐쉬가 좋다! 라는 분들이지요.

캐쉬 메모리는 기본적으로 지역성의 원리(principle of locality)를 이용하는 메모리입니다.
즉, 이 세상의 대부분에 적용되는 80:20의 원리.. 이것이 캐쉬에서도 적용되어서 “메모리 접근중의 대부분은 특정한 부분에 이루어진다.”라는 특성을 지니게 됩니다.

세상의 일반적인 원리(?)를 이용한 것이니, 대부분의 어플리케이션에서는 캐쉬를 사용함이 타당합니다.
하지만, 항상 그러냐구요?
예외없는 법칙이 없듯이 캐쉬에서도 마찬가지 입니다.
캐쉬가 힘을 제대로 못쓰는 경우는 “지역성이 없는 데이터”입니다. 당연하겠죠? 지역성을 이용하는 메모리인 캐쉬이니, 지역성이 없는 데이터는 쥐약입니다.

그럼, 지역성 없는 데이터는 어떤것이 있을까요? 캐쉬의 1 라인이 4개 워드를 저장하는 구조라고 합시다.
4 x 4 배열 두개를 만들어봅시다. 배열에서 가장 많이 사용하는 연산이 뭐죠? 내적..
접근은  x(0,0) y(0,0) x(0,1) y(1,0) x(0,2) y(2,0) x(0,3) y(3,0) 이런식이죠? x는 비교적 순서대로 접근했으니 캐쉬 hit이 자주 납니다. 근데, y는 어떻죠? 계속 miss가 발생합니다. 공간적 지역성이 캐쉬에서 예측한 지역성의 수준보다 크기때문에, miss가 발생하는 겁니다.

좀더 심각하게 생각해 볼까요? 하나의 배열에서 저런 접근 하나만 하고, 더 이상 사용하지 않고 다른 배열을 씁시다. 이런 경우가 없다고요? 동영상이 연속된 배열의 입력이란건 알고 계시죠? ^^;

네, 멀티미디어 데이터는 많은 경우 시간적 지역성이 부족합니다. 동영상은 공간적 지역성도 부족할때가 많구요.
그래서, 멀티미디어 처리를 목적으로 하는 프로세서들에는 내장  램을 두고 캐쉬는 두지 않는 경우가 빈번합니다. 또한,  배열 데이터는 특정한 패턴이 있으므로 prefetcher라는 유닛을 두고 프로세서가 필요로 하기 전에 데이터를 내부 RAM에 넣어서, 접근을 빠르게 하는 경우가 많습니다.

이런 경우에 캐쉬가 영 잼병이냐구요?
음.. 네.. 솔직히 캐쉬가 멀티미디어 데이터에 있어서만은 잼병이 될때가 많습니다. 프로그래머분들께서 세심하게 다루어주지 않으시면 말입니다. 사실 캐쉬의 동작은 프로그래머가 프로그램을 얼마나 “캐쉬에 효과적으로” 짜 주시느냐에 따라 달라집니다.

캐쉬에 효과적이려면 어떤 것일까요?
당연히 “지역성의 원리”를 따를 수 있도록, 배열을 잘게 짤라서 공간적 지역성을 찾아수록 좋습니다.
또, 하나의 배열에 대해서 어떤 처리를 해야 한다면 최대한 그 배열에 대해서 어떤 동작을 많이 취해주는 것이 좋습니다.
예를 들어, 이미지의 화질을 개선하기 위해서 상호 보간하고, 밝기를 조정하는 동작을 한다면 모든 화면에 대해서 보간하고 난 이후에 밝기를 조절하는 것 보다는, 잘게 짜른 매크로 블럭에 대해서 보간, 밝기 조정을 같이 수행하는 것이 아무래도 캐쉬에게 좋습니다.

요즘처럼 프로세서가 빨리 도는 세상에, 캐쉬 동작까지 고려하시는 분이 어디있겠습니까만.. (엔진을 만든다던지 하시는 분 이외에는 말입니다.), 염두에 두면 아무래도 더 좋겠죠…
물론, 많은 분들께서 캐쉬도 잘 고려해주는 좋은 컴파일러를 찾으시겠지만 말입니다.