1
00:00:00,000 --> 00:00:02,100
자막제작: 정재원(all2one)
http://vsts2010.net
http://gl3d.net

2
00:00:02,401 --> 00:00:06,396
여기 파일 경로는 wstring이고요,

3
00:00:06,976 --> 00:00:10,883
destinationFileList는 wstring 타입 파라미터의
unbounded_buffer가 되겠습니다.

4
00:00:11,602 --> 00:00:17,247
보시는 것처럼 모든 것이 template화 되어 있어서
복사만 지원한다면 여러분이 원하는 어떤 타입이라도
이용가능합니다.

5
00:00:19,119 --> 00:00:21,119
그 다음으로,

6
00:00:22,871 --> 00:00:27,113
직렬 처리의 경우 이렇게 타이머를 시작시키는 것을 볼 수 있습니다.

7
00:00:27,951 --> 00:00:30,111
그리고 경로에서 파일을 읽어오고요,

8
00:00:31,247 --> 00:00:35,461
blurFunctor를 만들고 있습니다.
여기 auto를 사용하고 있는게 보이시죠?

9
00:00:35,961 --> 00:00:39,035
또다른 C++0x의 키워드로 CTP에 구현되어 있습니다.

10
00:00:39,376 --> 00:00:44,451
여기서는 이 변수에 대한 타입 지정을 피하고 있는데요,
이것이 더 효율적일 수 있기 때문입니다. 특히 람다와 관련해서는요.

11
00:00:44,493 --> 00:00:50,803
타입 정보가 필요없으면, 람다를 매우 작고
수행이 간편하도록 만들 수 있습니다.

12
00:00:51,025 --> 00:00:55,663
필터 함수는 간단한 템플릿 함수를 이용하여 만들었습니다.

13
00:00:55,885 --> 00:00:58,347
실제 필터 함수가 하는 작업은

14
00:00:58,410 --> 00:01:05,186
GDI+를 가지고 비트맵을 입히고
비트들을 읽기 접근으로 잠궈서 접근이 빠르게 하고,

15
00:01:05,686 --> 00:01:11,245
여기 보이는 가우시안 블러와 글로우 필터를
차례대로 적용하는 것입니다.

16
00:01:13,593 --> 00:01:16,478
생성한 후 실제 돌리고,

17
00:01:16,978 --> 00:01:24,329
결과 이미지를 갱신 이미지를 위한 이미지 버퍼로 보냅니다.

18
00:01:24,389 --> 00:01:29,525
그 다음 화면을 무효화하여 repaint가 일어나도록 합니다.

19
00:01:31,326 --> 00:01:33,326
병렬 버전도

20
00:01:34,971 --> 00:01:36,971
이와 매우 유사합니다.

21
00:01:37,653 --> 00:01:40,051
여기 loadBitmap_은 실제 transform이 되겠습니다.

22
00:01:40,343 --> 00:01:45,515
Concurrency::transform 이죠.

23
00:01:46,015 --> 00:01:50,462
스트링을 받아서 BitmapType에 대한 포인터를 반환합니다.

24
00:01:52,185 --> 00:01:55,285
LoadImageFromPath를 생성 인자로 주고 있는데요,

25
00:01:55,369 --> 00:02:01,549
직렬 버전에서 사용했던 바로 그 함수죠.

26
00:02:06,005 --> 00:02:09,483
그 다음 가우시안 필터 변환을 하는 또하나의 transform이 있습니다.

27
00:02:09,619 --> 00:02:13,364
이것은 BitmapType*을 취해서 BitmapType*을 반환하네요.

28
00:02:14,749 --> 00:02:20,822
직렬 버전에서 보았던 필터를 역시 생성 인자로 주고 있습니다.
간단하죠.

29
00:02:22,545 --> 00:02:25,625
그 다음 핵심 부분인데요,
이들을 실제 연결하여 네트워크를 구성합니다.

30
00:02:26,359 --> 00:02:28,359
이 단계에서

31
00:02:29,067 --> 00:02:30,432
타겟을 연결시킵니다.

32
00:02:30,698 --> 00:02:36,005
그래서 한 블록에서 메시지를 받으면 다른 쪽으로도 전달이 되는거죠.

33
00:02:36,141 --> 00:02:39,239
그렇지 않으면 그냥 메시지가 큐에 쌓이기만 할겁니다.

34
00:02:39,479 --> 00:02:45,436
실제 연결해야 네트워크가 살아나는 것이죠. 

35
00:02:45,832 --> 00:02:53,247
이런 방식으로 한 곳에서 네트워크를 선언하고
런타임에 적절히 연결하는 유연한 작업이 가능합니다.

36
00:02:54,996 --> 00:03:03,069
그래서 loadBitmap_을 transform에 연결하고,
다시 transform을 updatedImage_ 버퍼에 연결합니다.

37
00:03:06,302 --> 00:03:08,014
자, 이제 돌려보죠.

38
00:03:17,103 --> 00:03:19,103
훨씬 빠릅니다.

39
00:03:22,206 --> 00:03:24,206
현재 큰 이미지를 처리하고 있군요.

40
00:03:24,237 --> 00:03:28,255
실제 일부 이미지는 메가픽셀 단위이고 나머지는 수백k 수준입니다.

41
00:03:28,365 --> 00:03:31,318
상대적으로 연산이 비싼 필터라 하겠습니다.

