The Green Fuse

[눈범 진실 3] GCD: Grand Central Dispatch 1부

September 03,2009 hit:(6648)

Link#1 : http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/8
Link#2 :

계속되는 arstechnica.com 의 눈범이 리뷰입니다. 가면 갈수록 제 한계를 넘어가는 전문적인 내용입니다...ㅋ! 하지만 이 부분을 빼고 스노우를 논할 수 없는 거 같습니다. 한계내에서 가급적 저 같은 유저들이 취할 수 있는 정보 중심으로 옮겨 봤습니다...특히 스노우 GCD 의 밑그림을 제공하는 프로그램 랭귀지 부분 (Blocks)에서는 도저히 제 머리가 못쫓아가서 거의 겉만 핥았습니다...이해해주시길...^^ 혹시 삐돌이님이 이 글을 보신다면 잘못된 부분 및 빠진 부분을 지적해 주실수도 있을거 같습니다만 ...^^

위 그림이 생각나시나요? 익숙한 그림이죠...맥 사용자는 다 아실듯한...이전 흑백화면의 매킨토시 때부터 부팅때말고 프로그램 실행시 돌아가는 바람개비입니다. 지금은 무지개 빛으로 변했죠. 헌데 이게 멋진게 아니더군여. 특히 멀티태스킹 작업환경에서 프로그램 실행시 여러분의 맥컴퓨터가 버벅되는것을 표현하는 것입니다. CPU는 갈길 먼데 또 새로운 일하라고 명령하면 "지둘려~"하면서 심심한데 무지개 바람개비나 보라는...ㅋㅋ

근데 맥에서 GCD가 사용되는 프로그램환경에 이르면 예쁜 무지개도 더이상 나타날 필요가 없다는 군여...!!

--------------------------------------------------
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/8

다다익선?

잠깐 무어의 법칙을 들춰보자. 오늘날 약간의 오해가 있긴 하지만 그가 65년 처음 말한 것은 "컴퓨터 스피드가 매년 두배로 빨라질 것"이었다. 이후 무어는 자신의 주장을 "2년"이라고 수정했었다. 컴퓨터 시대가 열리고 그의 법칙이 맞아 떨어진 기간이 있었지만 오늘날 문제는 그게 아니다.

이슈를 재조명하자면 "스피드가 두배로 빨라지는게 아니라 실리콘 칩의 트랜지스터 집적도(density)가 2배로 커지는 것"이다. 컴퓨터 클럭 스피드가 한계점에 도달한 지금 인텔, AMD같은 칩제조사들은 개발 포커스를 스피드에서 트렌지스터 집적 분야로 옮겨갔다. 클럭스피드는 오히려 거꾸로 가는 모양새다. 맥프로의 경우 2009년 최상위 모델이 2.93GHz인데 반해 2008년 최상위 모델은 3.2GHz다. 코어수가 다를 뿐이다. 하드웨어의 끊임없는 발전과 마케팅을 위한 어쩔수없는 방편이지만 증가일로의 다중코어 칩을 위해 프로그래밍 코드를 쓰는 프로그래머들은 사실 난관에 봉착했다.

일반적으로 보자면 듀얼 코어 CPU가 싱글 코어에 비해 사용자 어플리케이션 작동시 2배로 빨라지는게 아니다. 그렇게되기 위해선 프로그램이 듀얼 코어를 이용하도록 만들어져야한다. 현재의 모양새는 프로그래머들이 다중코어 최적화를 위한 준비를 못하고 있는 가운데 하드웨어 회사는 모든 책임을 프로그래머에게만 던져놓은 그런 양상이다.

개발자를 위한 운영체제

눈범이가 이런 환경속에서 태어났다는 것을 기억하시라! 지금까지 컴퓨터 운영체제 제조사의 중요한 책임중 하나가 "보안"이었다면 2009년 오늘부터 더 중요해지는 책임은 날로 증가하는 칩셋 자원을 보다 효율적으로 이용할 수 있는 방법을 프로그래머와 써드 파티 어플 제조사에게 제시하는 것이다. 그리고 이번 눈범이에서 가장 눈에 띠는 대목이 개발자들에게 오늘날의 멀티코어 실리콘 칩셋을 보다 효율적으로 그리고 이미 만들어져있는 "다다익선"의 구조를 활용하는 방법을 제시하고 있다는 것이다.

이제 눈범이에 포함된 두가지 특별한 API (어플리케이션 프로토콜 인터페이스인가요?!)에 대해 논하고자 한다. 그 첫째가 Compiler다.

