우리는 프로그램을 개발할때 메모리는 무한하다고 가정한다

![실제 메모리는 한정적이지만, 논리적으로 무한으로 가정한다

즉, DRAM을 캐시처럼 쓰고 로직을 메인메모리를 쓴다](https://prod-files-secure.s3.us-west-2.amazonaws.com/09ccd4d5-876c-4bba-bbdf-cc77a0a11257/33a118c9-a848-4546-8df6-70f13d20210a/Untitled.png)

실제 메모리는 한정적이지만, 논리적으로 무한으로 가정한다

즉, DRAM을 캐시처럼 쓰고 로직을 메인메모리를 쓴다

• 공간과 연산이라는것은 항상 교환할 수 있다
  • 구구단 → 계산을 기억으로 바꾸듯이
• 그래서 VM이라는 개념을 추가했다

버추얼 메모리 컨셉

• Virtual Memory : 메인메모리 역할
• DRAM : 캐시메모리 역할

자주 액세스 하는 놈들은 DRAM 에 맵핑해두자! (진짜 캐시취급..)

DRAM보다 VM이 커도 코드실행이 가능한 이유

DRAM보다 더 큰 메모리가 있다고 가정

역시 로컬리티를 프로그램이 아무리 커도 액세스하는 메모리는 로컬리티의 룰을 따르게된다

<u>[**액세스가 자주일어나는 부분만 연결되니까!**](https://cybecho.notion.site/1651f9fda32e4e60be009b91e686e6d4)</u>

그래서 논리메모리는 무한으로 설정해두고, 전체 프로그램중에서 자주 사용하는 코드들만 DRAM에 가져와 프로그램을 실행시키는 것이다

그래서 우리가 블렌더를 할때, 뷰포트에서 모델링하는 속도가 렌더링하는 속도보다 빠른 이유는 뷰포트는 자주 사용하는 코드니까 VM의 캐시역할인 DRAM속에 들어와있고, 렌더링 코드는 자주 사용하지 않으니까, 사용할때만 DRAM에 불러와서 뷰포트보다 느린거임

PC값은 결국 Virtual Memory의 주소가 된다

• 그럼 실제 물리 주소 맵핑은 어케함?

• CPU에서 직접 수행해줌 - Translation

  

  [VM] - Translation

VM은 [Fully associative](https://cybecho.notion.site/Fully-associative-540ca7d434ab45b4a2c8646f812363cd) 를 따른다 즉, INDEX가 없다는 소리

Fully associative

그냥 한 세트로 묶어버리고, 먼저 들어온놈이 앉도록 함.

이러면 자리를 두고 싸우진 않을거아냐?

예전엔 1입구에 1자리여서 싸우는거였는데

지금은 1입구에 n자리여서 자리쟁탈전은 없음

0
1
2
3
4
5
6
7
8
9

<aside> 💡 근데 Fully associative 에서는, 방이 꽉차면 누가 먼저 나가는가? - LRU 다음 문제로

LRU 방식으로 문제를 해결하지 않았나?

엄청나게 큰 페이지를 LRU로 해결하면 오히려 Hit율이 줄어드니까, VM을 효율적이게 구성하는것은 쉬운일이 아니다

</aside>