pipelining

Written by Keith
on 

컴퓨터 구조를 이공계 학부에서 다 배운다. 웃긴 건 이미 중학생 혹은 초등학생이면 쉽게 이해하는 부울대수를 하느라고 많은 시간을 까먹고 정작 중요한 컴퓨터 아키텍쳐는 학기 말에 하다가 어영부영 끝내버린다는 거다. 교수마다 가르치는 방법이 다르긴 하겠지만 적어도 내 경우는 그랬다.

그러니까, ALU까지는 그냥 단숨에 건너뛰어도 되는 걸 거의 학기의 2/3를 초등학생도 이해하거나 잘 알만한 토픽으로 채우면서 시간을 낭비한 거다. 지금 생각하면 교수라는 사람 자체가 computer architecture를 가르칠 능력이 없다보니 겨우겨우 자기가 아는 수준의 토픽만 커버하려고 보니 그런 짓을 해버린 거다.

지금의 세상은 HDL로 CPU 정도는 매우 쉽게 설계할 수 있고, 그것으로 기존의 게임 같은 것들 (사실 이게 가장 좋은 활용 예라고 나는 생각한다)을 포팅해서 그 설게가 좋았는지 아닌지까지 시뮬레이션해 볼 수 있다. 물론 에뮬레이션도 가능하다. 쓸데없는 부울 대수 따위는 그냥 개나 줘버리고 곧바로 8085나 6502(혹은 z80)로 시작해서 학기 말에는 이들 아키텍쳐를 개량한 processor model을 가지고 컴퓨터를 에뮬레이션해서 누가 누가 더 좋은 아키텍쳐로 개량을 했는지를 가지고 점수를 먹일 수 있는 수준은 되어야 되는 것 아닐까 하는 거다. 적어도 그래야 ‘컴퓨터 아키텍쳐’를 배웠다고 할 수 있는 것 아닐까? 21세기에 컴퓨터 아키텍쳐를 배운다며 바보같은 bool algebra나 한다든가 무슨 karnaugh map 따위 계산으로 gate수를 줄이는 짓을 하면서 시간을 버릴 게 아니라 말이다.

지금 이 세상에서 요구되는 것은 새로운 것을 만들어내는 창의적인 아이디어지 원시인들이 어떻게 물건을 샜는지 따위의 것들을 되세김질해야 하는 것이 아니니까. 지금 누가 logic circuit를 수동으로 설계해서 만들고 그것을 TTL로 만들고 있을까? 이것은 70년대, 그러니까 워즈니악이 아주 젊었을 시절에나 하던 짓이다. 그러니까 고급 개념에서 시작하면 더 나은 상위의 개념으로 발전할 수 있는데, 교수나 강사 또한 아는 것이 없으니 가나다라도 아닌 한글의 창제방법부터 따지고 들어가는 것이다.

어쨌든 컴퓨터 아키텍쳐에서 내가 새롭게 배운 개념은 pipelining이다. 이게 뭐냐면 하나의 복잡한 일을 최소단위로 잘게 쪼개놓고 그 최소단위가 한꺼번에 동시에 처리되도록 만들어놓으면 initial latency는 그 최소 단위의 개수만큼 생겨나지만 그걸 제외하면 사실상 그 복잡한 일을 1클럭에 수행할 수 있다는 것으로 이해하면 된다. 이렇게 말하면 이해하지 못할 수도 있는데, 용어가 똣하는 것처럼, 이를테면 초코파이를 찍어내는 공장에서 매 단위시간에 완료될 수 있는 양으로 일을 쪼개서 직렬로 늘어놓으면 이 파이프라인(콘베이어 벨트?)에서 매 단위시간에 한개씩의 초코파이가 얻어진다는 뜻이다.

그러니까, 예를 들어 혼자서 초코파이를 만드려면 10시간이 들어가는데, 이 과정을 1분 단위로 잘라서 600 개의 스텝을 두어 직렬로 생산라인을 가동시키면 1분에 한개씩 초코 파이를 얻게 된다는 거다. 물론 최초로 생산된 초코파이는 10시간이 지나야 나오게 되지만, 그 다음부터 얻어지는 것들은 파이프라인에 문제가 없다고 하면 1분에 한개씩 얻어지게 되는 것이다. 그러니까, 쉽게 알고 있는 병렬처리 과정을 직렬화 해놓은 것과 같다. 참고로 병렬로 600명을 고용해서 일을 시킨다고 하면, 단위 생산 주체에서 얻어지는 초코파이는 10시간에 1개이니까 매 10시간마다 600개의 초코파이가 얻어지는 것과 같다. 이 과정에서도 초기 latency는 10시간이니까 pipelining가 다를 바 없고, 얻어지는 thoughput도 600/10시간으로 같다. 그러나 파이프라인으로 만드는 것이 같은 하드웨어를 600개 사용하지 않아도 되니까 하드웨어의 복잡도가 줄어드는 장점을 가지고 있다.

여기서 생각할 수 있는 중요한 것은 어떤 일을 pipeline으로 해야하고 어떤 것을 parallel로 해야하는가를 직관적으로 구분하는 것이고 어떻게 일을 나누어야 pipelining을 하기에 좋은가 하는 것이다. 이것은 실제로 하드웨어를 구현해 본 경험이 없으면 할 수 없는 일이긴 하지만 이것을 이해하기 위해서 꼭 하드웨어를 구현해야 할 이유는 없다.

단지 여러 개의 instance를 병렬로 늘어놓느냐 직렬로 늘어놓느냐, 복사하느냐 아니면 기능이 다른 것으로 직렬 연결하느냐의 차이가 존재할 뿐이다.