잊지 않겠습니다.

VS 2008 & .NET Framework 4.0 Beta2

.NET Framework 2010. 1. 5. 01:06
설치 이후.. 이상할 정도로 UI가 전보다 빠르다.;

Win7에 최적화가 되어있나? 라는 생각도 들고. UI쪽에 실버라이트와 DirectX 기술이 들어가있다는 말은 들었는데. 그것 때문인가 라는 생각도 들고.;

무엇보다 설치 이후에 충격적인 내용은..;;

다음과 같은 코드 실행의 결과가 아래와 같이 나왔다는 점이다.;


class Program

{

    static void Main(string[] args)

    {

        string runtimeEnvironment = RuntimeEnvironment.GetRuntimeDirectory();

        Console.WriteLine(runtimeEnvironment);

    }

}


CLR의 버젼이 완전히 바뀌었다.;;; 3.x대를 완전히 넘어가서 바로 4.0.21 대로 진입.
.NET Framework의 새로운 장이 열렸다고 해도 과언이 아닌 변화가 이루어졌다;;

Powershell과의 통합은 어찌된걸까?; 다른 .NET과의 통합은? ;;;
저작자표시 비영리 변경금지
Posted by Y2K
,

Singletone Pattern

.NET Framework 2009. 3. 31. 03:04
예전에 Design Pattern에서 언급되던 Singletone pattern에서 다른 언어들과 .NET에서 구현상의 큰 차이점이 발견되어서 적어두기. 

1. 다른 언어들.
    public sealed class SingletonOld
    {
        private static Object lockObj = new Object();
        private static SingletonOld singleObject;

        private SingletonOld()
        {
        }

        public static SingletonOld Value
        {
            get 
            {
                if(singleObject == null)
                {
                    lock(lockObj)
                    {
                        singleObject = new SingletonOld();
                    }
                }
                return singleObject;
            }
        }
    }


2. .NET
    public sealed class SIngletonNew
    {
        private SIngletonNew()
        {

        }
        private static SIngletonNew singleObject = new SIngletonNew();

        public static SIngletonNew Value
        {
            get { return singleObject; }
        }
    }

가장 큰 차이는 변수의 선언과 동시에 값의 할당. CLR에서는 변수의 선언과 동시에 값을 할당시켜주는 경우에 생성자의 inline code로 만들어서 넣어주기 때문에 가장 빠르고 static의 경우에는 Single Thread의 접근을 완벽하게 보장해준다. 그러나 예전의 방법대로 구현하게 되면 Thread의 동기화 lock에 의해서 효율성을 떨어뜨리는 구현이 된다. (불행하게도 Design Pattern 책에는 대부분 첫번째 방법으로 되어있다.;; 두번째 방법 비슷하게 private 의 생성자 구현을 만들어두고 이렇게 만들면 안되고 첫번째 방법으로 Thread의 lock을 유지시켜야지 된다는 친절한 설명이 있는 책도 있다.;; )




저작자표시 비영리 변경금지
Posted by Y2K
,

JIT compiler에서 생성되는 code와 native code간의 성능 차이.

.NET Framework 2009. 3. 20. 01:12
CLR via C# 책에서 일반적인 통념을 부정하는 견해가 있어서 여기에서 간단히 소개. 

1. 컴파일 시에 JIT 컴파일러는 실행환경의 CPU type을 알 수 있기 때문에, 최적화된 지시어를 이용해서 Native code를 생성함으로써 성능의 향상이 가능

2. JIT 컴파일러는 특정 상황의 테스트값 혹은 논리 연산의 결과를 실행 전에 알아내서 좀 더 빠른 Native code의 생성이 가능하다. 

3. CLR은 appliaction의 실행 패턴을 Profile함으로써, 실행중인 IL code를 native code로 다시 컴파일 할 수 있다.

이상의 이유로.. managed code가 unmanaged code보다 성능이 우수하다.


  약간은 생뚱맞기도 하고, 절대로 공감할 수 없다는 사람들이 엄청나게 덤벼들 것이 뻔한 상황이지만.. 개인적으로 전에 C++로 작업하던 환경과 지금 C#으로 작업하는 환경에서 겪어본 상황을 생각하면 은근히 이 말이 맞다는 생각이 든다. 일단... 첫 실행 시간. JIT에 의해서 native code가 생성되는 그때는 절대적으로 unmanaged code가 성능이 더 우수하다. 그렇지만, JIT에 의해서 native code가 생성된 이후라면.. 이미 사용된 assembly의 내용을 재이용하는 상황에서는.. 속도가 비슷하거나, 내가 짠 C++코드보다 빨랐었던 경험이 분명히 있었다. -_-;; 
(내 코드가 문제였을거야.. 라는 생각도 하지만.;)

  .NET으로 만든 코드에 대한 자신감을 좀 더 갖고 이야기를 해도 괜찮을 것 같다. 잘 생각해보면.. 그렇게 성능이 중요하면 assembly로 짜라. 라는 말이 가장 막강하긴 하지만. ^^
저작자표시 비영리 변경금지
Posted by Y2K
,

티스토리툴바