MSDN Virtual Lab에서는 Microsoft Team Foundation Server 2010 제품을 온라인으로 트레이닝 받을 수 있는 서비스가 있습니다. Team Foundation Server 2010 을 설치할 여력이 되지 않거나, 제품을 직접 시연하고 싶은 사용자에게 가상 환경을 제공해 주고, 가상 환경에서 여러 시나리오를 따라해 볼 수 있습니다.

이 MSDN Virtual Lab 환경은 Internet Explorer 만 있으면 곧바로 서비스를 체험할 수 있습니다. 다만, 이 서비스는 가상의 환경으로 제공이 되기 때문에 가상 환경에서 실습이 끝난 이후에는 생성된 팀 프로젝트와 데이터는 모두 삭제가 됩니다.

실습은 모두 3가지의 모듈로 제공이 됩니다.

   

먼저 실습을 하고자 하는 모듈의 주소를 Internet Explorer 를 통해 접속을 합니다.

   

Launch Virtual Lab을 선택하면 아래와 같은 팝업이 뜨는데, 실습 환경의 가상 환경을 제공하기 위한 준비를 합니다. 아마도 실습을 하기 위한 스냅샷으로 돌아가고 있겠지요..?

   

이 가상 환경 실습은 원격 데스크톱 연결을 이용하는데, Connect 버튼을 클릭하면 곧바로 가상 환경을 원격 데스크톱 세션을 통해 접속이 됩니다.

   

접속이 되면 가상 환경 접속에 접속할 수 있는데, 마치 Hyper-V 관리 콘솔과 같은 화면이 나타납니다. 물론 단 하나의 VS2010CTP 라는 가상환경에만 접근할 수 있습니다.

   

아래오 같이 가상 환경이 접속이 되면, 텅 빈 윈도우 바탕 화면이 나타나는데, Start 버튼을 클릭하면 우리가 실습에 필요한 모든 소프트웨어가 설치가 되어 있습니다. 우측의 패널에는 실습 단계를 차례대로 진행할 수 있고, 상단에 HTML과 PDF 문서를 다운로드 받을 수 있습니다.

   

사실 Team Foundation Server 2010의 MSDN Virtual Lab 서비스가 나온지는 좀 되었지만, 아직 많이 알려지지는 않은 듯 합니다. 소프트웨어 패키지를 구매하고 설치하고 MSDN을 통해 기능을 익힐 수 있지만, 이렇게 가상화 서비스를 이용해 부담 없이 하드웨어나 환경적인 제약 없이 실습 공간을 제공해 주는 것을 보면 Before Services 가 짱 이네요.

(BE란 ? 고객들이 제품 구매에 앞서 제품을 직접 써보거나 충분히 경험해 본 다음 구매를 결정할 수 있도록 하는 다양한 체험 프로그램 서비스를 말한다. 기존 서비스 방식인 애프터서비스(AS)는 고객들이 제품을 구매한 후 제품에 대한 차후 서비스를 받을 수 있다. )

 

Visual Studio 2005버전부터 만들어온 VSGesture 확장 도구가 Visual Studio 2008, Visual Studio 2010, 그리고 Visual Studio 11버전까지 나왔습니다. VSGesture는 Visual Studio에서 마우스 오른쪽 버튼을 이용하여 제스쳐를 하면 여러 가지 동작을 하는 확장 도구 입니다.

   

   

   

현재 이 확장 도구는 이미 오픈 소스로 공개를 하였답니다.

http://vsgesture.codeplex.com

   

그 밖에 오픈 소스로 공개한 다른 것들도 구경해 보시고요.

Umc.Core Framework http://umccore.codeplex.com/

jQuery DateTimePicker http://umcdatetimepicker.codeplex.com/

MEFGeneric http://mefgeneric.codeplex.com/

vutpp for VS2010 http://vutpp.codeplex.com/

   

기타 무료 확장 도구 및 Visual Studio 백서

http://www.powerumc.kr/ko-kr/products.aspx

   

   

웹을 통해 이 버전을 다운로드 받으려면 다음의 링크를 참고하세요.

Visual Studio 11, 2010 - http://visualstudiogallery.msdn.microsoft.com/e03c91ff-e20d-4dcc-822b-172a68c40f5b

Visual Studio 2005, 2008 - http://visualstudiogallery.msdn.microsoft.com/F5007932-0720-492B-8A51-631D5265F6B7

   

   

Visual Studio 2010, 11 에서는 Tools(도구) -> Extension Manager(확장 관리자)를 이용하여 바로 설치할 수 있습니다.




Get Microsoft Silverlight

개발자에게 Visual Studio 11의 가장 큰 장점 중에 하나가 될 바로 코드 에디터 입니다. 특히 C++ 개발자에게 원성을 샀던 부실했던 C++ 코드 에디터는 기존의 C,#, VB.NET 과 동등할 정도로 코드 에디터의 구현에 충실해 다른 확장 도구의 도움 없이도 충분히 사용이 가능합니다. (Visual C++ 의 코드 에디터는 그 흔한 코드 컬러링도 기대 이하의 수준이었거든요)

   

C++ 코드 에디터

C++ 개발자에게는 C++ 코드 편집기의 컬러링과 인텔리센스는 정말 희소식일 것 같습니다. C++ 개발자는 기본적인 코드 작성에 Visual Assist 툴에 많이 의존하였었지만, 이제 외부 도구의 도움이 없이도 코드 작성에 어려움은 없을 것 같습니다. 

아래의 Visual Studio 2010과 Visual Studio 11의 C++ 코드 에디터를 그냥 눈으로 쓱 훑어보시기 바랍니다.

   

Visual Studio 2010의 C++ 코드 에디터

   

Visual Studio 11의 C++ 코드 에디터

   

   

   

C++/CLI 코드 에디터

특히 C++/CLI 를 자주 쓰는 분들에게는 더욱 특별할 수 있을 겁니다. C++/CLI 는 이전버전까지 예쁜 컬러링은 물론이거니와 인텔리센스도 작동하지 않는 암울한 환경에서 코드를 작성해야 했었습니다. 특히 C++/CLI 를 이용하여 C++ 코드를 단위 테스트할 때 무척 유용하였는데, 이번 컬러링과 인텔리센스 기능으로 더욱 활용도가 높아질 것 같습니다.

마찬가지로 Visual Studio 2010의 C++/CLI와 Visual Studio 11의 C++/CLI의 코드 에디터를 한번 보시죠.

   

Visual Studio 2010 C++/CLI 코드 에디터

   

Visual studio 11 C++/CLI 코드 에디터

C#, VB.NET 과 동급한 레벨로 인텔리센스와 코드 컬러링을 제공합니다. 그리고 Code Snippet도 제공되니 코딩이 한껏 즐거워지겠네요.

   

   

   

JavaScript 코드 에디터

JavaScript 는 웹 개발 환경에서 필수 언어로써, 개발 툴에서 JavaScript 인텔리센스 지원이 점점 좋아지고 있네요. Visual Studio 11 Beta 에서는 JavaScript 인텔리센스의 성능이 향상이 되거나 HTML5 등을 지원하는데요.

그 중, Lazy Initialize와 Lazy Loading 부분에서 상당히 만족할만한 수준으로 인텔리센스 기능이 좋아졌습니다.

   

JavaScript 코드 에디터에 대한 더 자세한 내용은 다음의 링크를 참고하십시오.

http://msdn.microsoft.com/en-us/library/bb385682(v=vs.110).aspx

   

JavaScript 코드 에디터의 인텔리센스가 얼마나 똑똑해 졌는지 아래의 예시를 보면서 비교해 보시기 바랍니다.

   

Visual Studio 2010 JavaScript 인텔리센스

인텔리센스가 C#, VB.NET 과 다르게 인텔리센스의 범위가 축소가 되지 않고 그냥 다~~~ 보여주지요.

   

   

Visual Studio 11 JavaScript 인텔리센스

JavaScript 인텔리센스가 C#, VB.NET 에서 사용하는 것과 똑같이 입력하는 문자에 따라 점점 인텔리센스 범위가 축소가 됩니다. 그리고 인텔리센스 상자 오른쪽에 시그너처도 함께 표시해 주네요.

   

   

JavaScript OOP 프로그래밍 인텔리센스

특히 JavaScript OOP 프로그래밍을 할 때는 인텔리센스의 도움을 많이 받게 되지요. Visual Studio 11 의 JavaScript 구문을 제대로 분석하여 인텔리센스를 제공해 주는 것 또한 막강한 Visual Studio 11 기능이라고 할 수 있습니다.

특히 Visual Studio 2010을 사용할 때 필자는 JavaScript OOP 프로그래밍을 절대 Visual Studio 2010에서 하지 않았답니다. 왜냐하면 제대로 인텔리센스를 보여주지 못하거나 올바른 인텔리센스 목록이 제공이 되지 않으면, 아차 하는 순간 코드가 동작을 안하거든요.

   

마찬가지로 Visual Studio 2010과 Visual Studio 11의 JavaScript OOP 인텔리센스를 비교해보시죠.

   

Visual Studio 2010 JavaScript OOP 인텔리센스

아주 간단한 JavaScript Initialize 패턴과 Simple Factory 패턴의 New() 메서드를 인식하지 못합니다. 물론 아래의 코드는 잘못된 코드가 아니겠지요.

   

Visual Studio 11 Beta JavaScript OOP 인텔리센스

Visual Studio 2010 JavaScript 인텔리센스에 비해 Visual Studio 11 Beta 는 Lazy Initialize 패턴과 Simple Factory 패턴 구문을 정확하게 분석하여 인텔리센스 목록에 New() 메서드를 깔끔하게 보여주고 있습니다.

   

   


Visual Studio 11, 검색 기능 강화

Visual Studio 2012 2012. 3. 5. 08:00 Posted by POWERUMC

솔루션 탐색기의 코드 미리 보기

솔루션 탐색기에서 코드 파일의 클래스나 메서드, 필드 정보를 TreeView에서 확장하여 바로 볼 수 있게 되었군요. 물론 하위 정보들을 더블 클릭하면 바로 코드의 위치로 이동하겠죠.

   

설마 다른 개발 도구를 사용하는 분들이 보시면 여태 그런 기능도 제공이 안되었냐고 오해할 수 있을 수 있겠군요. 아래의 모든 기능들은 Microsoft에서 개발하여 배포한 Visual Studio 확장 도구를 통해 사용이 가능했었고, Visual Studio 11에 와서 Product Features로 들어가게 된 것들입니다.

   

이전 버전인 Visual Studio 2010에서 필수 앱이었죠.

PowerCommands for Visual Studio 2010, Productivity Power Tools

   

   

   

코드 윈도우 고정 핀

자주 사용하는 코드 파일을 아예 핀을 이용하여 좌측으로 고정할 수 있습니다. 필자는 구현 클래스나 참조 클래스들의 탭 위치가 뒤죽박죽이 되면 열 받아서 'Close All Windows' 를 해버리고 다시 정리하는 습관이 있었는데, 이 고정 핀 덕분에 효과를 톡톡히 보고 있습니다.

   

솔루션 탐색기 창의 다중 인스턴스

이번 Visual Studio 11에서는 솔루션 탐색기를 다중 인스턴스로 열어서 사용이 가능합니다. 아래의 그림과 같이 솔루션 탐색기가 여러 개가 열려 있지요.

필자도 이런 기능이 꼭 필요했답니다. 왜냐하면 솔루션의 폴더 구조가 복잡하거나 프로젝트 양이 많아지게 되면 솔루션 탐색기에서 마우스 휠을 올렸다 내렸다 하면서 파일을 찾느라 정신이 없거든요. 솔루션 탐색기를 한 두어개 열어놓고 미리 자주 탐색하는 위치에 스크롤을 해놓으면 훨씬 편리하겠지요…?

   

   

   

여러 툴 윈도우에 검색 기능 제공

여러 툴 윈도우에 검색 기능이 강화가 되었습니다. 자칫 "모두 똑같은 검색 아니야?" 라고 하실 수 있겠지만, 각각 검색의 기능은 다르게 작동합니다. 예를 들면, TEAM EXPLORER인 경우 원하는 Work Item을 찾거나 SharePoint 문서를 찾는데 활용할 수 있고, SOLUTION EXPLORER에서는 파일의 내용이나 파일 이름으로 검색을 할 수 있겠지요.

다음은 툴 윈도우에서 제공하는 검색 기능들 입니다.

   

솔루션 탐색기 검색

   

단위 테스트 검색

   

팀 탐색기 검색

   

