컴퓨터 구조 - 고찰편

 

 

물병에 물을 가득 따르는 가장 쉬운 방법은 물을 넘치도록 따르는 것입니다. 저는 공부도 같다고 생각합니다. 당신이 어떤 시험에서 정녕 100점을 맞기 위해서는 100점에 필요한 노력에 더한 노력 또는 그에 상응하는 지식의 습득이 이루어져야 합니다. 가득 차 흘려버린 물은 가득 따르기 위한 오버헤드임을 깨달아야 합니다.

 

서론

충남대학교 컴퓨터 구조 (김형식) 교수님의 수업을 들으며, 이번 학기에 배운 내용을 요약하자면, 컴퓨터는 성능을 위해 굉장히 많은 부분을 하드웨어가 취약하게 만들어버렸고, 그럴 수 밖에 없었고, 그것에 대한 책임을 소프트웨어와 OS에 위임했다는 것입니다.

 

물론 그런 내용을 가르치지는 않았지만, 그냥 제가 이걸 얻어갔을 뿐입니다. 선을 넘어서 탐구한 내용들을 좀 적어보는 시간을 가지도록 하겠습니다.

 

문제

1. 데이터 하자드를 막기 위해, Forward를 사용했다. 이것은 만능인가? Forward Path를 많이 뚫으면, CPU 클럭 속도는 어떻게 변하겠는가?

Forward를 사용할 때, 우리는 ALU나, 데이터가 필요한 다음 인스트럭션의 일부에 데이터를 바로 넘겨줌으로써, Forward를 행했습니다. 그럼, 이때, Control Unit은, 모든 Instruction들을 기억하여, MUX등을 사용해, ALU나, 로드에 사용되는 값들을 적절하게 갈아 끼워야합니다. 이때, 생각보다 Forward Path를 많이 뚫으면, MUX는 기하급수적으로 커지게 됩니다. 따라서, Critical Path가 길어져, CCT를 늘릴 수 밖에 없습니다.

 

2. 2024 시험의 ADD AND BNE 만 지원하도록 DataPath를 최적화 하는 것은 임베디드 시스템이나 특수 목적 프로세서를 설계할 때 자주 합니다. 회로를 줄여서, DataPath가 짧아지면, CCT는 무조건 빨라지게 설계할 수 있나요?

파이프라이닝 단계에서 일부 instruction의 기능을 제거하여, DataPath를 더욱더 간결하게 만들고 최적화 해도, 메모리에 접근하는 시간이나, 레지스터에 접근하는 시간 등 각 PipeLine 단계의 가장 느린 시간에 맞추어 CCT를 결정해야합니다.

 

3. Cache Block Size를 무작정 크게 하면, Cache Hit Ratio가 계속 올라가나요? False Sharing 이나, Cache Pollution이 시스템에 얼마나 악영향을 끼치는지, 멀티 쓰레딩 환경에서 서술하세요.

계속 올라가지 않습니다. 크기가 고정된 캐시 메모리에서 Cache Block Size를 늘린다면, Block Index가 줄게되어, race가 심화됩니다. 따라서, Miss가 더 자주일어나게 되어, Hit Ratio가 올라가지많은 않습니다. 즉, 한정된 공간안에서, 시간적 지역성과 공간적 지역성은 서로 Trade-Off 관계가 있습니다. 이것은 cache Pollution에 대한 설명과도 밀접합니다.

블럭의 크기가 크면, 쓸모없는 데이터도 캐쉬로 딸려들어와, 캐쉬의 공간을 낭비 할 수 있습니다.

 

False Sharing 이란, 다중 코어 환경에서 서로의 코어에 저장된 cache를 계속 메모리로 write하게 만드는 경우를 말합니다.

서로의 코어가 같은 캐쉬 블럭을 자꾸 접근하고 write해야한다면, cache coherence를 지키기 위해, 메모리에 블럭을 write -back 하거나, cache를 비워야합니다.

 

따라서, 개발자는 이러한 컴퓨터 구조를 이해하고, 다중 쓰레드 환경에서 주로 사용되는 변수들이 분리되어있을 경우, 캐쉬 블럭 크기만큼 패딩을 넣어, 변수들을 논리적으로 분리해야합니다.

 

4. 인텔은 한때, 펜티엄 4에서 31단계까지 파이프라인을 쪼개서 4GHz를 달성하려 했습니다. 왜 현대 CPU는 다시 파이프라인을 10~15단계까지 내렸을까요?

이것은 논리회로의 지식을 살짝 사용합니다. 래치는 기본적으로 값을 바꾸라고 값이 와도, 값이 정말 저장되기 까지, 살짝의 오버헤드가 존재합니다. 

이해가 쉽도록, 래치의 오버헤드가 특정 전압에서 1ns에 도달했다고 합시다. 파이프라인을 어느정도까지 쪼갰더니, 각 파이프라인단계에서 2ns수준의 지연이 걸리게 되었습니다. 그럼 사이클은 3ns정도가 적당 하겠습니다.

 

이것을 더 개선하기 위해, 파이프라인을 더 쪼갠다고 했을 때, 엔지니어링 관점에서 이게 옳은 일일까요?

 

우선, 파이프라인을 더 쪼개서 개선을 한다고 해도, 이제는 더이상 극적인 성능향상을 보장할 수 없습니다.

또한, 파이프라인이 늘어나면 래치가 더 필요하게 됩니다. 래치는 생각보다 전력을 많이 잡아먹기 때문에, 이런식으로라면, 회로가 타지 않게, 회로의 일부를 완전꺼야하는 Dark Silicon으로 이어지게 됩니다.

 

따라서, 파이프라인을 늘리고 래치의 오버헤드를 줄이기 위해 전압을 더 쌔게 거는것은 엄청난 비효율이 되었습니다.

어느정도 전압을 더 올리고, Dark Silicon을 없애기 위해, 파이프라인을 줄이는 방식으로 발전하게 되었습니다.

 

추가로, 분기 예측 실패에 대한 비용이 파이프라인 절차에 따라 증가했고, 파이프라인을 늘리는 것은, 엔지니어링 관점에서 무척 어려운 일입니다. 수많은 래치에 도달하는 클럭신호의 타이밍 마진을 0으로 수렴하게 만드는 것은 무척 어렵고 위험합니다.

 

5. 64비트 시스템은 가상주소를 매핑 할 때, 4나 5계층의 테이블을 사용합니다. 그럼 물리주소를 알아내기 위해 메모리를 4-5번 접근해야하는 오버헤드가 생깁니다. 이에 서버나 데이터베이스 시스템은 4KB 대신 2MB or 1GB의 Huge Page를 사용합니다. 왜 사용하는지, 또한 우리의 커널은 왜 4KB를 페이지 크기로 잡았는지 서술하세요.

우선 서버와 데이터베이스는 TLB를 최대한 이용하기 위해, 큰 Page를 사용합니다.

그러면, TLB가 커버하는 실제 데이터 영역이 굉장히 커지기 때문에, miss를 최소화 하는 방법 중 하나입니다.

우리의 커널이 4KB로 잡은 이유는, 경험적 결정입니다. 프로그램이 마다 내부 파편화를 격고, 적당히 디스크에 swap을 진행하면서, page fault를 처리하고 하는것에 있어서, 실험적, 경험적 결정으로 4KB가 가장 적절하다고 판단했기 때문입니다.