[Chapter5] 작은 것으로 큰 성과 이루기,캐시

[yunseorim1116]

감상평을 남겨주세요~
범위: 섹션 5.1-5.5 (끝까지)
8/3 11시 전까지~! ^ㅇ^

[yunseorim1116]

가장 흥미로울 것 같은 파트라고 생각했는데 막상 읽어보니 난해한 파트였던.. 하지만 읽으면 읽을 수록 흥미로운 내용이 많아 저번 파트보단 재밌게 읽었다! (그치만 네 가지 메모리 장벽에서 와르르 무너져버렸다. 정신을 차리고 다시 읽으니 읽을만 했다……. 아니 아닐지도…)
책 내용보단 그 주의 컨디션에 따라 감상이 달라지는 것 같아서.. 이번 주는 읽을 시간이 충분해서 더 재밌게 읽었던 것 같다.

정리링크

[sa02045]

1. 프론트엔드 개발을 하면서 캐시에 대한 지식은 HTTP Cache-Control, Tanstack Query 같은 라이브러리에서 제공하는 캐시기능 정도로만 알고있었는데요. 좀 더 캐시에 대한 근본적인 내용을 배울 수 있었고 이해를 도왔던 것 같습니다.

• �일단 캐시를 업데이트해서 사용자 경험을 증가시키는 낙관적 업데이트는 write-back(후기입) 캐시 갱신방식과 비슷해보였습니다.
• 프론트엔드에서 많이 사용되는 stale-while-revalidate 전략도 생각이 났습니다. 오래된 캐시 값이라도 일단은 사용자 경험을 위해 사용하고 나중에 최신 데이터로 교체한다라는 전략으로 데이터 정확성보다는 사용자 경험을 중요시하는 프론트엔드의 관심사를 알 수 있습니다.

2. 캐시 친화적인 프로그래밍을 하는 방법을 알 수 있었습니다. (자바스크립트 언어에서 실용적인지는 모르겠네요)

• 덜 사용하는 콜드 데이터는 분리하여 포인터로 가르켜라
• 메모리 풀을 사용하여 캐시 지역성을 잘 지키도록 노력하라
• 코드 순서가 달라져도 캐시 지역성이 달라질 수 있다. (다차원 배열에서도 조심하라)

3. 캐시를 사용하면 발생하는 각종 어려운 문제들도 알 수 있었습니다.

• 캐시 튕김 문제: 다중 스레드라고 단일스레드보다 항상 빠른 것은 아니다.
• 다중 프로그래밍에서 캐시를 사용할 때 발생하는 문제 (다중 코어 캐시 불일치문제)
• 거짓 공유 -> 두 스레드가 공유 데이터를 사용하지 않더라도 캐시라인 때문에 데이터를 공유하는 것처럼 보이는 문제

4. CPU는 항상 코드를 순차적으로 실행하지 않는다! 라는 점이 매우 흥미로웠습니다. CPU는 효율을 위해 "부정 출발"한다는 것
   • 다른 코어가 어떤 코어를 바라볼 때 비순차적인 순서로 실행하는 것처럼 보이는 현상
   • 명령어 재정렬 문제 => 메모리 장벽로 해결
     • 해결하는 방법은 쪼오금 어려워서 한번더 읽어야할 것 같은..
     • 단일 스레드 환경에서 프로그래밍하는 JS가 고마워지네요

[ella-yschoi]

감상평

• 물론 흥미로운 파트도 있긴 합니다만,, 후반으로 갈수록 어려워지는 건 저만 느끼는 걸까요? (아니겠지? 아닐거야..😖)
• 이번 챕터는 이해가 어려워 여러 번 읽느라 시간이 오래 걸렸습니다.
• 캐시에 대해 잘은 몰랐어서 이번 챕터가 꽤 유익했어요! 예를 들어 이런 글이 조금이나마 다르게 보입니다.

5.1장: 캐시, 어디에나 존재하는 것

• 캐시의 필요성을 CPU와 메모리 간 속도 불일치 문제부터 설명해 주어 이해가 쏙쏙! 되었습니다. 생각보다 소듕한 존재였군요..
• 성능을 개선시키는데에는 대가가 따르고, 또 개선시키려면 또 다른 대가가 따르는군요. 역시 기술 선택에는 정답이 없는듯 합니다.
• 중간에 디스크 이야기가 나오면서는 어려워서 머리가 지끈했습니다만, 어쨌든 핵심은 마지막 문단에 있는 것 같아요.
• 컴퓨터 저장 체계의 각 계층이 다음 계층에 대한 캐시 역할을 한다, 캐시의 설계 사상은 필수불가결하다. 그러니 꼭 필요하다!
• 초반에 언급된 나무통 원리가 궁금해 찾아봤습니다. 재미삼아 읽어보세용 🤓