도구 상자 검색


Visual Studio 11, 프로젝트 호환성

Visual Studio 2012 2012. 3. 4. 08:00 Posted by POWERUMC

프로젝트 호환성

Visual Studio 11 에서 바로 와 닿는 편리함 중의 하나가 기존의 솔루션 파일과 프로젝트 파일을 어떤 변경 없이 그대로 열 수 있는 점입니다. 이전까지는 솔루션 파일의 구조와 프로젝트 파일의 일부 속성이 변경되어 새로운 개발 툴이 나올 때 마다 손이 갔었습니다. Visual Studio 가 해주는 자동 업그레이드를 그렇게 신뢰하지 않기 때문에 상위/하위 버전과 호환이 되도록 솔루션 파일과 프로젝트 파일을 변경했기 때문입니다. 과거에 Visual Studio 솔루션/프로젝트를 자동으로 업그레이드해 줄 경우 컴파일이 되지 않는 경우가 많았거든요.

   

   

이번 Visual Studio 11은 대부분의 솔루션/프로젝트의 구조를 변경 없이 그대로 상위 버전인 Visual Studio 11에서 사용할 수 있습니다. 재미있는 것은 예전에는 솔루션/프로젝트 업그레이드 마법사가 업그레이드를 진행하였는데, 이번 Visual Studio 11에서는 안전한 업그레이드인 경우 그냥 알아서 업그레이드하는 듯 합니다.

   

하지만, 모두 다 호환되는 것은 아닙니다. 우리가 평상시에 자주 쓰는 프로젝트 형식들은 아무 변경 없이 호환이 되지만, 일부 호환이 되지 않는 프로젝트 형식도 몇 가지 됩니다. 그리고 프로젝트 형식이 호환은 되지 않지만, 아주 사소한 변경이라면 Visual Studio 11이 그냥 알아서 업그레이드를 합니다. 여기에 대한 정보는 다음의 링크에서 확인할 수 있습니다. (

http://msdn.microsoft.com/en-us/library/hh266747(v=vs.110).aspx )

   

그 중에서 대표적으로 호환이 되지 않는 것들만 볼까요?

   

프로젝트 형식

  • Visual Studio 11 에서 열 수 없는 것들
    • Cloud tools
    • MSI setup (설치 프로젝트) - VS11 에서 없어졌지요.
    • Visual Studio Macro - VS11 에서 없어졌지요.
    • Windows Mobile - 프로젝트 형식이 없어졌지요.
    • Windows Phone - 프로젝트 형식이 없어졌지요.

   

   

  • Visual Studio 11 형식으로 업그레이드가 필요하고, 그 이후 Visual Studio 11 에서만 열리는 것들
    • F#
    • LightSwitch
    • Rich Internet Applications - 실버라이트를 의미하는 것일까요? ^^;
    • Visual Studio SDK/VSIX

         

         

  • 그 외 특수한 경우
    • Visual C++ 10.0 - 로컬 컴퓨터에 Visual Studio 2010과 Visual Studio 11 Beta 둘 다 설치되어 있어야 VC++ 10.0 프로젝트를 Visual Studio 11에서 열 수 있습니다.
    • Visual Studio 2010 Database (.dbproj) - 컨버전을 하면 열 수 있는데, 지원 안 되는 기능이 많네요. 꼭 문서 참고 하세요.

         

         

파일

  • BizTalk Flat file schemas - 파일을 추가 못함
  • Profile Reports File : 성능 프로파일 보고서 중 .vspx 파일만 열지 못함
  • Solution File : 솔루션 파일 중 .sou 파일이 있는데, 여기에 Break Point 등의 정보가 있는데 VS11 로 업그레이드 되고 나면 VS2010 에서 설정 정보를 잃어버릴 수 있다고 하네요.

Welcome to Parallel C#(16) - 분배 전략.

C# Parallel Programming 2012. 2. 17. 09:00 Posted by 알 수 없는 사용자
이번에는 TPL에서 제공하는 옵션에 대해서 알아보겠습니다. 병렬 작업을 위해서는 먼저 병렬로 수행할 수 있게끔 작업을 분할하는 일이 먼저 수행되어야 합니다. 예를 들어서 10000개의 데이터를 4개의 스레드가 나눠서 처리해야 하고, 각 10000개의 작업이 독립적이라면, 이걸 공평하게 4등분 할 것인지, 혹은 다른 방법을 사용할 것인지등을 결정하는 것 말이죠.


- 두 가지 선택.

TPL에서 작업 분할을 할때 사용하는 방법으로 구간 분할과 로드 밸런싱이 있습니다. 구간 분할을 루프의 크기를 스레드의 개수만큼 공평하게 나눠서 처리하는 것을 말합니다. 단순하죠.  :) 그리고 로드밸런싱은
처리할 구간을 미리 정하지 않고, 처리해야 할 작업에 따라서 각 스레드가 처리할 구간의 크기나 스레드의 개수가 유동적으로 변하게 됩니다. 이때 스레드하나가 이 작업을 담당하게 됩니다. 이 스레드는 작업 상황을 지켜보면서 그때 그때 스레드를 생성해서 작업을 맡기등의 역할을 맡게 되는 거죠. 그래서 작업을 끝낸 스레드가 다음에 처리할 구간을 할당받기 전까지 기다리는 시간이 필요하고, 이런 동기화에 따른 부하가 발생하게 되는 거죠. 나눠주는 구간의 크기가 작을 수록 스레드는 자주 구간을 할당받으려고 기다려야 하고 성능은 더 저하되는 거죠. :)

Parallel.For의 기본 동작은 로드 밸런싱을 사용하도록 되어 있습니다. 그래서 위에서 언급한 동기화 이슈가 자주 발생하는 경우 싱글스레드로 실행되는 for루프에 비해서 그다지 성능의 우위를 보이지 못하게 됩니다. 예제로 확인해볼까욤? ㅋㅋ

using System;

using System.Linq;

using System.Threading.Tasks;

using System.Collections.Concurrent;

using System.Collections.Generic;

 

namespace Exam20

{

    class Program

    {

        static void RangeParallelForEach(int[] nums)

        {

            List<int> threadIds = new List<int>();

            var part = Partitioner.Create(0, nums.Length);

 

            Parallel.ForEach(part, (num, state) =>

            {

                if (!threadIds.Contains(Task.CurrentId.Value))

                {

                    threadIds.Add(Task.CurrentId.Value);

                }

 

                for (int i = num.Item1; i < num.Item2; i++)

                {

                    nums[i] = nums[i] * nums[i];

                }

            });

 

            Console.WriteLine("Thread ID list of RangeForEach");

            foreach (var id in threadIds)

            {

                Console.WriteLine("{0}", id.ToString());

            }

        }

 

        static void ParallelFor(int[] nums)

        {

            List<int> threadIds = new List<int>();

 

            Parallel.For(0, nums.Length, (i) =>

            {

                if (!threadIds.Contains(Task.CurrentId.Value))

                {

                    threadIds.Add(Task.CurrentId.Value);

                }

 

                nums[i] = nums[i] * nums[i];

            });

 

            Console.WriteLine("Thread ID list of ParallelFor");

            foreach (var id in threadIds)

            {

                Console.WriteLine("{0}", id.ToString());

            }

        }

 

        static void Main(string[] args)

        {

            int max = 50000000;

            int[] nums1 = Enumerable.Range(1, max).ToArray<int>();

            int[] nums2 = Enumerable.Range(1, max).ToArray<int>();

 

            ParallelFor(nums1);

            RangeParallelForEach(nums2);

        }

    }

}

위 코드를 보면 로드밸런싱을 사용하는 Parallel.For와 Partitioner.Create 메서드를 이용해서 구간분할을 사용하도록 설정한 Parallel.ForEach를 사용하는 코드를 포함하고 있습니다. 이렇게 수행하면서 각 방법 별로 몇 개의 스레드가 생성되는지 확인한 결과를 볼까요.

Thread ID list of ParallelFor
1
2
3
4
5
6
7
8
9
10
--------------중략--------------
91
92
93
94
95
96
97
98
99
100
101
Thread ID list of RangeForEach
102
103
104
105
106
107
108
Press any key to continue . . .

구간 분할을 사용하는 경우(RangeForEach)는 고작 7개의 스레드가 생성되어서 작업을 처리한 것에 비해서, 로드밸런싱을 사용한 경우는 무려 101개의 스레드가 생성된 것을 볼 수 있습니다. 스레드가 많이 교체되면서 생기는 비효율성은 굳이 말을 안해도 되겠죵. 그렇다면 다음과 같은 코드로 실제로 어떤 속도의 차이가 발생하는지 확인을 해보시져 :)

using System;

using System.Linq;

using System.Threading.Tasks;

using System.Collections.Concurrent;

 

namespace Exam21

{

    class Program

    {

        static void NormalFor(int[] nums)

        {

            for (int i = 0; i < nums.Length; i++)

            {

                nums[i] = nums[i] * nums[i];

            }

        }

 

        static void ParallelFor(int[] nums)

        {

            Parallel.For(0, nums.Length, (i) =>

            {

                nums[i] = nums[i] * nums[i];

            });

        }

 

        static void RangeParallelForEach(int[] nums)

        {

            var part = Partitioner.Create(0, nums.Length);

 

            Parallel.ForEach(part, (num, state) =>

            {

                for (int i = num.Item1; i < num.Item2; i++)

                {

                    nums[i] = nums[i] * nums[i];

                }

            });

        }

 

        static void Main(string[] args)

        {

            int max = 50000000;

            int[] nums1 = Enumerable.Range(1, 10).ToArray<int>();

            int[] nums2 = Enumerable.Range(1, 10).ToArray<int>();

            int[] nums3 = Enumerable.Range(1, 10).ToArray<int>();

 

            //JIT컴파일을 위해.

            NormalFor(nums1);

            ParallelFor(nums2);

            RangeParallelForEach(nums3);

 

            nums1 = Enumerable.Range(1, max).ToArray<int>();

            nums2 = Enumerable.Range(1, max).ToArray<int>();

            nums3 = Enumerable.Range(1, max).ToArray<int>();

 

            DateTime normalForStart = DateTime.Now;

            NormalFor(nums1);

            DateTime normalForEnd = DateTime.Now;

            TimeSpan normalForResult = normalForEnd - normalForStart;

 

            DateTime parallelForStart = DateTime.Now;

            ParallelFor(nums2);

            DateTime parallelForEnd = DateTime.Now;

            TimeSpan parallelForResult = parallelForEnd - parallelForStart;

 

            DateTime rangeForStart = DateTime.Now;

            RangeParallelForEach(nums3);

            DateTime rangeForEnd = DateTime.Now;

            TimeSpan rangeForResult = rangeForEnd - rangeForStart;

 

            Console.WriteLine("Single-threaded for : {0}", normalForResult);

            Console.WriteLine("Load-balancing Parallel.For : {0}", parallelForResult);

            Console.WriteLine("Range-partition Parallel.ForEach : {0}", rangeForResult);

        }

    }

}

좀 어글리한 코드이긴 하지만, 싱글 스레드를 사용한 for루프와 로드 밸런싱을 사용하는 Parallel.For, 그리고 구간 분할을 사용하도록 한 Parallel.ForEach의 성능을 각각 비교한 코드입니다. 그럼 결과를 확인해보죠!

Single-threaded for : 00:00:00.3000763
Load-balancing Parallel.For : 00:00:00.3430858
Range-partition Parallel.ForEach : 00:00:00.2130545
Press any key to continue . . .

조금은 의외의 결과가 나왔습니다. 오히려 병렬로 작업을 처리한 Parallel.For가 순차적으로 실행되는 for루프에 비해서 낮은 성능을 낸 것이죠. 왜 그럴까욤? 첫 번째 원인은 너무 빈번하게 스레드 간의 작업 전환을 하느라 오버헤드가 컸던 점을 들 수 있을 것 같구요. 그리고 다음은, 병렬 작업에 사용되는 델리게이트의 내용이 너무 짧아서 입니다. 위 코드를 보면 델리게이트의 내용이 간단한 연산 한 줄로 이루어진 것을 볼 수 있는데요. 위 처럼 호출 수가 작은 경우는 큰 문제가 되지 않지만, 위의 코드 처럼 많은 횟수를 호출하는 경우 델리게이트 호출은 부담이 됩니다. 델리게이트의 내용을 처리하는 것 보다 델리게이트를 호출하는 시간이 더 많이 걸리게 되면서 일반 for루프보다도 못한 성능을 보여주는 거죠. 그래서 Partitioner.Create메서드를 이용해서 큰 작업 덩어리로 잘라줘서 이 오버헤드를 줄일 수 있습니다. 그 결과 위와 같은 시간이 나오게 된거죠.