LLVM & Clang
(역자주: 이제부터 모르는게 마구 나옵니다.ㅋㅋ Low Level Virtual Machine(LLVM)이란 하나의 컴파일러 하부구조를 의미한다. C++로 만들어졌으며 프로그램 최적화를위한 compile-time, link-time, run-time 그리고 idle-time을 위해 만들어진 것이다. by Wikipedia]

애플은 오래전부터 오픈소스 프로젝트인 LLVM에 전략적 투자를 해왔다. 이미 레퍼드에도 도입된 것이며 LLVM 역할은 OpenGL 기능과 연관되는 JIT방식의 소프트웨어 효율성을 극대화 시켜주는 것이다. 하지만 레퍼드에서의 사용은 미미한 것이었다. 오래전부터 언급한 것이지만 이런 미미한 사용일지라도 애플의 원대한 플랜을 볼 수 있는 대목이었다. 프로그래밍의 스피드 향상과 버그발생을 낮춰주는 LLVM. 지금까지 사용해온 GCC를 LLVM로 완전히 대체한다는 것이 꿈이기만 한 일일까?

GCC를 버리지만 GCC와 호환되는 완전한 LLVM 기반의 컴파일러 시스템을 우리는 Clang 프로젝트라고 부른다. 그리고 눈범이의 출시는 바로 Clang과 LLVM이 애플의 "컴파일러 전략"임을 공식 선언한 것이다!!!

Clang(guage)은 현재 C, Objctive-C, 그리고 약간의 C++ 을 지원한다. 하지만 장점은 컴파일 타임이 짧고 더 빠른 실행 속도다. GCC 4.2와 비교해서 Clang은 3배나 빠른 속도를 가져오며 프로그래밍의 단순화가 가능하다. 현재로서 스노우는 LLVM을 백엔드로해서 프론트엔드에 Clang과 GCC 4.2의 혼합형 컴파일러를 사용중이지만 이 조차 5-25%의 스피드 향상을 가져왔다. 게다가 애플은 iCal, Address Book, Xcode, 그리고 Ardium, Growl 등의 써드파티 소프트웨어 프로그래밍에 Clang을 도입했다. 더 중요하게는 Clang에서 아직 호환되지 않는 C++을 스노우가 지속되는한 반드시 호환되게 만들겠다는 애플의 약속이다.

업계 리더

Clang/LLVM 도입은 애플로 하여금 마침내 개발 플랫폼의 완전한 주도권을 쥐게되는 것이다. 그동안 써드파티 개발자에 목메달아온 환경을 완전히 뒤바꿀수있는 기회가 온 것이며 이는 애플의 역사가 보여주는 과거의 점철된 실패에서 배운 결과물이다. 많은 시간이 걸렸지만 이제 스노우의 Xcode가 진정으로 인정받게 된 것이다. 자 그럼 이제부터 이러한 프로그래밍 하부구조의 변화가 멀티코어 칩셋구조를 이용하는 것과 어떤 관계가 있는 것인지를 찾아보자.

스노우가 제시하는 2번째 API: Blocks

애플이 눈범이를 통해 소개한 Blocks는 일종의 C 랭귀지의 확장이다. C랭귀지와 이의 변종인 C++, Objective-C, Objective-C++ 등을 지원하는 하나의 묶음 틀(closures)이다.

이미 존재해온 것이긴 하고 또 비전문가들에겐 먹힐리가 없는 소리가 되겠지만 그래두 blocks의 의미가 스노우에서 차지하는 비중을 설명하고자한다. 가장 쉽게 말하자면 blocks는 데이터 형태의 또다른 컴파일 기능이다. C 랭귀지 변종들도 이런 데이터 형태로 움직인다. 이런 언어체계는 컴파일 타임에서 만들어진 기능들을 패스(전달경로?)하는 것이다. 이런 기능들을 조정하는 것은 별도의 Argument를 패스해주면서 발생한다. 이런 관계가 엄청난 시간소모적 작업으로 나타난다.

Argument를 패스하는 것이 거추장스럽고 통제하기 어려운 작업인것은 프로그래머들이 익히 알고 있는 사실이다. Block 은 덩어리의 명령체계로 이런 복잡한 작업을 우회에서 기능구현을 실현하는 것이다. 그리고 이런 실행은 CPU 쓰레드 작업에 안정성을 확보한다. 이로인해 갑자기 C 랭귀지가 보다 다이나믹해졌다는 것을 알수 있다. 더 고차원의 프로그램에 이용될 수 있다는 것이다.