인터넷의 검색 속도는 컴퓨터, 모뎀, 회선 중 가장 성능이 떨어지는 수준에서 결정된다. 인터넷 회사가 100메가 속도의 광랜을 공급해도 마지막 컴퓨터가 있는 집의 구조가 낡아 문제가 있다면 최신의 기술인 광 랜도 무용지물이 된다. 또한 인간 경쟁력은 나무 물통 판 하나하나가 인품, 성격, 실력, 사회성, 건강, 도덕성으로 되어 있다. 따라서 아무리 실력이 뛰어나도 도덕성이 낮다면 그 낮은 도덕성에서 인간에 대한 평가가 이루어진다.

5.2장: 어떻게 캐시 친화적인 프로그램을 작성할까?

• 캐시 친화적이라는 것이 공간적 시간적 지역성을 통해 메모리 접근 패턴을 '예측 가능하게 만드는 것'과 밀접하다고 생각했습니다.
• 캐시가 규칙적 반복적, 인접하게 메모리에 접근하려면 ’아 메모리가 저기에 저 때 있겠구나‘ 하는 확신과 안정을 주어야 하니까요. 🍀
• 그리고 똑같은 배열을 순회해도 열을 우선하느냐 행을 우선하느냐에 따라 차이가 발생하는 게 흥미로웠습니다.

5.3장: 다중 스레드 성능 방해자

• 다중스레드 프로그램의 성능이 좋지 않은 예시를 보며.. 하나 키우는 것보다 쌍둥이 둘 키우는 게 더 어렵고 힘들다....(?👶🏻👶🏻)
• 그림 5-30 두 변수 사이에 사용되지 않는 데이터를 채우거나 변수 순서를 조정하면 다중 스레드 프로그램 성능을 개선할 수 있다는 게 흥미로웠습니다. 하지만 코드의 전체적인 맥락을 모르는 사람이 봤을 때는 왜 이 데이터가 여기 있지? 할 것 같아 실 사용에는 조금 의문입니다.
• 5.3.2에선 '캐시 튕김'을 'cache line bouncing'이라 하던데, 각종 자료에서 cache thrashing, cache line bouncing, cache snooping, cache invalidation 등 여러 용어로 쓰이더라고요. 찾아보니 가장 흔히 사용하는 용어는 책처럼 'cache line bouncing'이라고 합니다. 깨알지식!
• 캐시라인(묶음 데이터)의 목적은 "네가 원하는 게 뭔지 몰라 다 준비해봤어. 필요한 게 있으면 골라봐 ✅" 인 것 같아요.
• 예를 들면.. 어떤 루프에서 배열의 요소들을 순서대로 접근한다 했을 때 캐시 라인이 없다면, 각 배열 요소에 접근할 때마다 메모리에서 데이터를 가져와야 하니 성능이 저하될 수 있잖아요.
• 하지만 캐시 라인을 사용하면, 예를 들어 64바이트의 캐시 라인을 사용하는 경우, 한 번의 메모리 접근으로 배열의 여러 요소(e.g. 16개의 4바이트 정수)를 한꺼번에 가져와서 이후 반복에서 다음 요소에 접근할 때 이미 캐시에 존재하므로 캐시 히트율을 높일 수 있을 것 같아요.

5.4장: 봉화희제후와 메모리 장벽

• 앞에서는 분명 '부정 출발' 형태가 CPU 성능을 높일 수 있어 좋다고 했는데, 메모리 장벽은 부정출발 형태로 먼저 실행되는 것을 방지한다고 해서 읭? 했습니다. 알고보니 메모리 장벽은 성능을 약간 저하시키더라도 메모리 일관성 보장을 위해 필요하다고 하더군요. 실행 순서가 예측 불가능하거나, 잘못된 데이터를 읽으면 심각한 버그를 초래하니까요. 약간의 타협으로 리스크를 방지하는 느낌? 🤔
• 주유왕 스레드와 제후 스레드로 설명한 부분은 코드가 재밌네용.. 덕분에 잘 이해했습니다.
• 하지만 뒤의 내용은.. 어질어질하네요. 메모리 장벽 개념을 이야기 하기까지 굉장히 많은 양의 정보를 흡수해야해서 힘들었어요.
• 어쨌든 메모리 장벽이 필요한 이유는 부정출발 및 재정렬 방지, 비동기 처리, 최신값을 얻기 위한 목적 정도겠군요.
• 마지막으로, 메모리 장벽 내용이 한 눈에 들어오지 않아 네 가지 메모리 장벽 유형을 표로 정리해 보았어요. (Thanks to GPT🤖)