어떻나요? 단순히 for루프를 Parallel.For로 교체하는 것만 가지고는 제대로된 성능을 기대하기 힘듭니다. 혹시, "어? 뭐야 당신 이전 포스트에서는 단순히 Parallel.For를 쓰기만 해도 성능이 좋아진다며?" 하는 생각이 드셨다면... 당신은 저의 팬...???!?!? ㅋㅋㅋㅋ 아마 기억하시는 분은 없겠죠. 암튼, 주의하고 볼일 입니다. 오늘은 여기까징~! :)
지난 포스팅에서 Break와 Stop메서드의 차이에 대해서 시덥잖은 퀴즈를 남겼었는데욤, 뭐 별로 궁금한 분들이 없거나 너무 쉬워서 코에서 바람 좀 내뿜은 분들이 많으리라 생각합니다. 저는 이게 뭔 차이인지 잠깐 헤맸습니다만... 허허허 :) 그럼 차이점에 대해서 잠깐 이야기를 해볼까욤.


- Parallel.For와 for의 브레끼는 닮았더라.

Parallel.For의 Break메서드는 for의 break와 좀 닮았습니다. for루프에서 break를 만나게 되면 그 즉시 for루프를 중단하게 됩니다. 그리고 break가 걸리기 전 까지의 인덱스에 대해서는 루프가 실행되었음을 보장할 수 있습니다. for루프는 처음부터 순차적으로 실행되기 때문이죠. 그런데 Parallel.For에서는 루프문의 길이에 대해서 각각의 스레드가 조금씩 나눠서 담당하게 됩니다. 예를 들면 1-10000까지의 구간이라면, 스레드 하나가 1-5000까지, 다른 스레드가 5001-10000까지 뭐 이런식으로 말이죠. 이런 상황에서 5100번째 인덱스에서 Break가 호출된다면 어떻게 될까요? 기존의 for루프를 사용하던 관점에서 보자면 당연히 5109번째 인덱스까지는 다 처리되었을 거라고 예상하게 됩니다. 이런 개발자의 기대를 저버리지 않기 위해서 Break메서드를 호출하게 되면 Break가 호출된 인덱스보다 작은 인데스에 대해서 남아있는 작업은 모두 실행하도록 합니다. 예제를 볼까요?

using System;

using System.Threading.Tasks;

 

namespace ConsoleApplication1

{

    class Program

    {

        static void Main(string[] args)

        {

            Parallel.For(0, 20, (i, loopState) =>

            {

                if (i == 10)

                {

                    loopState.Break();

                    Console.WriteLine("Break at {0}", i.ToString());

                }

                else

                {

                    Console.WriteLine(i.ToString());

                }

            });

        }

    }

}


아주 간단하게 0부터 19까지 Parallel.For루프를 돌면서 i가 10일때 Break를 호출해서 루프를 중단하도록 하는 코드입니다. 실행할 때마다 결과가 다르게 나오는데요, 그 중에 가장 설명하기 좋은 결과를 고르면!

0

1

2

3

4

6

5

Break at 10

7

8

9

Press any key to continue . . .


대략 이렇습니다. 스레드가 구간을 나눠서 루프를 실행하는데, 먼저 실행한 스레드가 0-6까지를 처리하고 다른 스레드가 10을 처리하는 순간 Break를 만나게 되는 거죠. 하지만 여기서 중단 되지 않고, 다른 스레드가 7, 8, 9를 처리하도록 해줍니다. 그래서 10에서 Break가 호출되었더라도 바로 중단하지 않고 10보다 작은 인덱스가 모두 처리되도록 해주는 것이죠.


- 장비를 정지합니다... 어 안되잖아?

Break를 즉시 중단하는 개념으로 생각하다 보면 조금은 이상할 수 있습니다만, 사실 기존의 for루프와 유사한 동작을 제공한다는 개념에서는 바람직한 동작이 아닌가 싶습니다. 그런데, 데이터에서 뭔가를 검색하는 경우는 어떨까요? 4명이 근무하는 사무실을 생각해봅시다. 뭔가 중요한 서류를 찾아야 해서 사장 이하 4명이 구역을 나눠서 사무실을 뒤지기 시작합니다. 한 명은 책상을, 한 명은 캐비넷을, 또 한 명은 창고를, 또 한 명은 잉여짓을. 이렇게 4명이 찾다가 누군가 한 명이 그 서류를 발견했습니다!!! 그러면 그 사람은 '심봤다 어허으어릉러허엏엉 나 심봤쪄영 뿌우 'ㅅ'~'하고 외치겠죠? 그러면 그 사람들은 그 찾는 작업을 멈추게 됩니다. 그게 정상이겠죠. '그럴리가 없엉 어흐어흐어흐러라어헝'하면서 나머지를 계속 찾는 사람은 '안돼에~'. 허허허허 :)

이런 경우에는 Parallel.For를 즉시 중시해야 합니다. 그럴때! 바로 Stop을 호출하게 됩니다.

using System;

using System.Threading.Tasks;

 

namespace ConsoleApplication1

{

    class Program

    {

        static void Main(string[] args)

        {

            Parallel.For(0, 20, (i, loopState) =>

            {

                if (i == 10)

                {

                    loopState.Stop();

                    Console.WriteLine("Stop at {0}", i.ToString());

                }

                else

                {

                    Console.WriteLine(i.ToString());

                }

            });

        }

    }

}

Break대신에 Stop을 호출한 코드죠. 결과능!

0

5

Stop at 10

Press any key to continue . . .


짤 없습니다. 그냥 중단해버리는 거죠. 자 지난 포스팅에서 왜 Stop을 호출한 게 미세하게 빨랐는지 아시겠나요? 소수는 1과 자신 외에 하나라도 나눌 수 있는 숫자가 존재하면 안되는 거죠. 그래서 for루프에서 숫자를 바꿔가면서 나눠보다가 하나라도 나눠지는 게 발견되면 그 즉시 중단하는 게 맞는 거죠. Break는 발견되더라도, 그 보다 작은 인덱스에 대해서는 모두 수행하게 되기 때문에 Stop에 비해서 아주 미세하게 느린 결과가 나오게 되는 거죵. 허허허허허 :) 참 별 내용 없네요 ㅠㅠ...

그럼 오늘은 여기까징~!

Welcome to Parallel C#(14.2) - 긴급 패치 2.

C# Parallel Programming 2012. 2. 14. 09:15 Posted by 알 수 없는 사용자

김명신님께서 또 아주 좋은 지적을 해주셨습니다~~ List<T>도 ConcurrentBag<T>이든 하나의 컬렉션을 이용하는 건 바람직하지 않은 것 같다는 의견이셨는데요, 동감합니다 :) 그래서 제 나름대로 해결책을 강구해봤는데욤. 스레드 로컬 변수를 이용해서 스레드 별로 작업을 시키고, 나중에 하나의 리스트로 모으는 것입니다. 코드를 볼까욤~?

using System;
using System.Collections.Concurrent;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
 
namespace ConsoleApplication1
{
    class Program
    {
        static readonly object _sync = new object();
 
        static IEnumerable<long> GetPrimeNumber(long num)
        {
            List<long> primeList = new List<long>();
 
            Parallel.For<List<long>>(0, num + 1, 
                () => new List<long>(), //스레드 로컬 변수 초기화
                (i, outerLoopState, subList) =>
            {
                bool isPrime = true;
                Parallel.For(2, i, (j, loopState) =>
                {
                    if (i % j == 0)
                    {
                        isPrime = false;
                        loopState.Break();
                    }
                });
 
                if (isPrime)
                {
                    subList.Add(i); //스레드 로컬 리스트에 추가
                }
 
                return subList;
            },
            (subList) => //각 스레드 종료 후에 취합
            {
                lock (_sync)
                {
                    primeList.AddRange(subList);
                }
            });
 
            return primeList;
        }
 
        static void Main(string[] args)
        {
            Stopwatch sw = new Stopwatch();
            sw.Start();
            IEnumerable<long> primeList = GetPrimeNumber(99999);
            sw.Stop();
 
            Console.WriteLine("Elapsed : {0}, Found prime counts : {1}",
                sw.Elapsed.ToString(),
                primeList.Count());
            //뭔가 한다.
        }
    }
}

위 코드를 보면, Parallel.For 루프에서 스레드 로컬 변수를 사용하도록 밑줄 친 부분들이 추가된 것을 볼 수 있습니다. 즉 이 Parallel.For는 List<long>타입의 스레드 지역 변수를 사용하며, 그 지역변수를 어떻게 초기화 할 것인지를 명시하고, 각 스레드가 종료할 때 지역 변수를 리턴하도록 한 것이죠. 그리고 Parallel.For의 마지막 매개변수로, 각 스레드가 종료할 때 어떤 동작을 취할 것인가를 명시하는데, 스레드가 끝날 때 리턴한 지역 변수가 매개변수로 들어오게 됩니다. 이렇게 하면 동기화를 좀 더 줄일 수 있는 것이죠. 그래서, 이왕 코드를 고친 김에 시간을 재봤습니다.

   ConcurrentBag<T>사용(초)  스레드 지역 변수 사용(초)
 GetPrimeNumber(99999)  2.54  2.52 
 GetPrimeNumber(199999)  9.32  9.25
 GetPrimeNumber(299999)  20.03  19.96

미세하게 스레드 지역 변수를 사용한 쪽이 빠르긴 한데요, 위 코드의 경우 하나의 리스트로 값을 합치는 데 시간이 좀 소요되어서 큰 속도 향상이 없는 것으로 보입니다. 동기화해서 수행해야 하는 작업이 간단할 수록 속도차이는 벌어질 것으로 보이는데요, 가능하면 각자 작업 후에 하나로 합치는 쪽이 더 효율적일 것 같네요.

부족한 실력이다 보니 이 이상 뭐가 떠오르지 않네요 -_-;; 더 나은 방법이 있으면 알려주세용~ :)

Welcome to Parallel C#(14) - 거기까지.

C# Parallel Programming 2012. 2. 13. 09:00 Posted by 알 수 없는 사용자

자~ 그럼 이제 부터는 다시 병렬 프로그래밍으로 돌아가서 조금 이야기를 해보도록 할 까욤~? 오래전에 써놓은 자료를 보다보니..... 제가 쓴 내용이지만 무슨 내용인지 이해가 안되는 글이 많아서 다시 정리를 하느라 조금 애를 먹고 있습니다. 하하하하 :) 뭐 제 수준이 딱 거기 까지니까 말이죵 호호호호.


- 병렬 작업을 중단할 때능?

기존의 for루프를 중단할 때는 그냥 간단하게 break하나 추가해넣으면 되었습니다. for루프는 정해진 순서에 따라서 순차적으로 실행되기 때문에 특정 조건에서 break를 만나서 루프가 중단 된다고 하더라도 항상 취소되기 이전까지의 내용은 모두 실행이 되었음을 보장할 수 있었죠. 즉,

for (int i = 0; i < 100; i++)

{

    if (i == 50)

    {

        break;

    }

}


위와 같은 코드가 있다고 할 때, i가 50이되어서 for루프가 중단된다고 할 때, i가 0-49일때는 이미 다 진행된 상태라는 것이죠. 그런데 이런 루프를 빠르게 처리하기 위해서 여러 스레드를 동시에 사용하는 Parallel.For를 사용했다고 한다면... 각 스레드가 나눠서 진행중인 작업을 어떻게 중단 시켜야 할까요?


- 브레이크를 걸자.

일단은 기존의 for루프와 가장 유사한 형태를 보이는 것 부터 살펴봅시당. 일단 비교를 위해서 다음과 같은 예제를 먼저 살펴보겠습니다.

using System;

using System.Collections.Concurrent;

using System.Collections.Generic;

using System.Diagnostics;

using System.Linq;

using System.Text;

using System.Threading.Tasks;

 

namespace ConsoleApplication1

{

    class Program

    {

        static IEnumerable<long> GetPrimeNumber(long num)

        {

            List<long> primeList = new List<long>();

 

            for (long i = 0; i <= num; i++)

            {

                bool isPrime = true;

                for (long j = 2; j < i; j++)

                {

                    if (i % j == 0)

                    {

                        isPrime = false;

                        break;

                    }

                }

                if (isPrime)

                {

                    primeList.Add(i);

                }

            }

 

            return primeList;

        }

       

