[눈범이 진실 3] GCD: Grand Central Dispatc -2부-

September 03,2009                      hit:(6644)

Link#1 : http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/12
Link#2 :
1부에서 Grand Central Dispach의 도래와 관련해 병렬 컴퓨팅의 시조 격인 Be를 들춰봤고 멀티코어 칩셋을 활용하기 위한 애플의 노력이라고 할 수 있는 2가지 특별한 형태의 API를 짚어봤습니다. 자세하게는 저도 모릅니다. 이해가될리가 없죠...ㅋㅋ 다만, 이런 API의 준비가 프로그래머들에게 차원높은 GCD를 활용하기 위한 멍석을 제공했다는 정도로 이해했습니다. 그 첫째 API를 보면 로우레벨 프로그래밍에서의 지금까지 사용해온 프론트엔드의 GCC 4.2를 새로운 방식의 Clang으로 이주를 시작했으며 백엔드는 GCC 와 Clang 모두를 받아들일 수 있는 LLVM의 구조를 갖는 거죠. 두번재 API는 애플에서 미리 만들어 놓은 Block이란 것입니다. 100여가지 이상을 이미 준비했다고 하며 이 명령어 집합체를 이용해 역시 빠르고 단순한 프로그래밍의 구현을 가능케 하고 있습니다. 이런 애플의 시도가 스노우에 적용되면서 프로그래머들은 보다 효율적이고 단순하면서도 빠른 소프트웨어의 제작이 가능해졌습니다. 무엇보다 이런 API가 스노우용 프로그램을 제작하도록 써드파티 프로그래머를 유인하는 것이죠. 편하고 질높고 성능좋은 소프트웨어 만드는게 그들의 일 아니겠습니까.

그리고 이제 이런 자원을 바탕으로 그랜드 센트럴 디스패치(GCD) 활용이 가능해지는 것입니다. GCD는 절대 애플 혼자 가능한게 아닙니다. 일단 하드웨어분야에서 멀티코어 씨퓨를 만들어 놓고 바탕을 제공하고 있으며 오에스차원에서 이런 자원을 활용할 수 있도록 프로그래머들에게 배려를 해주는 것입니다. 다름아니라 결과물에서 소비자가 이득을 보지만 하드에어/눈범/소프트웨어 개발자가 하나의 작품을 만들어내면서 전혀다른 컴퓨팅 환경을 만들어가는 것으로 봐야겠죠. 물론 Be 같은 회사에서 이전에 시도했지만 저변화되진 못했고 다만 애플은 이제 적절한 시기에 적절한 운영체제와 적절한 신기술을 소개하는 것으로 미래를 도모하는 것입니다.

--------------------------------------------------------

GCD

눈범이의 그랜드 센트럴 디스패치는 멀티코어 씨퓨 활용에 있어서 지금까지 프로그램머들이 직면해있던 "명령계통의 동시 실행 문제"(Concurrency Conundrum)를 해결해주는 열쇠다. 마치 서울역 중앙 통제 센터라는 적절한 뜻을 의미하는 GCD는 사실 이해하기 쉬운것은 아니다.

소프트웨어 어플리케이션이 멀티코어 씨퓨를 활용하기 위해선 쓰레드(Thread)라고 불리는 코드작업이 요구된다. 개발자들은 쓰레드를 통해 멀티코어 프로세서가 설계된 대로 동시간대에 여러가지 수행명령을 각기 다른 코어에서 효율적으로 실행될 수 있도록 만들 수 있다. 하지만 쓰레드 기법은 그동안 너무나 어려운 프로그래밍 작업으로 알려져왔고 이 때문에 개발자들이 기피하는 분야이기도하며 지금까지 하드웨어에서의 멀티코어 체제를 제대로 활용하지 못했던 이유기도 하다.

스노우의 GCD가 등장하면서 개발자들은 이제 어려운 쓰레드 기능을 더이상 만들 필요없어졌으며 자신들이 만드는 어플리케이션이 하드웨어 자원을 100% 이상 활용할 수 있게 됐다. GCD가 가져온 차이점은 쓰레드가 각기 다른 어플리케이션 개발자에 의해 만들어지는 것이 아니라 오에스 차원에서 제공된다는 것이다. GCD를 활용하도록 만들어진 어플리케이션을 살펴보면 입력되는 명령수행작업이 자동으로 각 코어에 할당돼 가장 효율적인 결과물이 나오는 것을 알 수 있다. 또 GCD가 가동될때와 그렇지 않을때가 분명하게 구분된다. 따라서 하드웨어상에서 오버로드가 걸릴 이유가 없다. 또 개발자는 맥에서 제공하는 Xcode를 이용해 GCD를 활용하는 프로그램을 하기만 하면된다. 간단하다.

GCD가 새로운 코코아 기반의 프레임워크는 아니다. 이것은 맥 OS X에서 가장 기초가 되는 로우 레벨의 순수한 C 라이브러리 구조다. 써드 파티 개발자들이 GCD를 이용하기 위해 어플리케이션별로 새로운 라이브러리 링크 작업을 할 필요가 없다. GCD가 C 라이브러리란 의미는 모든 C 랭귀지와 이를 지원하는 변종 Objective-C, Objective-C++, 그리고 C++ 등을 자유자재로 사용할 수 있다것과 같다.

Queues & Thread