42
00:03:31,402 --> 00:03:36,801
하지만 아직도 전체 수행에 걸쳐 완전히 병렬로 도는 것은 아닙니다.

43
00:03:37,900 --> 00:03:42,249
parallel_for 사이에 직렬 작업이 존재하죠.

44
00:03:43,322 --> 00:03:51,400
이제 이 놈이 16-way에서 어떻게 도는지 보죠.

45
00:03:57,965 --> 00:03:59,965
직렬 처리는 191초였습니다.

46
00:04:05,955 --> 00:04:13,000
이 천체 이미지들에서 글로우 효과를 확인하실 수 있습니다.

47
00:04:42,730 --> 00:04:44,730
생각보다 더 오래 걸리는군요.

48
00:04:45,230 --> 00:04:47,726
보통은 10x 속도향상이 있습니다.

49
00:04:48,747 --> 00:04:50,747
흠, 무엇이 문제인지 모르겠군요.

50
00:04:51,091 --> 00:04:54,753
한번 다시 돌려보겠습니다;

51
00:05:22,010 --> 00:05:24,010
자 갑니다.

52
00:05:36,430 --> 00:05:38,430
훨씬 낫군요.

53
00:05:38,930 --> 00:05:44,382
15초입니다. 좋네요.

54
00:05:58,885 --> 00:06:01,030
질문을 위한 시간이 충분하겠군요.

55
00:06:03,014 --> 00:06:05,950
다시 크게 VS2010을 살펴보면요,

56
00:06:06,242 --> 00:06:08,136
매니지드 쪽으로는

57
00:06:08,844 --> 00:06:12,883
닷넷 4.0에 병렬 확장이 추가되었고요,

58
00:06:14,782 --> 00:06:16,934
네이티브 쪽으로는 Concurrency Runtime이 있습니다.

59
00:06:17,772 --> 00:06:20,452
그에는 로드밸런싱과 작업 스틸링 스케줄러가 포함되고요,

60
00:06:20,536 --> 00:06:22,200
그 다음으로 Parallel Pattern 라이브러리가 있습니다.

61
00:06:22,726 --> 00:06:24,407
데이터 및 작업 병렬화를 위한 것이죠.

62
00:06:24,465 --> 00:06:26,465
Asynchronous Agents 라이브러리도 있지요.

63
00:06:26,601 --> 00:06:28,601
병렬 디버거 툴도 추가되었고요,

64
00:06:29,101 --> 00:06:31,101
프로파일러도 마찬가지입니다.

65
00:06:36,520 --> 00:06:37,878
병렬 관련 세션들이 몇 개 더 있는데요

66
00:06:38,014 --> 00:06:41,492
하짐 세션에서는 프로파일러를 더 살펴볼거고요,

67
00:06:41,992 --> 00:06:44,168
다니엘의 세션도 있고,

68
00:06:44,278 --> 00:06:53,767
니컬라스는 고유의 스케줄러와 프로그래밍 모델이 필요한 상황에서
어떻게 리소스 매니저와 작업하는지 상세히 다룰 예정입니다.

69
00:06:55,516 --> 00:07:02,377
다음으로 우리 팀의 여러 멤버들이 참석하는
일련의 심포지엄이 있습니다.

70
00:07:12,546 --> 00:07:15,318
다시 말씀해주시겠습니까?

71
00:07:17,822 --> 00:07:21,669
태스크나 에이전트의 결과에 의존할 경우 어떻게 되냐고요?

72
00:07:24,095 --> 00:07:30,619
의존성은 PPL과 AAL에서 에이전트를 통해
가장 쉽게 나타낼 수 있습니다.

73
00:07:30,729 --> 00:07:40,908
transform을 가지고
연달아 호출하고자 하는 함수를 각각 지정한 뒤
연결하는 것이죠.

74
00:07:41,408 --> 00:07:48,324
일련의 태스크들의 경우
태스크 그룹으로 스케줄링해서 기다리면 되겠죠.

75
00:07:48,824 --> 00:07:51,700
여러 작업에서 여러 결과가 나오는 경우라면

76
00:07:51,966 --> 00:07:53,714
choice나 join을 이용하여

77
00:07:53,876 --> 00:07:58,563
스켈줄링한 후 그 중 하나 혹은 전부를
기다리도록 하면 됩니다.

78
00:07:59,063 --> 00:08:01,063
답변이 되었나요?

79
00:08:02,246 --> 00:08:03,563
넵

80
00:08:27,305 --> 00:08:29,305
네 맞습니다.

81
00:08:29,571 --> 00:08:33,090
런타임은 가능한한 로컬로 두려고 애씁니다.

82
00:08:33,200 --> 00:08:44,749
그래서 일련의 컴포넌트와 일련의 루프를 함께 스케줄링 한다면
근접한 태스크나 루프에서 작업을 스틸링하려고 할겁니다.

83
00:08:46,993 --> 00:08:52,125
여러 프로세서가 있다고 할 때 당연히 로컬을 먼저 살필거고요,

84
00:09:05,717 --> 00:09:10,043
이는 VS2010에 포함되고요,

85
00:09:10,985 --> 00:09:22,330
물론 일반적인 요구사항은 VS2008과 같을겁니다.
일부 제약이 있겠지만, 현재 비스타와 XP도 고려 중입니다.

86
00:09:22,830 --> 00:09:34,634
자막제작: 정재원(all2one)
http://vsts2010.net
http://gl3d.net