        static void Main(string[] args)

        {

            Stopwatch sw = new Stopwatch();

            sw.Start();

            IEnumerable<long> primeList = GetPrimeNumber(99999);

            sw.Stop();

 

            Console.WriteLine("Elapsed : {0}, Found prime counts : {1}",

                sw.Elapsed.ToString(),

                primeList.Count());

            //뭔가 한다.

        }

    }

}


아주 간단한 코드인데요, 1부터 사용자가 입력한 숫자 중에서 소수를 구해서 리스트에 추가하는 코드입니다. 그리고 각 수가 소수인지 검사하는 부분에서 1이 아닌 수로 나눠지는 케이스가 발견 되면 그 즉시 break를 이용해서 중단을 시키고 있죠. 위 코드를 실행하면 CPU점유율은 아래와 같이 단일 스레드를 이용하는 것을 볼 수 있습니다.


그리고 위 코드를 3번 실행해서 얻은 평균 실행 시간은 6.28초 입니다. 그렇다면 위 코드의 Parallel.For버전을 살펴 볼까욤?

using System;

using System.Collections.Concurrent;

using System.Collections.Generic;

using System.Diagnostics;

using System.Linq;

using System.Text;

using System.Threading.Tasks;

 

namespace ConsoleApplication1

{

    class Program

    {

        static IEnumerable<long> GetPrimeNumber(long num)

        {

            List<long> primeList = new List<long>();

 

            Parallel.For(0, num + 1, (i) =>

            {

                bool isPrime = true;

                Parallel.For(2, i, (j, loopState) =>

                {

                    if (i % j == 0)

                    {

                        isPrime = false;

                        loopState.Break();

                    }

                });

 

                if (isPrime)

                {

                    primeList.Add(i);

                }

            });

 

            return primeList;

        }

       

        static void Main(string[] args)

        {

            Stopwatch sw = new Stopwatch();

            sw.Start();

            IEnumerable<long> primeList = GetPrimeNumber(99999);

            sw.Stop();

 

            Console.WriteLine("Elapsed : {0}, Found prime counts : {1}",

                sw.Elapsed.ToString(),

                primeList.Count());

            //뭔가 한다.

        }

    }

}


for를 Parallel.For로 바꿨고, break역시 Parallel.For의 인자로 넘어오는 loopState변수에 대해서 Break메서드를 호출하는 것으로 변경되었습니다. 이 코드를 실행해보면, 아래와 같이 CPU의 4개의 코어가 모두 동작하는 것을 볼 수 있습니다.




그리고 역시 위 코드를 3번 실행해서 얻은 평균 실행 시간은 5.32 초입니다. 전에 비해서 약 15%의 성능향상이 있었습니다. 물론 소수를 구하는 알고리즘 자체를 더 개선할 수도 있지만, 단순히 싱글 스레드를 이용한 코드와 작업을 병렬화 시켜서 멀티 코어를 이용한 코드간의 차이가 이정도라면 의미가 있지 않을까요? 그리고 좀더 CPU를 많이 사용하는 코드일 수록 그 차이는 더 벌어지겠죠 :)


- 그런데 사실은...

위 코드에서 몇자를 바꾸고 나면, 코드의 평균 실행 시간이 5.29초로 조금 더 떨어지게 됩니다. 그 코드를 올려드릴 테니 어디를 수정한 건지 한번 찾아보시죵 :)

using System;

using System.Collections.Concurrent;

using System.Collections.Generic;

using System.Diagnostics;

using System.Linq;

using System.Text;

using System.Threading.Tasks;

 

namespace ConsoleApplication1

{

    class Program

    {

        static IEnumerable<long> GetPrimeNumber(long num)

        {

            List<long> primeList = new List<long>();

 

            Parallel.For(0, num + 1, (i) =>

            {

                bool isPrime = true;

                Parallel.For(2, i, (j, loopState) =>

                {

                    if (i % j == 0)

                    {

                        isPrime = false;

                        loopState.Stop();

                    }

                });

 

                if (isPrime)

                {

                    primeList.Add(i);

                }

            });

 

            return primeList;

        }

        

        static void Main(string[] args)

        {

            Stopwatch sw = new Stopwatch();

            sw.Start();

            IEnumerable<long> primeList = GetPrimeNumber(99999);

            sw.Stop();

 

            Console.WriteLine("Elapsed : {0}, Found prime counts : {1}",

                sw.Elapsed.ToString(),

                primeList.Count());

            //뭔가 한다.

        }

    }

}


어딘지 찾으셨나요? 바로 loopState변수에 대해서 Break를 호출하던 것을 Stop으로 바꿔준 것입니다. 그래서 조금 더 효율적인 코드가 되는 것이죠. 왜 그럴까요? 그거에 대해서는!!!! 다음 포스팅에서 ㅋㅋㅋㅋㅋ


- 참고자료
http://stackoverflow.com/questions/1510124/program-to-find-prime-numbers

Welcome to Parallel C#(13) - 더 편하겡... 더 빠르겡...

C# Parallel Programming 2012. 2. 10. 09:00 Posted by 알 수 없는 사용자

- 뭐 좀 더 편한 방법이?

지난 포스팅에서는 Monitor를 좀 더 간편하게 사용할 수 있게 해주는 lock구문에 대해서 살펴봤었습니다. 그런데... 더 편한 방법이 있다는 군요. 한 줄이면 된다고 합니다. 긴 말 필요없이 예제를 보죠!

using System;

using System.Threading.Tasks;

using System.Threading;

 

namespace Exam25

{

    class Program

    {

        static readonly int count = 10000000;

        static int sum = 0;

 

        static void IncreaseByOne()

        {

            for (int i = 0; i < count; i++)

            {

                Interlocked.Increment(ref sum);

            }

        }

 

        static void Main(string[] args)

        {

            Task task = Task.Factory.StartNew(IncreaseByOne);

 

            for (int i = 0; i < count; i++)

            {

                Interlocked.Decrement(ref sum);

            }

 

            task.Wait();

            Console.WriteLine("Result = {0}", sum);

        }

    }

}

위 예제는 정확하게 lock을 사용한 예제와 동일한 결과를 냅니다. Interlocked라는 클래스에 정의된 메서드를 통해서 1씩 증가시키고 감소를 시킨거죠. 즉, lock사용해서 명시적으로 락을 획득하는 대신에 스레드 안전한 방식으로 값을 증가시키고 감소시키도록 하는 것입니다. 그런데, 여기까지만 보면 약간의 의문이 생깁니다. 생각보다 더 간단해 보이지가 않는 다는 말이죠. 허허허허 :)

그런데 한 가지 장점이 더 있습니다. 바로 수행 속도 인데요. 잠금을 획득하고 해제하는 게 시간이 많이 걸리는 작업이다 보니, lock을 사용하는 것보다 Interlocked를 사용하는 게 조금 더 빠릅니다. 그럼 얼마나 더 빠르다는 건지 간단한 코드를 통해서 직접 확인을 해볼까욤?

using System;
using System.Threading.Tasks;
using System.Threading;

namespace Exam26
{
    class Program
    {
        readonly static object sync = new object();
        static readonly int count = 10000000;
        static int sum = 0;       

        static void SpeedTest()
        {
            DateTime lockStart = DateTime.Now;
            for (int i = 0; i < count; i++)
            {
                lock (sync)
                {
                    sum++;
                }
            }
            DateTime lockEnd = DateTime.Now;
            TimeSpan lockResult = lockEnd - lockStart;

            sum = 0;

            DateTime InterlockedStart = DateTime.Now;

            for (int i = 0; i < count; i++)
            {
                Interlocked.Increment(ref sum);
            }
            DateTime InterlockedEnd = DateTime.Now;
            TimeSpan InterlockedResult = InterlockedEnd - InterlockedStart;

            Console.WriteLine("lock Result : {0}", lockResult);
            Console.WriteLine("Interlocked Result : {0}", InterlockedResult);
        }

        static void Main(string[] args)
        {
            //JIT 컴파일 수행
            SpeedTest();

            SpeedTest();
        }
    }
}


수행된 결과를 볼까요?

lock Result : 00:00:00.3270844
Interlocked Result : 00:00:00.1820249
lock Result : 00:00:00.3090990
Interlocked Result : 00:00:00.1820285
Press any key to continue . . .

두 번째 실행된 결과를 보면 Interlocked를 사용한 쪽이 70%정도 더 빠른 속도를 보이는 것을 할 수 있습니다. 위 코드 같이 단순한 연산이 많이 수행되는 경우에는 Interlocked를 사용하는 쪽이 조금 더 유리할 수 있겠죠. 물론 요즘 세상에 별로 신경쓸만한 차이는 아니라고 생각이 듭니다. 하하하하 그냥 이런 것도 있다는 거죠 :)

그럼, 오늘도 이만 하구요~ 다음에 또 뵙죵 하하하 :)

Welcome to Parallel C#(12) - 귀찮으면 안 해.

C# Parallel Programming 2012. 2. 8. 09:00 Posted by 알 수 없는 사용자
- 인류 발전의 원동력.

귀.찮.다. 이 세자로 이루어진 표현이 인류의 발전을 이끌어왔다면 확대해석일까욤. 정말 죠낸죠낸쵸오낸 귀찮다 보니 사람들은 어떻게 하면 반복적인 작업을 줄일 수 있을까 하는 문제를 생각하게 됩니다. 그래서 더 나은 방법을 고안해 내고, 더 빠르고 더 간편한 시스템, 그리고 나아가서 자동화를 생각하게 됩니다. 그러다 보니, 수작업으로 이루어진 프로세스는 실수의 여지가 많은 반면에 자동화로 이루어진 프로세스에서는 그 여지가 굉장히 줄어들게 되는 부수적인 효과를 얻게 되는 것이죠.

물론 귀찮음으로 인해서 인류는 많은 퇴보도 했을 겁니다. 복잡하고 비효율적인 것도 몸에 익으면 편하게 느껴지게 됩니다. 그리고 더 깔끔한 방법으로 바꾸려 하면 머리속에서는 엄청난 저항이 일어나게 되죠. 이미 한번 구성되어서 굳어진 뇌의 회로를 다시 구성해야 한다는 그...... 귀찮음. 허허허허허허


- 락에 자동화를 도입!

지난 포스트에서 Monitor를 이용해서 락을 거는 방법을 알아봤습니다. 하지만 어떤가요? 매번 try-finally블록을 사용해서 락을 걸고 해야 한다면? 그리고 Enter는 있는데 Exit를 깜빡하게 빼먹었다면? 어머나!!!!

그래서 C#에서는 귀찮음을 싫어하는 인류의 특성을 감안해서 간편한 Syntactic Sugar를 제공합니다. lock이라는 구문이 바로 그것입니다. 하하하하 :) 그럼 간단한 예를 보죠.

using System;

using System.Threading.Tasks;

 

namespace Exam24

{

    class Program

    {

        readonly static object sync = new object();

        static readonly int count = 10000000;

        static int sum = 0;

 

        static void IncreaseByOne()

        {

            for (int i = 0; i < count; i++)

            {

                lock (sync)

                {

                    sum += 1;

                }

            }

        }

 

        static void Main(string[] args)

        {

            Task task = Task.Factory.StartNew(IncreaseByOne);

 

            for (int i = 0; i < count; i++)

            {

                lock (sync)

                {

                    sum -= 1;

                }

            }

 

            task.Wait();

            Console.WriteLine("Result = {0}", sum);

        }

    }

}

어떤가요? Monitor를 사용해서 해주던 번거로운 작업이 lock이라는 구문으로 임계영역을 감싸주는 것으로 간단하게 해결 되었습니다. 자, 그럼 lock이라는 편리한 구문 뒤에 실제로 생성되는 코드를 한번 확인해 볼까욤?

private static void Main(string[] args)

{

    Task task = Task.Factory.StartNew(new Action(Program.IncreaseByOne));

    for (int i = 0; i < count; i++)

    {

        object CS$2$0000;

        bool <>s__LockTaken1 = false;

        try

        {

            Monitor.Enter(CS$2$0000 = sync, ref <>s__LockTaken1);

            sum--;

        }

        finally

        {

            if (<>s__LockTaken1)

            {

                Monitor.Exit(CS$2$0000);

            }

        }

    }

    task.Wait();

    Console.WriteLine("Result = {0}", sum);

}

 

private static void IncreaseByOne()