GCD는 알고보면 아주 단순한 기반위에서 만들어졌다. 프로그램에서 각 명령의 실행대기를 의미하는 Queues 부터 시작해보자. GCD는 FIFO(First In, First Out) 명령실행 체계를 그대로 사용한다. 대기(Queue)하고 순서에 따라 입력(Dequeue)되는 것이다. FIFO는 간단히 말해 슈퍼마켓에서 벌어지는 돈을 내려는 고객과 같다. 줄을 서서 차례대로 돈을 내고 체크아웃하며 나가는 것과 같은 이치다. Dequeue 는 명령을 수행하는 작업을 의미하는 것으로 GCD에서는 실질적인 연산작업이 벌어지는 thread(쓰레드)에 들어가는 것을 의미한다.

기본적으로 GCD는 다른 운영체제와 마찬가지로 그 시작은 FIFO를 기반으로 한다. GCD Queue가 FIFO 방식에 따라 차례대로 수행된다는 것이다. 헌데 여기서 여러가지 작업 대기중인 Queue들이 주어진 시간내에서 한꺼번에 병렬 처리가 된다. 그 병렬처리의 다이어그램이 다음 에니메이션 동영상에서 확인할 수 있다.


Grand Central Dispatch from Ars Technica on Vimeo.



에니메이션에서 보듯이 Task B는 Task A 이전에 작업완료된다. 명령수행은 FIFO 방식을 이용하지만 명령 완료는 다른다는 것을 보여주는 것이다. 또 3가지 명령이 대기상태였지만 쓰레드는 2개만 사용된다. GCD의 강력한 효율성을 설명하는 것이기도 하다. 또 쓰레드가 필요할때 나타나서 진행되고 필요없을때 사라진다. 도데체 쓰레드가 어떻게 운영된다는 것일까? GCD가 바로 각기 다른 쓰레드 집합체를 운영하며 필요할때마다 Queue를 받아서 필요한 쓰레드 기능을 작동하도록 관리하는 것이다.

이런 기능은 GCD 디자인의 핵심이라고도 할 수 있다. 현재 운영체제에서 가장 어렵다고 알려진 작업이 씨퓨의 작업성능을 유지하기 위해 주어진 특정 시간내에서 얼마나 많은 쓰레드를 이용해야하는 가이다. 너무 적으면 아이들 문제가 발생하고 너무 많은명 과부하가 걸린다. 또 관리가 되지 않으면 시스템은 스스로 필요한 쓰레드를 계산하고 어느 코어에 작업을 넣을것인가를 알아내기 위해 혼자 계산하는데 시간을 소모하게 된다.

또 지금 얘기하는 것은 한개의 어플리케이션이 작업을 수행하기 위해 몇개의 쓰레드와 코어를 사용할 것인가를 논하는 것이지만 실제상황에서 과연 시스템에서 한개의 어플만이 작동하는 것이냐 아니냐가 또한 고려돼야할 포인트다.

만약 8 코어 시스템에서 6개의 쓰레드가 작동중이라고 가정할때 4개의 새로운 쓰레드를 시작하라고 추가한다면 운영체제는 남은 2개의 코어에 4가지 쓰레드를 할당하느라 시간을 소모하며 정신없게된다. 하지만 만약 6코어에서 작동하던 쓰레드가 끝났다면 어떻게될까. 4개의 쓰레드는 곧 절반의 코어만 활용하면 되는 것아닌가.
GCD가 하는 일이 바로 이런 타이밍계산을 지원하고 고려해서 작업분배를 한다. 어느 운영체제에서도 애플 GCD와 같은 기능을 제공하지 못한다.

단적으로 말하자면 주어진 특정 시간내에서 최상의 쓰레드 조합이 가용되고 하는 것을 GCD가 모두 결정하는 것이다. 지금까지 수행돼야할 Queue들이 기둘리고 기둘려서 하나하나 처리되는 것과 달리 처리시간을 인지하고, 쓰레드 수를 조정하고 각 쓰레드를 적절하게 코어에 분배하는 등의 작업을 GCD가 마치 생각하는 사람처럼 진행시켜주는 것이다.

프로그래머가 해야할 일은 씨퓨에 작업할당 방법을 계산해내는것이 아니라 자신의 프로그램이 어떻게 GCD와 연결시켜줄 것인가만 고민하면된다. 또 이 연결작업은 앞서 말한 LLVM/Clang 그리고 Block 등 애플이 제공하는 API를 통해 더 쉽고 더 빠르고 단순하게 할 수 있다.

쓰레드를 몇개나 만들어야하냐는 것을 걱정할 필요가없다. 만약 어플리케이션을 제작하는데 500가지 Concorrent task가 있다면 500개의 GCD Queues만 만들어놓으면 된다. 더이상의 일이 필요한게 아니다. 나머지는 GCD가 알아서 분배하고 쓰레드를 만들어내는 것이다. 물론 Queue에도 우선순위 레벨이 주어진다. 얼마나 자주 급하게 사용되야하는가에 따라 쓰레드의 분배가 달라진다.

더욱 중요하게는 하드웨어 제조사들이 코어수를 더 늘린다해도 프로그래머가 걱정하거나 변경해야 할일이 더이상 없다. 그랜드 센트럴 디스패치가 알아서 해주는 역할이기 때문이다.
원글 포스팅 출처 : http://x86osx.com/bbs/view.php?id=freeboard&no=19869

comment : (0)

      [Save a Comment]

[Prev]
 LA
 SEOUL
   JP
   Mission Viejo, CA,
   United States
   THE GREEN FUSE (RSS 구독)
   LaymenBlog
   x86osx.com