1 00:00:00,000 --> 00:00:05,107 자막: 정재원(all2one) http://vsts2010.net http://gl3d.net 2 00:00:20,049 --> 00:00:22,062 이제 Concurrency 런타임에 대해서 이야기해보죠. 3 00:00:28,961 --> 00:00:32,609 이 그림에서 전체 스택을 볼 수 있습니다. Concurrency 런타임 있고요, 4 00:00:33,830 --> 00:00:36,448 작업 스케줄러, 자원 관리자 레이어가 있습니다. 5 00:00:36,712 --> 00:00:40,384 프로그래밍 모델로는 Parallel Pattern 라이브러리와 동기화 라이브러리가 있습니다. 6 00:00:42,437 --> 00:00:43,905 먼저 런타임을 봅시다. 7 00:00:45,736 --> 00:00:47,015 몇가지 핵심 개념이 있는데요, 8 00:00:47,515 --> 00:00:52,765 먼저 로드 밸런싱 스케줄러입니다. 9 00:00:53,147 --> 00:00:58,023 이것는 순수 정적 분해이지만, 실제로 10 00:00:58,267 --> 00:01:03,122 여러분의 응용프로그램이 동작함에 따라, 부하에 적응할 수 있습니다. 11 00:01:03,185 --> 00:01:05,403 시스템 상에 그 외에 다른 것들도 돌고 있기 때문이죠. 12 00:01:05,600 --> 00:01:08,405 실제로 그를 표현하기가 그리 쉽지는 않습니다. 13 00:01:08,719 --> 00:01:11,403 특히 설계 시점에서는 말이죠. 14 00:01:13,609 --> 00:01:16,143 다음으로 이야기할 것은 동적 리소스 관리입니다. 15 00:01:16,643 --> 00:01:25,003 이것은 응용프로그램 내의 경쟁하는 여러 병렬 컴포넌트로부터 요청을 받아들이고 그들을 중재하는 것을 말합니다. 16 00:01:25,418 --> 00:01:37,449 병렬로 동작하는 두 컴포넌트가 있을 때, 둘이 동시에 활성화 되었다고 하면, 머신을 협력하는 방식으로 공평하게 나누길 원합니다. 17 00:01:37,656 --> 00:01:46,611 캐쉬 coherency 등과 같은 것에 시간을 낭비하지 않고, 18 00:01:46,615 --> 00:01:52,940 한놈이 작업을 마쳤으면 사용하던 자원을 다른 쪽에 넘겨 머신 활용도를 최대화하는 겁니다. 19 00:01:55,471 --> 00:01:59,333 이것은 로드 밸런싱에 관해 생각하는데 도움을 주기 위한 그림인데요, 20 00:01:59,351 --> 00:02:04,342 왼쪽은 정적 분할로 각 블록은 한 덩어리의 일을 나타냅니다. 21 00:02:05,238 --> 00:02:17,224 이 경우 효율적인 스케줄링이 힘듭니다. 하지만 동적 분할의 경우에는 현 부하를 고려한 최적의 잡 분배가 가능한 것이죠. 22 00:02:19,409 --> 00:02:23,405 런타임의 기능에 대해 다뤘는데요, 23 00:02:23,905 --> 00:02:36,873 저는 고수준에서 이야기하지만, 다른 세션에서 다른 친구가 더 자세한 사항에대해 다룰 겁니다. 저는 PPL과 에이전시 API에 초점을 맞추겠습니다. 24 00:02:37,769 --> 00:02:41,313 병렬성을 위한 플랫폼 인프라를 다룹니다. 25 00:02:41,516 --> 00:02:48,699 이는 로우 오버헤드 스케줄러를 제공하여, 여러분은 이에 대해 걱정할 필요 없이, 도메인 문제에 집중할 수 있습니다. 26 00:02:48,864 --> 00:02:51,372 협력 블로킹에 대해서도 이야기합니다. 27 00:02:51,632 --> 00:03:00,917 가령, 한 응용프로그램이 웹 통신을 한다면, 블록이 되는데 이를 응용프로그램이 다른 작업을 할 기회로 활용하는 것이죠. 28 00:03:01,086 --> 00:03:03,774 런타임은 그러한 것을 확실히 지원토록 설계되었습니다. 29 00:03:04,125 --> 00:03:10,082 락킹 프리미티브와 동기화 프리미티브가 마련되어 있으며, 그를 표현하기 위한 프로그래머 제어 도구들도 준비되어 있습니다. 30 00:03:10,385 --> 00:03:14,072 마지막으로 다중 스케줄러 인스턴스에 대한 지원이 있습니다. 31 00:03:14,157 --> 00:03:20,937 그간 미비했던 부분이, 다중 병렬 컴포넌트를 가지는 응용프로그램이 있을 때, 32 00:03:21,163 --> 00:03:29,230 한 컴포넌트는 Quality of Service 요구 때문에 특정 우선순위로 특정 하드웨어에서 돌기를 원하고, 33 00:03:29,299 --> 00:03:36,906 다른 컴포넌트는 특별히 까다롭지 않으므로, 전체 시스템을 활용할 수 있게 하는 등의 작업을 34 00:03:37,524 --> 00:03:44,807 명시적으로 매우 정밀하게 선언할 수 있으면서도, 장래 플랫폼에 대처할 수있는 유연한 규모가변성을 가지는 것이었습니다. 35 00:03:47,031 --> 00:03:49,472 다음으로 앞에서 언급된 자원 관리가 있습니다. 36 00:03:49,698 --> 00:03:58,472 스케줄러에 대한 요청을 자원 관리자가 중재하고 런타임에 동적으로 조정하는 것이죠. 37 00:03:59,638 --> 00:04:02,613 마지막으로 플랫폼 확장성과 조합능력이 있습니다. 38 00:04:03,466 --> 00:04:04,375 이것이 핵심이죠. 39 00:04:04,875 --> 00:04:11,806 우리가 제공하는 프로그래밍 모델 외에, 다른 프로그래밍 모델과 라이브러리가 분명히 존재할 것입니다. 40 00:04:12,306 --> 00:04:18,143 우리가 원하는 바는 제공되는 토대 위에 커뮤니티가 필요한 것을구축할 수 있게 하는 것입니다. 41 00:04:18,643 --> 00:04:21,592 여러분이 여러분의 라이브러리나 컴포넌트를 구축할 때, 42 00:04:21,786 --> 00:04:24,800 자원 관리자에게 어떤 자원들 사용하는지 알려줄 수 있고, 43 00:04:25,143 --> 00:04:31,187 그러면 자원 관리자는 그 시스템 상의 다른 컴포넌트나 라이브러리들 간에 조정을 할 수 있습니다. 44 00:04:34,900 --> 00:04:52,687 얼마전 발표된 한가지 기대되는 소식은, 인텔이 TBB와 OpenMP를 지원하는 Parallel Studio라는 제품을 준비하고 있다는 것인데, Concurrency 런타임도 그에 포함될 것입니다. 45 00:04:55,774 --> 00:04:58,458 이것이 여러분에게 의미하는 바는, 46 00:05:02,211 --> 00:05:10,003 여러분이 TBB와 PPL을 같이 사용할 경우, 문제없이 맞물릴 것이며 좋은 성능을 보여줄 것이라는 점입니다. 47 00:05:10,503 --> 00:05:12,834 또한, 인터페이스도 맞출 것인데요, 48 00:05:14,000 --> 00:05:21,087 TBB 역시 PPL 내의 인터페이스들을 지원하기로 약속했습니다. 49 00:05:21,141 --> 00:05:28,353 따라서 여러분은 PPL에서 배운 기법을 TBB에서도 사용할 수 있을 것입니다. 50 00:05:28,555 --> 00:05:37,931 이것은 매우 중요한 부분인데요, 더 많은 옵션으로 전체 분야를 일보 전진시킬 수 일 겁니다. 51 00:05:38,431 --> 00:05:46,901 왜냐하면, 프로그래머가 생산적일 수 있으려면, 이러한 개념이 언어에 깊숙하게 내장되어 있어야 하기 때문입니다. 이게 시작인 거죠. 52 00:05:49,521 --> 00:05:52,814 좋습니다. 이제 PPL입니다. 53 00:05:56,665 --> 00:05:59,156 이것은 태스크 병렬성을 위한 프로그래밍 모델입니다. 54 00:05:59,656 --> 00:06:06,570 그리고 병렬 알고리즘을 위해 몇가지 동기화 프리미티브와 자료구조를 갖추고 있습니다. 55 00:06:07,859 --> 00:06:13,884 우리가 정말 원하는 바는 병렬 프로그램을 작성하는 과정을 쉽게 하는 것입니다. 56 00:06:13,858 --> 00:06:23,683 그래서 스레드, 뮤텍스, 스케줄러 대신에 parallel_for나 태스트를 다룰 수 있는 것이죠. 57 00:06:24,577 --> 00:06:27,549 또한 우리는 확장성(조합가능성)을 원했습니다. 58 00:06:28,049 --> 00:06:32,682 그래서 여러분이 라이브러리를 만들 때, 스케줄링 시만틱을 서술하지 않습니다. 59 00:06:32,722 --> 00:06:37,814 대신 parallel_for나 parallel_sort 등을 조합하는 것이죠. 60 00:06:38,314 --> 00:06:50,747 그리고 늦은 바인딩을 통해 최종 사용자가 원하는 병렬성을 지정할 수 있도록 하는 것이죠. 61 00:06:53,468 --> 00:06:58,667 PPL의 핵심 개념은 두가지입니다. 첫째는 작업(Task)인데요, 62 00:06:58,773 --> 00:07:02,667 이는 단순히 스케줄되어 동작할 수 있는 일을 나타냅니다. 63 00:07:04,021 --> 00:07:08,341 아주 단순하죠. 이것을 task_handle이라 부릅니다. 64 00:07:08,513 --> 00:07:10,906 다음 개념은 태스크 그룹입니다. 65 00:07:12,851 --> 00:07:19,342 이는 간단히 논리적 연산 혹은 하부연산을 이루는 태스크들의 집합입니다. 66 00:07:19,579 --> 00:07:29,616 그래서 일련의 태스트 혹은 task_handle을 태스크 그룹으로 표현하고, 스케줄링하고, 기다릴 수 있습니다. 67 00:07:30,116 --> 00:07:39,447 여기서 매우 중요한 점은 단순히 스케줄링하고 기다리는 것 외에, 취소할 수도 있고, 68 00:07:40,473 --> 00:07:54,082 예외를 추출하거나, 상속받거나, 기능을 추가할 수도 있습니다. 매우 원시적이며 유연하죠. 69 00:07:54,582 --> 00:07:58,103 PPL의 대부분이 이 두가지를 기반으로 구현되었습니다. 70 00:08:03,465 --> 00:08:05,267 여기 간단한 예가 있습니다. 71 00:08:05,504 --> 00:08:11,616 태스크 병렬성을 보여주기에 최적인데요, 퀵소트입니다. 72 00:08:11,794 --> 00:08:19,450 퀵소트의 좋은 점은 데이터를 분할하고 왼쪽, 오른쪽을 따로 정렬한 후 둘다 끝날 때까지 기다리면 된다는 것이죠. 73 00:08:20,541 --> 00:08:24,090 이를 PPL 태스크를 이용해 표현할 수 있습니다. 74 00:08:24,590 --> 00:08:30,196 task_group을 선한하고, 그의 run 메소드를 사용하고 있습니다. 75 00:08:30,696 --> 00:08:32,343 다시 람다를 사용하고 있는데요, 76 00:08:32,843 --> 00:08:38,696 람다를 써서 왼쪽 부분과 오른쪽 부분을 나타낸 후, task_group에 g.run 을 호출하고 있습니다. 77 00:08:39,196 --> 00:08:40,660 아주 명료하죠. 78 00:08:46,744 --> 00:08:50,621 이제 디버깅 작업에 대해 살펴보죠. 79 00:08:56,970 --> 00:08:59,349 다시 병렬 행렬 곱셈으로 돌아갑시다. 80 00:09:00,112 --> 00:09:04,458 전술한대로 PPL은 태스크 기반이므로, 81 00:09:04,564 --> 00:09:08,361 여기서 태스크를 뽑아내보죠. 82 00:09:08,861 --> 00:09:14,675 VS 2010에서 태스크를 디버깅하기 위해 두가지 개념이 등장하는데요 83 00:09:14,781 --> 00:09:16,913 둘 모두 CTP에 있습니다. 84 00:09:17,413 --> 00:09:31,187 하나는 태스크 뷰라는 것으로 스레드 뷰가 스레드를 보여줬다면 한단계 위의 추상화로 태스크를 관찰할 수 있게 해줍니다. 85 00:09:31,490 --> 00:09:39,043 물론, 스레드 뷰도 여전히 존재합니다. 86 00:09:39,477 --> 00:09:44,541 이번엔 여기까지입니다. ^^ 다음 회를 기대해주세요. 자막: 정재원(all2one) http://vsts2010.net http://gl3d.net