{

    for (int i = 0; i < count; i++)

    {

        object CS$2$0000;

        bool <>s__LockTaken0 = false;

        try

        {

            Monitor.Enter(CS$2$0000 = sync, ref <>s__LockTaken0);

            sum++;

        }

        finally

        {

            if (<>s__LockTaken0)

            {

                Monitor.Exit(CS$2$0000);

            }

        }

    }

}

위에서 볼 수 있듯이 생성되는 코드는 Moniter를 이용한 코드와 정확하게 같은 코드를 사용하고 있습니다. 대신에 훨씬 간단하죠? 물론 lock구문을 통해서 락을 걸어줄 객체는 Monitor를 사용할 때와 동일하게 readonly static이어야 합니다.
 
락을 거는 대상이 되는 잠금 객체에 대해서 조금 덧붙이자면, 락을 걸어줄 객체는 값 형(Value 타입)이 아닌 참조 형(Reference 타입) 객체여야 합니다. 왜냐면, 값 형의 경우는 다른 변수에 값을 대입할 때 값을 복사해서 넘겨 주기 때문에 매번 메모리에 동일한 값이 새로 생겨나게 됩니다. 이렇게 되면 Enter메서드에서 받는 잠금 객체와 Exit메서드에서 받는 잠금 객체가 서로 다른 객체가 되므로 SynchronizationLockException이 발생하게 됩니다. 반면에 참조 형 객체의 경우는 동일한 객체에 대한 참조를 복사해서 넘겨주므로 항상 동일한 객체에 대해서 Enter와 Exit를 호출하게 되겠죠.

그럼~ 다음에 또 뵙죵~ :)

Welcome to Parallel C#(11) - 동기 부여.

C# Parallel Programming 2012. 2. 6. 09:00 Posted by 알 수 없는 사용자

우와~!!!! 증말 오랜만입니다. 이게 얼마만이죠? 하하하하하하하하-_-

기다리는 분이 아무도 없다는 건 알지만, 저 자신을 위해서 그냥 한번 호들갑을 떨어봤습니다. 허허허허 원래 제가 쓰는 포스팅이 다 그렇죠. 병렬 프로그래밍에 대해서 정리해놓은 자료가 조금 있었는데요, 매우 늦긴 했지만 그래도 일단 공부하면서 정리해놓은 자료를 그냥 썩히기는 아까워서 조금씩 옮겨 적어볼까 합니다. 그래서 다시 시작하는 거지요! 호호호호 :)

언제나 그렇듯이 제 포스팅은 공부하면서 정리하는 겁니다. 다른 분들이 적으시는 것 처럼 내공이 깊지도 않고, 그다지 실용적이지도 않지요. 의견이 있으시면 거침없이! 하지만 예의는 쪼금 지켜 주시면서! 가르침을 더 해주시면 읽으시는 분들에게 더 도움이 될 겁니다. 짧은 인생 Love & Peace! 그럼 또 초큼씩 풀어 볼까욤? ㅋㅋㅋ


- 화장실이 한 개!!!

4인 가족 기준으로 화장실이 한 개라고 생각을 하면..... 어머나!!! 끔찍해!!! 출근 시간이 되면 화장실에 응가를 때리러 러시아워가 벌어집니다. 먼저 들어간 사람은 느긋하게 다이빙하는 응가에 예술 점수를 매기면서 시간을 보낼 수 있지만, 출근 시간과 이제 그만 포기하자고 하는 장과 협상을 벌이면서 조마조마해야 하죠. 화장실을 원하는 사람은 4명인데, 화장실이 하나이다 보니, 먼저 들어간 사람이 화장실을 선점하고 문을 잠가서 락을 걸어버리면, 화장실을 원하는 다른 사람들은 그 락이 해제 될 때까지 인고의 시간을 보내야 하는 거죠. 어머나 슬픈이야기...ㅠㅠ

그러면 락을 걸지 못하게 하면 효과적인 해결책이 될까요? 일보고 있는데 갑자기 문을 열고 들어와서는 '난 얼굴 씻고 이빨만 닦으련다 변기를 쓰는 것도 아니니 너랑 내가 이 화장실을 평화롭게 공유하면서 각박한 출근 시간에 조그마한 훈훈함이라도 나눠가지지 않겠느냐' 하면 뭐 괘안을 수도 있겠습니다만.... 조금만 더 생각을 해보면 말이죠. 응가라는 건 굉장한 집중이 요구됩니다. 그리고 아무도 보는 사람이 없다는 안도감 속에서야 차분히 진행될 수 있는 일종의 비밀 의식 같은 거죠. 화장실을 공유하는 훈훈함 속에서 응가를 제대로 할 수 는 없습니다. 그리고 세면을 하는 사람 역시 은은하게 풍겨나오는 향기에 정신을 빼앗기다 보면 어서빨리 탈출하고 싶은 욕구에 사로잡히게 되어 세면을 제대로 할 수 없게 됩니다.

즉, 락을 거는 게 가장 효율적이라는 거죠. 여담이지만 그래서 저는 공중화장실에서는 응가를 안하는 편입니다. 정신 사나워서 집중을 할 수 없거든요. :)


- 그래서 필요한 동기화

그래서 프로그래밍을 하면서도 동기화에 신경을 써줘야 합니다. 컴퓨터의 자원을 한정적이고 그걸 호시탐탐 선점하려는 스레드의 욕구를 잘 제어해줘야 하기 때문이죠. 그럼 동기화 없이 스레드의 탐욕에 맡긴 결과가 어떻게 되나 한번 볼까요. 후후후후

using System;

using System.Threading.Tasks;

 

namespace Exam22

{

    class Program

    {

        static readonly int count = 10000000;

        static int sum = 0;

 

        static void IncreaseByOne()

        {

            for (int i = 0; i < count; i++)

            {

                sum += 1;

            }

        }

 

        static void Main(string[] args)

        {

            Task task = Task.Factory.StartNew(IncreaseByOne);

 

            for (int i = 0; i < count; i++)

            {

                sum -= 1;

            }

 

            task.Wait();

            Console.WriteLine("Result = {0}", sum);

        }

    }

}

두 개의 스레드를 이용해서, 주 스레드에서는 sum의 값을 1씩 감소 시키고, 추가 스레드에서는 증가 시키도록 해놓은 평범한 예제입니다. 하지만, 서로 뺏고 뺏기는 리얼 야생 탐욕이 살아 숨쉬는 정글의 법칙이 녹아들어 있습니다. 결과를 보시죠.

Result = 17104

계속하려면 아무 키나 누르십시오...

분명히 같은 횟수로 1씩 증가시키고 감소를 시켰는데 이런 결과가 나오다니!!! 매번 실행 할때 마다 다른 값이 나오긴 하지만, 이 결과는 분명 이상합니다. 오래전 포스팅이지만 원자성에 대해서 잠깐 이야기를 한적이 있었는데요, 특정 작업이 실행 될 때 그 작업 외에 다른 작업이 끼어들어서는 안된다는 원칙을 이야기 하는 것입니다. 그렇다면! 위에서 사용중인 +=, -= 연산자는 분명히 원자성을 위반하고 있는 것으로 보입니다.

단순하게 'a += 1' 을 가지고 생각해볼까욤. 이 연산은 몇 가지 단계 나누어 집니다. 우선 a의 값을 가져오고, 가져온 값을 1 증가 시키고, 증가된 값을 다시 a에 대입하는 단계로 나누어 지는 거죠. 그런데 a값을 가져온 직후에 다른 스레드가 a의 값을 변화시킨다면 어떻게 될까요? 이런 거 말로 설명하면 설명하는 사람도 읽는 사람도 불통에 빠지게 됩니다. 현재 sum이라는 변수의 값이 5라고 가정하고 간단하게 표를 통해 설명 해보죠 ㅋ

 증가 스레드(sum += 1 수행) 감소 스레드(sum -= 1 수행) 
   5를 읽어옴
 5를 읽어옴  
 1증가시킴  
 6을 저장  
  1감소시킴 
  4를 저장 

위와 같은 순서로 수행이 된다면?

분명히 1증가와 1감소가 수행되었지만, 결과는 1감소만 수행된 셈이죠. 이런식으로 서로 방해와 방해를 하다보면 이상한 결과가 나오게 되는 겁니다. 그래서 화장실에 락을 걸어서 순서를 정해서 사용하도록 하듯이, 순서를 정해줘야 하는 겁니다. 하하하하 :)

- 모니터로 락을 걸자! 락을 걸자!

자 그럼 아주 간단하게, 모니터로 락을 걸어 볼까요? 준비물은 여러분이 지금 보고 있는 모니터를 사용하면 됩니....는 훼이크고 Monitor라는 클래스를 이용해서 락을 걸어보겠습니다. Enter와 Exit라는 메서드를 이용해서 락을 걸고 빠져나가도록 통제를 하게 되는 데요. 참고로 이렇게 둘 이상의 스레드가 동시에 접근하면 안되기 때문에 락을 걸어야 하는 부분을 임계여역(Critical Section)이라고 합니다. 허허허허. 그럼 Monitor를 사용한 예제를 한번 보시죰.

using System;

using System.Threading.Tasks;

using System.Threading;

 

namespace Exam23

{

    class Program

    {

        readonly static object sync = new object();

        static readonly int count = 10000000;

        static int sum = 0;

 

        static void IncreaseByOne()

        {

            for (int i = 0; i < count; i++)

            {

                bool locked = false;

                Monitor.Enter(sync, ref locked);

                try

                {

                    sum += 1;

                }

                finally

                {

                    if (locked)

                    {

                        Monitor.Exit(sync);

                    }

                }

            }

        }

 

        static void Main(string[] args)

        {

            Task task = Task.Factory.StartNew(IncreaseByOne);

 

            for (int i = 0; i < count; i++)

            {

                bool locked = false;

                Monitor.Enter(sync, ref locked);

                try

                {

                    sum -= 1;

                }

                finally

                {

                    if (locked)

                    {

                        Monitor.Exit(sync);

                    }

                }

            }

 

            task.Wait();

            Console.WriteLine("Result = {0}", sum);

        }

    }

}

자, 코드를 보면 락이 걸려있는지를 판별하기 위해서 readonly static으로 sync라는 변수를 선언하고, 그 변수에 대해서 락을 걸로 해제하는 것으로 특정영역에 대한 락을 걸도록 했습니다. 그리고 Monitor를 통해서 들어가고 나오는 순서를 정해주고 있죠. 만약에 주 스레드에서 sync에 대해서 락을 획득하고 sum을 감소시키는 중이라면, 다른 스레드는 sync에 대한 락이 해제 될 때까지 임계영역에 들어가지 못하고 대기하게 됩니다. 그렇다면? 각자가 원하는 작업을 하는 동안 다른 스레드가 방해를 하지 못하겠죵?

참고로 락을 걸고 해제하는 대상이 되는 sync라는 객체를 보면, readonly이므로 객체의 값을 변경시킬 수 없는 immutable한 객체이고, static이므로 유일하게 존재하게 됩니다. 이렇게 복사본이 없고, 값을 변경시킬 수 없는 객체에 대해서 락을 거는 것이 안전한 방법이지요. 위 코드를 실행하면 다음과 같은 결과가 나오게 됩니다.

Result = 0

계속하려면 아무 키나 누르십시오...

이거시 바로 우리가 기대했던 결과지요. 하하하하하하하하. 아... 좀 불편한 자세로 포스팅을 하고 있으려니 허리가..... 일단 오늘은 여기까지 하겠슴니다 하하하하 :)

코딩된 UI 테스트 에 커스텀 어설션 추가하기.

Visual Studio 2010 2011. 11. 15. 09:00 Posted by 알 수 없는 사용자
코딩된 UI 테스트를 하려고 하다 보면, '코딩된 UI 테스트 빌더'를 사용하게 됩니다.


그런데 코딩된 UI 테스트 빌더를 사용하다 보면, 어설션을 추가할 수 있는 속성의 수가 매우 제한 적인 것을 알 수 있습니다. 예를 들어서, WPF의 리스트 박스에 항목이 몇 개 있는지를 나타내는 Count와 같은 속성에 어설션을 추가하고 싶은데, 그런 속성을 코딩된 UI 테스트 빌더를 사용하면 찾을 수가 없는 것이죠.


이럴 때는 코드를 통해서 어설션을 추가해야 합니다. 그래서 다음과 같이 UIMap.Designer.cs에 어설션을 추가합니다.


그리고 테스트를 실행하면, 다음과 같이 테스트가 통과하게 되죠.