애플이 스노우를 통해 구현한게 약 100가지가 넘는 Blocks 형태의 새로운 API다. 이는 명령어 처리 계통에서 획기적인 발판이 되는 것이다. 애플의 의도는 이런 blocks들을 C 기반의 랭귀지에 공식 확장자로 이용하려는 것이다.

Concurrency: 그 시조

오래전부터 다수의 독립적인 컴퓨팅 디바이스들을 효율적으로 사용한다는것은 너무나 어려운 일이었다. 수십년 넘게 슈퍼컴퓨터 하드웨어 소프트웨어 개발자들이 도전해왔고 이제는 그 도전의 범위가 데스크톱, 모빌컴퓨터까지 확대되고 있다.

PC업계에서 보면 누구보다 빨리 이런 도전을 성사시킨 회사가 있다. 20년전에 창립된 Be, Inc.다. Be 는 당시 컴퓨팅 환경의 제약을 떨쳐버리는 획기적인 PC 플랫폼을 만들어보자는 목표로 태어난 회사였다. 여러 독립적인 하드웨어를 하나로 묶어서 활용해보자는 당찬 시도였다. Be는 듀얼 CPU 데스크톱 컴퓨터에 전혀 새로운 BeOS가 탑재된 시스템 BeBox를 결과물로 선뵀다.

당시 "Pervasive MultiThreading"(멀티스레딩의 전파)는 Be가 내건 캐치프레이즈였다. BeBox와 BeOS가 탑재된 컴퓨터 시스템은 하드웨어가 지원하는 모든 자원을 국물하나 남기지 않고 쥐어짜내 사용하는 것이었다. 업계는 경이의 시선을 멈출수없었다. 66 mhz CPU 2개를 꼽아넣은 시스템에서 멀티 오디오 씨디 트랙이 재생되는 가운데 다수의 비디오 파일을 동시에 재생시키고 있었고 그럼에도 불구하고 User Interface는 안정적으로 굼뜨지 않게 반응하고 있었다.

BeOS의 광팬들이 생겨났고 그들은 아직도 오늘날 컴퓨터 보다 훨씬 더 부드러웠다고 말한다. 왜 그런 말을 하는지 충분히 공감하고도 남는다. 그 정도로 충격적이고 혁명적인 기술이었다.

90년대 Be가 설자리는 좁았다. 또 마소의 독과점식 몰아치기 경쟁을 피해갈수도 없었다. 애플은 거의 Be를 인수할뻔했다. 하지만 마지막에 스티브 잡스의 NeXT를 인수하고 말았다. 나머진 모두가 아는 역사다. 짚고 넘어가려는 대목은 바로 이것이다. BeOS의 멀티쓰레딩은 정말 사용자의 입장에서 너무나 환상적인 것이었지만 당시 프로그래머들에겐 나이트메어와 다름없었다. 그게 실패의 이유였다. BeOS는 모든것이 쓰레드와 관련됐고 이런 구조가 당시 프로그래머들에게 맞아떨어질 수가 없었던 것이다.

병렬(Parallel) 프로그래밍은 악명높다. 전세계 최고의 프로그래머라해도 로우 레벨 랭귀지 C 또는 C++ 을 갖고 덩치 크면서 동시에 작동하는 멀티쓰레드 프로그램을 만들라한다면 골목골목 장애물을 만나게 되고 헤어나올수없는 늪에 빠지게 된다. 결과물은 버그투성이가 되버린다는 것도 빼놓을 수 없는 포인트다. 컴퓨터 프로그래머들이 말하는 Heisenbug가 바로 이를 두고 하는 말이나 다를 바 없다.

BeOS 가 등장하고 19년이 흘렀다. 하지만 여전히 멀티쓰레드 프로그래밍은 찾아보기 힘들다. 하드웨어는 저만치 앞서있는데 이를 받쳐줄 프로그래밍이 여전히 뒤쳐져 있는 것이다. 옥타코어 맥 프로 조차 싱글 쓰레드 명령을 수행할때 한개의 코어만 100% 쓰고 나머지 15 코어가 놀고있는 것을 볼수있다.

그리하여 눈범이가 나온것이다.
--------------------------------------------------------

에고 힘들어라...서론이었습니다...본론격인 Grand Central Dispatch는 2부에서 진행하도록하겠습니다...ㅋㅋ

원글 포스팅 출처 : http://x86osx.com/bbs/view.php?select_arrange=reg_update&desc=desc&id=freeboard&no=19845