메모리 장벽	설명	목적
LoadLoad	Load1이 Load2보다 먼저 실행	데이터 레이스 방지, 읽기 순서 보장
StoreStore	Store1이 Store2보다 먼저 실행	쓰기 순서 보장 (단, 최신값 보장은 X), 메모리 일관성 유지
LoadStore	Load1이 Store2보다 먼저 실행	읽기 후 쓰기 순서 보장, 데이터 안정성 유지
StoreLoad	Store1이 Load2보다 먼저 실행	쓰기 후 읽기 순서 보장, 동기 작업, 강한 장벽, 성능에 영향 다중 프로세서 시스템에서 쓰기 이후 다른 프로세서의 읽기를 일관되게 유지 시 사용

[thgr8ganzi]

감상평

• 캐시가 왜 생겼는지, 어떵게 사용하는지, 어떻게 해야 문제가 없는지 전반적으로 캐시에 대해 훑을수 있는 단원
• 사실 직접적으로 캐시를 사용해본적이 없어서 전체적인 흐름만 이해 할수 있었다.
• 캐시를 사용해봐야 아 그때 읽은게 이거 구나 할듯

[iborymagic]

어떵게 사용하나요?

[bigsaigon333]

• 싱글스레드에서 주로 작업하다보니 좀처럼 접할 수 없는 다중스레드 환경에서의 문제점들이 흥미로웠습니다.
• 내가 작성한 단순한 변수 선언, 로직들도 캐시 적중률에 영향을 미칠 수 있다고 생각하니 프로그래밍 언어 차원에서 어디까지 추상화를 제공해야 하는 걸까 하는 생각이 들었습니다

[iborymagic]

• 캐싱은 그냥 속도 차이를 좁혀주어 성능을 개선해주는 역할~ 정도로만 추상적으로 자리잡고 있었는데, 캐싱에 의해 오히려 성능이 반감될수도 있다는 사실이 중요하게 다가왔읍니다..
• 다양한 방면에서 캐시 친화적인 프로그래밍을 고려해볼 수 있다는 사실이 흥미로웠네요.. 매우 흥미로웠지만 실제로 신경 쓸 일이 있을까 싶긴 했읍니다..
• 5.4절은 사실 이해하기가 좀 어려워서 빠르게 훑었는데, CPU가 코드를 순차적으로 실행하지 않는다는 사실이 꽤나 놀라웠읍니다..
  • 생각보다 내가 알지 못하는 부분들에서 다양한 최적화들이 적용되어있다는 사실..
  • 하드웨어가 빠른 시일 내에 충분히 영리해져서, 5.4의 다양한 기술들이 빨리 역사의 뒤편으로 사라지길 간절히 고대해봅니다.
  • 5.4절은 마지막에 네 줄 요약만 기억해야겠읍니다..

[ddongule]

감상평

캐시에 대해서는 잘 쓰면 속도 빠르게 해줘서 더 좋은 사용자 경험을 만들어주는 친구라고만 생각했었는데 역시나 내가 생각했던것보다 훨씬 복복잡잡한 친구였다는 것을 알게되었따.
봉화희제후는 무섭다.

[sunhpark42]

캐시 승희님이랑 얘기했던 열우선 이런게 나와서 재밌었다.
캐시와 동시성.. 성능을 위한 멀티 프로그래밍 역시 똑똑한 사람 넘 많다
로드로드 스토어스토어.. 완전직관적

[chloe-codes1]

감상평

• 캐시를 사용할 때 메모리를 디스크의 캐시로 사용하는 방식으로만 사용해와서 이 부분의 동작이 익숙했는데, CPU <-> 메모리 간의 캐싱에 대해서도 정리해 볼 수 있어 좋았다
• 스프링의 ‘@Cacheable’ 어노테이션으로 간단하게 캐시를 사용해 왔는데, 내부적으로 동기화 매커니즘이 구현되어 있어 신경쓸 부분을 줄여준 것이라는 사실을 알게됐다. 고마워…