하지만, 코딩된 UI 테스트 빌더를 이용해서 새 테스트를 추가하거나, 편집을 수행하는 순간 UIMap.Designer.cs에 추가한 코드는 날아가 버립니다. 이 때문에 UIMap클래스는 partial 클래스로 선언이 되어 있습니다. 디자이너가 생성하는 코드는 UIMap.Designer.cs에, 그리고 코딩된 UI 테스트 빌더를 사용해서 추가하기 힘든 코드는 UIMap.cs에 직접 추가하게 되는 것이죠. 그렇다면 위 테스트는 UIMap.cs에 다음과 같이 코드를 추가하면 간단하게 해결 됩니다.

public partial class UIMap
{
    /// <summary>
    /// 리스트 박스의 항목 개수를 테스트하는 메서드
    /// </summary>
    public void CheckListItemCount()
    {
        int expectedCount = 3;
        int actualCount = this.UIMainWindowWindow.UIMyListBoxList.Items.Count;
        Assert.AreEqual(expectedCount, actualCount);
    }
}

그리고 테스트 메서드에서 CheckListItemCount를 호출하도록 코드를 추가해주면 되는 것이죠.

[TestMethod]
public void CodedUITestMethod1()
{
    // 이 테스트의 코드를 생성하려면 바로 가기 메뉴에서 "코딩된 UI 테스트에 대한 코드 생성"을 선택한 다음 메뉴 항목 중 하나를 선택하십시오.
    // 생성된 코드에 대한 자세한 내용은 http://go.microsoft.com/fwlink/?LinkId=179463을 참조하십시오.
 
    this.UIMap.SelectionTest();
 
    this.UIMap.CheckListItemCount();
}

그러면, 의도 했던 테스트가 제대로 추가 되는 것을 볼 수 있습니다.

정말 오랜만에 썼는데, 쓰고 나니 별 내용이 없는 포스트 네요 ㅠ_ㅠ;; 다음에 또 찾아 뵙겠습니다.

ps.
예제 코드를 첨부해드립니다. 예제는 Visual Studio 2010에서 작성했습니다.

[KGC 2011] 발표 자료

DirectX 11 2011. 11. 14. 08:00 Posted by 알 수 없는 사용자


안녕하세요~ 조진현입니다.
얼마 전 대구에서 KGC 2011 행사가 있었습니다.
저는 그 곳에서 DirectX11 과 관련한 발표를 진행하고 왔습니다.
그래서 발표 슬라이드를 공개해 드립니다.

특히나 이번 발표 때, C++ AMP 에 대한 언급이 있었습니다.
AMP는 아래 링크에 흥배님이 자세히 설명해 주셨습니다.
http://vsts2010.net/591

빠른 시간 내에 발표 때 언급했던 C++ AMP 와 관련한 내용을
팀 블로그에 게재하도록 하겠습니다..^^

[StartD2D-8] 투명 이미지 다루기

DirectX 11 2011. 9. 28. 08:00 Posted by 알 수 없는 사용자


이번 시간에 다룰 것은 투명 이미지 입니다.
얼마 전 댓글로 문의하신 내용인데 답변을 달기가 조금 부족한 듯 싶어서,
이렇게 별도로 아티클(?)로 남깁니다.

예전에 Win32 API 로 알파가 있는 이미지를 표현하는 작업은 무척 번거로운 작업이였습니다.
이미지 색상에 알파가 고려되어지면, 각 색상 성분마다 알파 연산을 해주어야 합니다.
또한 RGB 각 성분이 8비트씩 사용하는데 A성분이 추가되어지면서,
다시 8비트의 추가 데이터들이 각 색상값들에 필요하게 됩니다.
용량이 커지면 성능에 문제가 생기게 되는 것은 당연한 일입니다.

그래서 이를 흉내내기 위한 대안으로 마련된 것이 ColorKey 라고 불리는 기법입니다.
이 기법은 이미지 내의 특정 색상을 표현하지 않음으로써 구현됩니다.
아래의 그림을 예로 들어보겠습니다.



이미지 내에서 배경이 모두 붉은 색으로 되어있습니다.
이런 경우에 붉은 색을 ColorKey로 지정해서 데이터를 읽지 않는 것입니다.
그러면, 캐릭터 관련 색상만 메모리에 기록되게 됩니다.
이 방법을 사용하면 24비트 비트맵만으로 캐릭터를 표현할 수 있습니다.
주의해야 할 점은,
ColorKey 에 해당하는 색상 값을 아티스트들에게 사용하지 말 것에 대한
사전 협의가 있어야 겠지요.

아쉽게도(?) Direct2D에서 이 ColorKey 사용에 대한 API를 찾지 못했습니다.
( Direct3D 에는 있습니다.^^ )

사실 ColorKey 방식이 널리 이용되긴 하지만,
근본적으로 알파 처리를 이용하며 관련 효과를 모두 구현할 수 있습니다.
그렇기 때문에, 굳이 ColorKey 를 염두할 필요성은 없습니다.

이번에 샘플에 사용한 이미지는 알파가 있습니다.

 


우측의 흑백 이미지가 알파 성분만 표현한 이미지 입니다.
당연히 검은 부분은 알파 성분이 0 이기 때문에
해당 영역은 화면에 표현되지 않을 것입니다.

이번에 살펴볼 샘플은 아래와 같습니다.



똑같은 이미지 파일에서 데이터를 읽었지만,
위의 그림은 알파 처리가 되어서 동물 부분만 출력이 되었습니다.
하지만 아래 부분은 알파처리가 이루어지지 않아서 이미지 영역이 모두 출력되었습니다.

이번 결과의 차이는 WIC를 이용한 것입니다.
우리가 지금껏 무심코(?) 지나쳤던 WIC의 컨버터를 기억하십니까?


제가 이번 샘플을 위해서 약간 개량을 했습니다.
두 사용법에 별 차이는 없지만, GUID_WICPixelFormat... 부분이 보일 것입니다.
이 인자가 바로 두 이미지의 차이를 만들어낸 부분입니다.
즉, 컨버터에서 데이터를 어떤 포맷으로 읽어들일지를 설정하는 부분입니다.

첫번째는 알파처리를 수행하는 방법으로 데이터를 읽어들입니다.
GUID_WICPixelFormat32bppPBGRA는
4개의 색상 채널을 가지고 채널당 8개의 비트를 가지고 있으며,
픽셀 당 32비트를 표현하며 UINT로 각 색상이 저장되어 있는 포맷을 의미합니다.

두번째 알파처리를 하지 않는 GUID_WICPixelFormat32bppBGR은
3개의 색상 채널과 8비트로 각 채널을 표현하는 32비트 픽셀 포맷을 의미합니다.
이 포맷도 UINT로 각 색상 성분을 표현합니다.
이 경우에는 알파 채널이 존재하지만, 실제로 읽어들이지 않습니다.
즉, 알파 채널을 무시하는 것입니다.

관련 포맷이 매우 방대하기 때문에, 여기서 더 이상 자세히 다루지 않습니다.
중요한 것은 이 컨버터 덕분에 별다른 수고 없이 알파 처리를 쉽게 수행할 수 있습니다.

Direct2D 가 사실 많은 부분을 우리가 모르게 자동적으로 처리하는 부분이 많이 있습니다.
Direct2D에서는 프로퍼티를 생성하는 부분들이 많이 있습니다.
예를 들면 다음과 같은 것들입니다.



사실 이 프로퍼티 정보들을 별도로 설정하지 않으면,
자동적으로 Direct2D에서 처리를 해버립니다.
혹은 디폴트 생성자들이 모두 들어있습니다.
자동적으로 처리되는 부분들 이외의 기능이 필요하다면,
이들을 잘 제어해야만 하겠지요..^^

부족하지만 샘플을 참조해 드립니다..^^

[StartD2D-7] 변환의 중심과 확대/축소/찌그러짐

DirectX 11 2011. 9. 26. 08:00 Posted by 알 수 없는 사용자


< 변환의 중심 점은 어디인가? >

Direct2D의 변환과 관련된 API는 모두 변환을 수행할 중심점을 함수 인자로 요구를 합니다.
그렇다면, 이 중심점은 스크린 기준에서 정의되어지는 것일까요?

다음과 같은 다람쥐 그림이 있다고 가정해 보겠습니다.


이 그림은 ( 100, 100 ) 의 크기로 그려지기를 원한다고 가정해 보겠습니다.

 


그리고 우리의 모니터에 ( 300, 200 ) 위치에 그려지기 원하도록 설정하겠습니다.
그러면, 우리에게 변환을 위한 중점을 설정하기 위한 기준 좌표는 어떻게 설정되어야 할까요?
그림의 좌측 상단을 변환의 중점으로 원한다면 ( 300, 200 )으로 설정하면 될까요?
그림의 좌측 상단이 변환의 중점이 된다는 말의 의미를 잘 되새겨 보시기 바랍니다.

그림의 중심을 기준으로 중점을 설정해 두는 것이 훨씬 쉬운 개념으로 변환할 수 있습니다.
즉, 위의 그림에서 변환의 중심이 되는 좌측 상단은 좌표는 ( 0, 0 ) 이 되는 것입니다.
만약, 우측 하단이 변환이 중심이 되길 원한다면 ( 100, 100 )을 설정하면 됩니다.

앞서 살펴 보았던 샘플에는 이 의미를 그냥 넘겼지만
이번에 제공되는 샘플에서는 이를 고려해서 모두 작성했으니,
유심히 살펴보시기 바랍니다.^^

우리는 이 개념을 다음과 같이 지금까지 사용하고 있었습니다.


D2D1_RECT_F 정의의 변수가 보이시나요?
바로 이 dxArea 를 기준으로 변환이 되는 중점을 설정하는 것이 이해하기가 편리합니다.^^

이번 샘플은 지난 번 샘플의 연장에 있습니다.
지난 번 샘플에서 이번 내용과 관련된 부분을 추가 했습니다.

 




< Scale( 확대/축소 ) >

확대/축소 작업은 1.0을 기준으로 이루어집니다.
1.0 보다 작으면 축소가, 1.0보다 크다면 확대가 이루어 집니다.
이 작업은 D2D1::Matrix3x2F::Scale() API를 통해서 이루어 지는데,
역시나 변환의 중점을 요구합니다.^^



만약 좌측 상단을 기준으로 확대를 하면 다음과 같은 개념입니다.






< Skew( 찌그러뜨리기 ) >

마지막 변환은 찌그러뜨리기 작업입니다.
이는 Matrix3x2F::Skew() API를 통해서 설정할 수 있습니다.
함수 인자로 받는 것은 X축과 Y축의 찌그러질 각도와 역시나 기준이 되는 중점입니다.



역시나 변환이 되는 중점에 따라 결과가 변합니다.
아래의 그림은 30도씩 찌끄러뜨린 결과입니다.
첫번째는 X축만 적용한 것이고, 두번째는 Y축을,
세번째는 X와 Y축 모두를 30도씩 찌그러뜨린 결과입니다.



부족하지만, 제가 작성한 샘플을 첨부해 드립니다.^^


 

[StartD2D-5] Direct2D의 리소스 기본 개념.

DirectX 11 2011. 7. 11. 08:30 Posted by 알 수 없는 사용자

 

 

Direct2D 리소스( Resource ) 기본 개념

 

Direct2D 에서 리소스라는 것은 단지 메모리를 의미합니다.

그 메모리는 지오메트리(Geometry)나 비트맵 이미지가 될 수도 있습니다.

즉, 이들 리소스는 메모리들이 추상화 된 일종의 개념적인 분류들입니다.

 

이들 리소스를 처리해서 모니터에 최종적으로 보여주는 것이 Direct2D의 역할입니다.

이전 까지 사용되던 GDI 도 바로 이런 역할을 하는 것입니다.

 

하지만, GDI와 Direct2D 는 리소스 처리 방식이 완전히 다릅니다.

앞선 시간을 통해서, GDI는 CPU만을 활용한다고 꾸준히 언급했습니다.

 

반면에, Direct2D는 CPU와 GPU를 동시에 활용합니다.

CPU와 GPU를 동시에 활용하기 때문에,

리소스들도 이들에 맞게 추상적으로 재분류 되어야 합니다.

 

Direct2D는 이 리소스들을 크게 두 가지 형태로 분류합니다.

바로 디바이스 독립적인 리소스( device-independent resource )와

디바이스 의존적인 리소스( device-dependent resource )로 분류하고 있습니다.

이들 두 리소스들은 모두 ID2D1Resource 인터페이스를 상속받습니다.

 

 

