컴퓨터 밑바닥 Chapter 5: 작은 것으로 큰 성과 이루기, 캐시

이번 장에서는 캐시에 대해서 기술하며 책의 5번째 여정입니다. 다시 복기하자면 컴파일러 -> 프로세스/스레드 -> 메모리 -> CPU에 이은 장이며, 컴퓨터가 캐싱을 하기 위한 방법과 문제에 대해서 서술합니다.

---

1. 캐시, 어디에나 존재하는 것

• CPU는 메모리에서 정보를 가져와 업무를 수행하며, 이를 더 효율적으로 수행하기 위해서 캐시를 발명
• 도서관으로 비유하면 캐시는 책상 메모리는 서고
• 캐시는 L1,L2,L3로 나눠어져 있으며 점차 그 크기가 커짐
• 가상메모리의 경우 실제 메모리보다 더 크게 설정될 수 있는데 이 경우 하드디스크에 데이터를 저장

저장 형태의 계층 구조

맥북의 경우 활성 상태 보기에서 캐시에 대한 정보를 확인할 수 있음

하단 Cached Files

이전에 인텔 맥을 사용하면서 16기가 중에 거진 15기가를 점유하고 사용하고 있었다. 맥북을 새로 구입하면서 48기가로 구입했는데 오히려 사용량이 31기가로 늘었다(거의 비슷한 환경 구성임에도) 이로 미루어 볼때, 이전에 메모리가 부족해서 로컬 스토리지(SSD)에서 끌어다 쓰고 있다는 사실을 알게되었다.

궁금증1) 파이썬 데이터 처리 메소드 pd.read_csv는 메모리에 저장할까 캐시에 저장할까?

• 메모리에 저장한다. `info()`, `memory_usage()`로 확인 가능하다

궁금증2) 최근에 채점 서비스를 개발하면서 streamlit 프레임워크(파이썬 프론트엔드)에서 데이터를 저장하는 것을 캐싱으로 제안받았는데 이게 뭘까?

https://docs.streamlit.io/develop/api-reference/caching-and-state/st.cache_data

• 기본적으로 streamlit은 메모리에 데이터를 저장하며 캐싱을 통해 데이터를 추가로 불러올 필요없이 사용할 수 있다. "캐싱"이라는 방법을 쓰는 것이지 앞에서 서술한 캐시-메모리의 구조를 분할하여 쓰는 것은 아니다.

2. 어떻게 캐시 친화적인 프로그램을 작성할까?

• 시간적 지역성
  • 프로그램이 메모리 조작에 접근하고 나서 다시 여러 번 참조하는 경우
  • 캐시 친화성이 높아 캐시에 있는 데이터를 적중할 확률이 높음
• 공간적 지역성
  • 인접한 메모리도 참조하는 경우
  • 링크드리스트 자료형의 경우 배열 arr자체는 콜드 데이터(자주 참조하지 않음)이며, next 포인터와 value 값은 핫 데이터(탐색 과정에서 자주 참조함)

3. 다중 스레드 성능 방해자

프로그램에서 데이터를 접근하면 다음에 인접한 데이터에 접근할 가능성이 높음(공간 지역성) 따라서 묶음 데이터를 저장하는 개념이 등장

• 캐시 라인: 캐시 메모리에서 데이터를 저장하고 전송하는 기본 단위. CPU가 데이터를 가져올 때 아키텍쳐에 따라 32, 64, 128 바이트씩 가져옴
  
  

단일 프로세스에서의 캐시라인

멀티 프로세스 상에서의 캐시라인

https://jungwoong.tistory.com/42

[windows] 멀티 프로세서 환경에서의 CPU 캐시라인

또한, 다중 프로세스스에서 하나의 메모리 값을 가지고 동기화 되지 않는다는 문제가 DDIA에서 마주했던 분산 처리시스템의 문제와 똑 닮아서 역시 다중 포인트의 의사소통 문제는 늘 해결해야하는 이슈가 많아지는구나 라고 생각했다.

• 캐시라인의 문제 
  1. 캐시 튕김
     • 멀티 스레드를 사용한다고 속도가 빨라지진 않음. 
     • 캐시 일관성 때문에 데이터가 업데이트 되었을 때, 타 스레드의 값을 무효화시키는 작업으로 오히려 더 오래 걸리는 현상
  2. 거짓 공유
     • 동일한 캐시라인에 두 스레드가 접근함으로써 스레드 각각이 데이터를 공유하지 않는 것처럼 보여도 캐시 라인을 공유하는 현상
     • 중간에 사용되지 않는 더미데이터(dummy)를 삽입하여, 캐시라인을 구분되게 만들면 성능향샹