[💬] 데이터 지향 프로그래밍의 핵심

은 캐시 미스를 줄여서 램에서 데이터 불러오는 동안 cpu가 노는 경우를 최소화하는 것.

OOP와의 차이점은, OOP는 객체의 한 인스턴스를 만들었을 때 그 객체를 구성하는 데이터가 지역성의 원리(principle of locality)를 따르도록 하는데 크게 신경을 쓰지 않는다는 것.

그 차이점 때문에 DOP와 달리 OOP는 캐시 라인의 특징을 최대한으로 활용하지 못한다.

캐시 라인의 특징이란, 캐시 라인이 (보통 64bytes 의) 정해진 단위로 데이터를 불러오고 저장한다는 것이다. 즉, 구조체의 총 크기가, 뭐 한 12 bytes쯤 된다고 하고 그 구조체 하나만 참조한다고 해도 캐시 라인은 똑같이 (보통 64 bytes의) 정해진 단위로 데이터를 불러온다.

만약 지역성의 원리가 정말 형편 없이 지켜지고 있다면, 나머지 데이터는 모두 정크다. 캐시 미스를 줄이는데 도움이 되지 못한다. 반면 만약 지역성의 원리가 제대로 지켜지고 있다면, 나머지 데이터는 정크가 아니며 캐시 미스를 줄이는데 큰 도움이 될 수 있다.

예를 들어보자. f(arr)이라는 간단한 함수가 있어 그 함수는 배열을 하나 입력 받고 각 원소들에 1의 값을 더한다고 하자.

f(arr) {

for val in arr {

val += 1

}

2개의 배열이 있다. arr1과 arr2는 모두 똑같은 숫자의 원소를 가지고 있지만, arr1의 원소들은 메모리 주소상으로 찰싹 달라붙어 있고 arr2의 원소들은 메모리 주소상으로 사방에 흩어져 있다.

f(arr1) {

for val in arr1 {

val += 1

}

<=>

f(arr1) {

arr1[0] += 1

arr1[1] += 1

arr1[2] += 1

arr1[3] += 1

}

이 경우, f(arr1)은 첫번째 구문 arr1[0] += 1을 처리할 때 arr1[0]이 캐시에 이미 올라와 있는지 확인한다. 없다고 가정하면 캐시 미스가 뜨고 arr1[0]을 램에서 참조해 캐시에 올린다. 이때 arr1[0]의 크기는 64 bytes보다 한참 적지만, 그래도 여전히 캐시 라인은 arr1[0]과 함께 근처에 있는 나머지 데이터까지 모두 포함해 64 bytes를 함께 캐시에 올린다.

그 다음 구문 arr1[1] += 1을 처리할 때도 똑같이 arr1[1]이 이미 캐시에 올라와 있는지 확인한다. 하지만 arr1의 각 원소들은 메모리 주소상으로 서로간에 찰싹 달라붙어 있었기 때문에, 매우 높은 확률로 arr1[1]은 arr1[0]이 캐시에 올라갈 때 함께 캐시 라인에 포함되어서 캐시에 올라갔을 것이다. 따라서 캐시 히트가 뜬다.

arr2에서는 똑같은 일이 일어날 수 없다. 각 원소들이 메모리 주소상으로 멀리 떨어져 있기 때문이다. 4개의 원소 모두가 캐시 미스로 나올 확률이 높고, 따라서 램에서 데이터를 참조하는데 들어가는 150~250 cpu 사이클 정도의 시간을 매번 기다려야 한다. 제곱근 함수가 보통 30~50 cpu 사이클 정도라는 것을 감안하면 상당한 낭비다.

그동안 한 뻘짓 때문에 오늘 코드 베이스를 들어 엎다가 끄적여 본 글.

[💬] 데이터 지향 프로그래밍의 핵심

댓글 3

다른 게시글