디바이스 독립적인 리소스

 

디바이스 독립적인 리소스라고 하는 것은 CPU에 의해서 처리되는 리소스를 의미합니다.

단어 자체에서 볼 수 있듯이,

이들 리소스는 사용자의 그래픽 하드웨어와 상관없는 처리 결과를 보장합니다.

 

뒤에서 살펴보겠지만, 지오메트리를 표현하는 인터페이스들이 여기에 속합니다.

( 조금 더 정확히 나열하면, ID2D1DrawingStateBlock, ID2D1Factory, ID2D1Geometry,

ID2D1GeometrySink, ID2D1SimplifiedGeometrySink, ID2D1StrokeStyle 등이 여기에 속합니다. )

아래는 이런 디바이스 독립적인 리소스들의 계층구조를 보여주는 그림입니다.

 

 

 

 

 

디바이스 의존적인 리소스

 

반면에 디바이스 의존적인 리소스는 GPU에 의해서 처리되는 리소스를 의미합니다.

사용자들이 가지고 있는 그래픽 하드웨어들은 매우 다양하기 때문에, 그 기능들을 모두 동일한 방식으로 처리하는 것이 쉽지 않습니다.

( 각각의 하드웨어마다 성능이나 명령어들이 모두 차이가 나기 때문이겠죠..^^ )

즉, 이들은 사용자의 하드웨어들에 따라서 결과가 차이가 날 수 있습니다.

이 차이라는 것은 눈으로 확인 가능한 차이를 얘기하는 것이 아니라,

그래픽 하드웨어들이 생성하는 명령어들과 성능 등과 같은 차이를 얘기하는 것입니다.

 

우리가 보는 모니터는 그래픽 하드웨어들이 생성한 명령어들의 최종적인 결과입니다.

리소스들도 바로 이 그래픽 하드웨어의 영향을 받아서 결과가 생성되는 것입니다.

 

앞서 우리가 화면에 렌더링 하기 위해서 만들었던 렌더타겟이나 브러시, 이미지 같은 리소스들은 모두 여기에 속합니다.

아래의 그림은 디바이스에 의존적인 리소스들의 계층구조를 표현하는 그림입니다.

 

 

 

 

Direct2D는 리소스 처리 방식은 되도록이면 GPU를 활용합니다.

GPU 처리가 불가능하다면, 자동적으로 CPU로 처리하게 됩니다.

GPU를 활용하는 리소스라면, 더욱 높은 품질로 빠르게 처리할 수 있습니다.

 

이들 리소스에 대한 설명은 다음 시간부터 차근히 살펴보겠습니다.^^

 


2010 겨울 마이크로소프트는 XBOX 360 새로운 사용자 인터페이스로 프로젝트 명 나탈을 키넥트라는 이름으로 출시했습니다(Kinect for Xbox 360). 이후 키넥트는 기록상 가장 빨리 판매된 가전기기로 선정되었고, 최근에 나온 마이크로소프트의 제품 사용자에게 가장 빠른 시간에 인정받는 제품으로 인정 받은 것 같습니다.

키넥트는 상황인지 컴퓨팅 중 NUI의 일반 사용자 버전으로 개발자, 과학자, 그리고 해커들에게도 상당히 매력적으로 보인 같습니다. 여기에 의료와 전시 다양한 분야에서 키넥트를 활용한 시나리오가 거론되면서, Xbox360 아닌 PC에서의 적용에 대한 다양한 시도가 일어나게 됩니다.

 마이크로소프트는 이러한 시도에 대해 과거와는 다른 접근 방법을 보이게 되고, 개발자와 과학자들을 위한 SDK 출시를 선언하게 됩니다.

MIX 발표와는 달리 오래 기다리기는 했지만, 마이크로소프트는 Windows 7에서 구동할 있는 키넥트용 개발 키트를 출시하게 되었습니다.(Kinect for Windows SDK)

공식 사이트(http://research.microsoft.com/kinectsdk)

키넥트를 활용할 있는 방법을 사용자와 장치 가지 기준으로 보면, 사용자는 일반 소비자와 기업 소비자, 장치는 PC Xbox 구분 있습니다.

현재 우리가 키넥트라고 부르는 것은 정확히 kinect for xbox 360으로 xbox 이용한 일반 소비자를 대상으로 게임 인터페이스로 있습니다.


<
그림1> 키넥트용 Xbox 360 게임과 키넥트를 통한 동작 인식

그림1에서 보이는 처럼, 스포츠와 모험, 그리고 댄스를 중심으로 게임들이 인기를 끌게 되고,

디바이스를 PC 바뀌게 되면, 장르가 단순히 게임을 떠나 의료와 교육 부분이 눈에 뛰게 됩니다.

가장 대표적인 것이 지난 Mix2011에서 보여준 데모들이 같습니다.

#Kinect for Windows SDK Preview(http://www.youtube.com/watch?v=co8jEyVjlPo)

내용 이외에도 유튜브를 보면 다양한 재미있는 동영상을 보실 있으실 입니다.

기업 부분에서는 홍보와 전시, 그리고 PC 제어가 쉽지 않은 공간 등에서 활용도가 많아지게 같습니다.

 

그럼, 이제 키넥트의 실체를 살펴 보도록 하겠습니다.

키넥트는 그림1 2 같이 개의 3D 센서와 하나의 RGB 카메라, 그리고 개의 마이크로 구성되어 있습니다.


<그림2> 키넥트 구조1

<그림3> 키넥트 구조2

<그림4> 키넥트 구조 3

키넥트의 동작 방식은 다음과 같습니다. 먼저 적외선 조명기에서 적외선을 방출합니다. 물체에 반사되는 적외선을 CMOS 카메라가 인식하고, 심도(Depth) 인식해서 처리 합니다. 컬러 이미지 CMOS 카메라에서 인식된 색과 위의 정보를 모두 모아서 스켈레톤 형태로 동작을 처리하는 방식으로 사용됩니다.

 

그럼, Xbox PC에서 키넥트는 어떤 차이점이 있을까?

정밀도(해상도) 부분은 TV 기반으로 XBox 모니터를 기반으로 PC 보다 떨어지게 됩니다. 아무래도 다양한 TV 만족시키기 위해서는 높은 해상도를 사용하기 쉽지 않을 같습니다. 여기에 비해 PC 그것도 Windows 7 이라는 OS 기본으로 하게 되면, 넷북을 최저 사양으로 있을 입니다.

결국 이러한 차이가 xbox 기반 키넥트의 해상도인 320x240 30 프레임 이라는 한계를 지니게 되었고, 여기에 비해서 PC 보다 다양한 해상도를 지원하게 같습니다.

PC SDK 320x24 30, 640x480 30, 1280x960 10 프레임을 지원할 있습니다.

아무래도 하드웨어 전문가가 아닌 필자가 내용을 모두 설명하기에는 부족한 감이 많을 같습니다. 이런 부분은 전기, 전자를 전공하신 유능하신 분들의 포스팅을 기다려봐야 같습니다.

 

현재까지 나온 데모 소스만으로 키넥트 SDK 평가 하기에는 이른 느낌이 듭니다. 다른 공개 라이브러리와 비교해서, 부족하다는 의견 또한 없지 않지만, 아직 베타 버전이고, 근거리 인식에 있어서는 장점을 보이고 있습니다.

 

이제 베타 버전을 통해 키넥트가 PC에서 어떻게 활용될 것인지 가능성을 점쳐보고, 향후에 어떻게 있을 것인지, 지적 호기심을 가지고 기다리고 준비하는 것도 재미있을 같습니다.

[StartD2D-4] WIC 를 이용한 이미지 작업하기

DirectX 11 2011. 7. 4. 08:30 Posted by 알 수 없는 사용자

 

  

이번 시간에는 직접 이미지를 화면에 표현하는 방법에 대해서 언급합니다.

Win32 API를 이용할 때, 우리는 '비트맵(Bitmap)' 이라는

그래픽 데이터 포맷을 읽어서 화면에 그려주었습니다.

사람마다 차이는 있겠지만, 일반적으로 다음과 같은 순서를 따라서 구성했을 것입니다.

 

  1. 비트맵을 읽기 위해서 파일을 오픈한다.

  2. 파일에서 헤더를 읽어 들인다.


  3. 비트맵 헤더의 정보를 통해서 관련 메모리를 생성하고,

    파일에서 색상 데이터에 대한 정보를 읽는다.


  4. DIBSection 을 생성하고, 실제 데이터를 읽는다.
  5. 그리고 마무리 한다.

 

이 순서는 수 많은 방법 중에 하나일 뿐이지만,

기본적으로 파일을 열어서 헤더를 먼저 읽고, 관련 메모리를 생성하고,

이후에 실제 데이터를 채우게 되는 순서는 공통된 작업입니다.

Direct2D 에서도 이와 같이 작업을 해도 되지만,

이미 편의를 위해 만들어진 라이브러리를 사용해서 조금 더 확장성 있는 작업을 할 필요가 있습니다.

지금부터는 WIC를 이용한 간단한 이미지 뷰어 작업을 해보겠습니다.

  

WIC( Windows Imaging Component )

 

DirectX 가 윈도우 운영체제 전반으로 광범위하게 활용되면서,

이들과 관련한 내용들을 분리할 필요가 있었습니다.

과거까지는 DirectX 는 게임 개발자들의 전유물에 가까웠기 때문에,

다른 개발자들도 손쉬운 개념으로 접근할 수 있는 그런 분류가 필요했습니다.


결과적으로 아래와 같이 분류가 되었습니다.  

 

WIC는 모든 이미지를 쉽게 처리할 수 있도록 만들어낸 COM 기반의 프레임워크입니다.

그림에서 보듯이 WIC도 하나의 큰 영역으로서 자리 잡고 있습니다.

( 참고로 DXVA는 영상 처리를 위한 프레임워크입니다. )

 

WIC를 이용한 이미지 처리는 앞서 GDI 기반에서 작성했던 것과는 완전히 다릅니다.

WIC는 PNG, JPG, GIF 등과 같은 거의 모든 주요한 이미지 형식을 포함하고,

기본 코덱들을 지원하고 있습니다.

 

말이 참 어렵죠?

쉽게 말해서, Direct2D 기반에서 이미지 처리를 하려면 WIC를 사용하면 쉽게 할 수 있다는 것입니다.

우리는 이것을 사용하는 순서와 방법에 대해서 배우기 위해서,

윈도우 화면에 이미지를 그려주는 간단한 애플리케이션을 만들어 볼 것입니다.

 

 

기본 WIC 프로그래밍

 

애플리케이션 마법사로 새로운 프로젝트를 만들고, stdax.h 에 다음을 추가를 합니다.

 

'WindowsCodecs.lib'와 'wincodec.h' 가 바로 WIC를 사용하기 위해 추가시킨 것입니다.

눈치 빠른 분들이라면, 이름에서 약간 앞으로의 작업 방향을 예측할 수 있을 것입니다.

 

이번 프로젝트에서 사용할 전역 변수들은 아래와 같습니다.

 

 

익숙한 개념이 눈에 보이지 않으십니까?

바로 IWICImagingFactory 입니다. 네 그렇습니다~

WIC 도 바로 팩토리 형태로 생성이 됩니다.

 

추가된 변수들은 아래와 같은 절차에 의해 값이 채워집니다.

즉, 아래는 WIC의 처리 과정입니다.

 

  1. WIC 팩토리를 만든다.

  2. 파일 경로를 기반으로 해서 디코더를 만든다.

  3. 디코딩된 프레임을 가져온다.

  4. 변환기에 넣어서 Direct2D 형식으로 변환한다.

  5. Direct2D 비트맵을 생성하고, 이를 렌더링한다.

 

이제 위의 절차를 실제로 어떻게 처리하는지를 차근차근 살펴보겠습니다.

 

가장 먼저하는 초기화 작업입니다.

앞서 언급했듯이, WIC 도 팩토리 개념으로 생성됩니다.

COM 기반이기 때문에 API 인자들이 굉장히 어려워 보일 수도 있지만, 관심을 둘 부분은 아닙니다.

위와 같은 방법으로만 하면, WIC가 생성 되어진다는 개념으로만 인식하고 다음 단계로 넘어갑니다.

 

 

 

다음 단계는 디코더를 만들고, 이를 기반으로 해서 Direct2D 형식으로 데이터를 변환하는 것입니다.

이를 위해서 가장 먼저 해야 하는 일은

이미지를 읽어들이기 위한 디코더( Decoder )를 만드는 일입니다.


갑자기 등장한 생소한 용어에 조금 혼란스러울 것 같습니다.

우리가 사용하는 모든 멀티미디어 파일( 이미지, 영상, 사운드 등 )들은

굉장히 어려운 방법으로 압축이 되어있습니다.


이들에 대한 원리나 형식을 이해하는 것도 중요한 일일 수도 있지만,

이는 간단하게 본 페이지에서 설명할 수 있는 내용이 아닙니다.

물론 저도 이와 관련한 전문가는 더더욱 아닙니다.

우리는 단지 API만으로 이들에 대한 고민을 해결할 수 있습니다.

바로 그것이 WIC의 존재 이유 중 하나 일 것입니다.^^

 

즉, 우리는 이미 만들어진 API를 이용해서 손쉽게 이미지 파일을 읽어올 수 있습니다.

그런 역할을 하는 것이 바로 디코더입니다.

아래는 디코더를 가지고 실제 작업을 하는 부분입니다.

 

 

디코더는 WIC 팩토리 멤버함수로써 생성이 되어집니다.

우리가 사용했던 이 API의 원형은 다음과 같습니다.

<코드>

HRESULT CreateDecoderFromFilename(

[in] LPCWSTR wzFilename,

[in] const GUID *pguidVendor,

[in] DWORD dwDesiredAccess,

[in] WICDecodeOptions metadataOptions,

[out, retval] IWICBitmapDecoder **ppIDecoder

);

</코드>

 

이 API는 주어진 이미지 파일을 기반으로 해서 디코더를 생성해 줍니다.

첫 번째 인자로 파일명이 들어갑니다.

이 파일을 기반으로 해서 적합한 디코더를 생성해 주게 되는 것입니다.

예를 들어, PNG 파일이면 PNG에 대한 디코더가 필요하다고 인식하고,

그에 맞는 디코더를 자동적으로 생성해 주는 것입니다.

 

두 번째 인자는 선호하는 디코더 벤더(vendor)의 GUID를 입력해야 하는데, 지금은 NULL을 사용합니다.

 

세 번째 인자로는 디코더에 대한 접근 방법을 명시합니다.

읽기(read), 쓰기(write), 혹은 둘 다 가능한지를 넣어주면,

가장 최적화된 방법과 메모리 위치를 가지는 디코드를 생성해 줍니다.

위의 예제에서는 읽기용으로만 디코더를 만들었습니다.

 

네 번째 인자는 디코더의 캐시 관련 옵션입니다.

우리가 인자로 넘긴 WICDecodeMetadataCacheOnDemand는

필요한 이미지 정보만 캐시 하도록 옵션을 준 것입니다.

다음 번에 언급할 지도 모르지만, 하나의 이미지 파일에는 여러 이미지들을 포함하고 있을 수 있습니다.

예를 들면 GIF 애니메이션 이미지 같은 것들이다.

이런 경우에 유용하게 캐시하려면, 다른 옵션을 주어야 할 것입니다.

 

마지막 인자는 생성된 디코더를 저장할 디코더의 포인터입니다.

여기까지 작업하면, 우린 이제 파일을 읽은 디코더를 소유하게 되는 것입니다.

뭔가 절차 상으로 굉장히 복잡한 것처럼 느껴지죠?

 

 

다음으로 할 작업은 프레임(frame) 작업입니다.

프레임이라는 것은 실제 픽셀 데이터를 가지고 있는 비트맵입니다.

앞서 잠깐 언급했듯이, 하나의 이미지 파일은 여러 장의 이미지가 존재할 수 있습니다.

그런 경우를 대비해서 체크를 해야겠지만,

우린 여기서 단 하나의 프레임만이 존재한다고 가정할 것입니다.

디코더의 멤버 함수인 GetFrame()를 통해서 우린 가장 첫 번째 프레임을 얻을 수 있습니다.

이 프레임을 얻는다는 것은 우리가 화면에 표현할 수 있는 이미지를 얻었다는 것입니다.

 

이제 우리는 디코더를 통해서 이미지를 Direct2D에서 표현할 수 있도록

적절하게 변환을 해주어야
합니다.

CreateFormatConverter() API는 이를 위해서 컨버터를 만들어줍니다.

그리고 이 컨버터를 우리가 원하는 형태로 초기화를 시켜 줍니다.

컨버터의 멤버함수 Initialize() 는 이미지를 컨버팅 하면서

픽셀 정보를 보정해 줄 수 있는 많은 옵션을 가지고 있습니다.

이들 옵션에 대한 세부 설정을 하지 않았습니다.

그래서 위에 인자들 형태로 주면, 별다른 이미지의 수정 없이 32비트 포맷으로 남게 됩니다.

 

이제 마지막으로 실제 렌더링 가능한 형태의 메모리를 생성해야 합니다.

렌더타겟의 멤버함수인 CreateBitmapFromWicBitmap() API를 통해서 이 작업을 하게 됩니다.

여기까지 하면, 이미지를 렌더링 하기 위한 준비작업이 모두 끝난 것입니다.

 

저는 여기에 모든 옵션들을 나열하지 않습니다.

( 기본 목적인 이미지를 띄우는데 충실하고자 합니다.^^ )

 

 

생소한 API들이 눈에 많이 띄지만, 이들은 일련의 절차에 지나지 않습니다.

중요한 개념은 이미지를 읽어 들일 디코더를 만들고,

이 이미지 데이터를 Direct2D가 표현할 수 있는 픽셀 데이터로 변환하는 것입니다.

그리고 이 데이터를 렌더타겟에서 표현할 수 있는 비트맵으로 만들어서

렌더링 가능한 상태로 만듭니다.

위의 코드는 바로 이 개념들을 표현하고 있는 것입니다.

 

그러면 실제 WM_PAINT 메시지를 통해서 이들이 어떻게 화면에 그려야 하는지 살펴보겠습니다.

 

WM_PAINT 메시지에서는 렌더타겟이 존재하지 않는 경우, 렌더타겟을 생성합니다.

렌더 타겟이 존재한다면, 비트맵을 그리고 있습니다.

렌더타겟의 렌더링 작업도 BeginDraw() / EndDraw() 의 매커니즘 내부에서

특정 상태를 기반으로 작업을 수행하게 됩니다.

우리는 Clear() 라는 API를 통해서 렌더타겟의 메모리를 흰색으로 채우고 있습니다.

그리고 현재 우리가 이미지를 (0,0) 위치에 (300,300) 크기로 렌더링 합니다.

 

마법의 함수 DrawBitmap()

 

앞선 작업을 통해서 우린 Direct2D를 이용해서 이미지를 화면에 그릴 수 있었습니다.

만약 우리가 읽어 들인 이미지의 일부분만을 화면에 그리고 싶다면 어떻게 해야 할까요?

혹은 흐릿한 효과를 주고 싶다면 어떻게 해야 할까요?

굉장히 어려운 일들 같지만, 이들 기능은 DrawBitmap() 에 모두 옵션 인자로서 존재하고 있습니다.

( 무척 고마운 일이지요..^^ )

그렇기 때문에, 우리는 이 함수를 잘 사용할 수 있어야 합니다.

API의 원형은 다음과 같습니다.

 

<코드>

virtual void DrawBitmap(

[in] ID2D1Bitmap *bitmap,

[in, optional] const D2D1_RECT_F *destinationRectangle = NULL,

         FLOAT opacity = 1.0f,

D2D1_BITMAP_INTERPOLATION_MODE interpolationMode =

D2D1_BITMAP_INTERPOLATION_MODE_LINEAR

,

[in, optional] const D2D1_RECT_F *sourceRectangle = NULL

) = 0;

</코드>

 

첫 번째 인자는 우리가 렌더링 작업을 수행할 이미지입니다.

 

두 번째 인자부터는 옵션적으로 설정할 수 있다.

두 번째 인자는 렌더링 작업을 수행할 화면의 영역을 설정합니다.

NULL 로 설정한다면, 렌더타겟의 원점에 그리게 됩니다.

만약 이미지 크기보다 크게 설정된다면, 자동적으로 이미지를 확대해서 보여주게 됩니다.

 

세 번째 인자는 투명도를 설정합니다.

범위는 0.0~1.0 사이의 값으로 0.0은 투명한 상태를 나타내고 1.0은 불투명한 상태를 나타냅니다.

 

네 번째 인자는 우리가 렌더링하는 이미지가 회전을 하거나 크기가 조정되었을 때,

어떻게 부드럽게 보일 것인가에 대한 옵션을 설정하는 부분입니다.

즉, 보간( interpolation ) 옵션입니다.

 

마지막 인자는 원본 이미지에서 일정 영역을 보여주고 싶을 때 영역을 입력하는 옵션입니다.

이 때 단위는 해당 이미지 파일의 사이즈를 기준으로 영역을 설정해 주면 됩니다.

 

그러면, 간단하게 실제로 이미지의 일부 영역을 약간 투명하게 보여지는 것을 프로그램으로 구현해자면,

앞서 작성했던, 이미지 뷰어의 기능에서 DrawBitmap()만 변경해주면 됩니다.

 

<코드>

HRESULT hr = E_FAIL;

::g_ipRT->BeginDraw();

::g_ipRT->SetTransform( ::D2D1::Matrix3x2F::Identity() );

::g_ipRT->Clear( ::D2D1::ColorF( ::D2D1::ColorF::White ) );

                            

if( ::g_ipD2DBitmap != nullptr )

{

    ::D2D1_RECT_F dxArea = ::D2D1::RectF( 0.0f, 0.0f, 500.0f, 500.0f );

    ::D2D1_RECT_F dxSrc = D2D1::RectF( 0.0f, 0.0f, 250.0f, 250.0f );

    ::g_ipRT->DrawBitmap( ::g_ipD2DBitmap, dxArea, 0.3f,

D2D1_BITMAP_INTERPOLATION_MODE_LINEAR, &dxSrc );

                

}

hr = ::g_ipRT->EndDraw();                

</코드>

 

우리는 간단하게 DrawBitmap() 의 인자들만 변경해주는 것만으로 이미지의 일부 영역만을 보여주고,

투명도를 조절할 수 있음을 확인해 보았습니다.

각각의 값을 변경시키면서, 여러가지 아이디어를 구상해 보기 바랍니다. ^^


아래 소스코드를 첨부합니다..


[STL] 15. VC++ 10에 추가된 새로운 컨테이너 forward_list – 사용편

C++0x 2011. 6. 21. 09:30 Posted by 알 수 없는 사용자

STL의 컨테이너를 사용해보았다면 forward_list라고 해서 딱히 어려운 부분은 없습니다. 다만 forward_list이 단 방향 리스트라는 것과 다른 컨테이너에서는 지원하는 기능이 일부 없다는 것을 잘 숙지해야 합니다.

 

필요한 헤더 파일

forward_list는 이름과 같은 ‘forward_list’라는 헤더 파일을 포함해야 합니다.

#include <forward_list>

 

 

[예제] forward_list를 사용하여 요소 추가, 순회, 삭제하기

#include "stdafx.h"

#include <iostream>

#include <forward_list>

 

using namespace std;

 

 

int main()

{

           forward_list< int > flist;

 

 

           cout << "flist에 추가한 요소들 출력" << endl;

           // 추가하기

           auto iter = flist.before_begin();

           for( int i = 0; i < 5; ++i )

           {

                     iter = flist.insert_after( iter, i );

           }

                    

           // 순회

           for( iter = flist.begin(); iter != flist.end(); ++iter )

           {

                     cout << *iter << endl;

           }

 

           cout << endl;

           cout << "flist의 요소들 중 일부를 삭제한 후 남은 요소들 출력" << endl;

           // 순회 하면서 일부 요소 삭제

           auto prev_iter = flist.before_begin();

           iter = flist.begin();

           while( iter != flist.end() )

           {

                     if( 3 == *iter )

                     {

                                iter = flist.erase_after( prev_iter );

                                continue;

                     }

                     ++prev_iter;

                     ++iter;

           }

 

           // 순회

           for( iter = flist.begin(); iter != flist.end(); ++iter )

           {

                     cout << *iter << endl;

           }

 

           return 0;

}

 

< 결과 >


 

위 예제를 보면 아시겠지만 forward_list std::list에 비해 성능 면의 이점을 가지고 있지만 사용 측면에서는 조금 불편한 점이 좀 있습니다. 그러나 C와 비슷한 성능을 내고 싶은 경우에는 좋은 선택 기가 될 수도 있습니다.

 


참고

http://msdn.microsoft.com/ko-kr/library/ee373568.aspx