'dev.log'에 해당되는 글 45건

  1. 2009.04.09 정보은닉을 위한 라이브러리 헤더
  2. 2009.03.03 goto hell 7
  3. 2009.02.23 A Brief History of C++ 2
  4. 2009.02.17 행렬 구현
  5. 2009.02.11 크리티컬 섹션 문제
  6. 2009.02.07 단위 변환
  7. 2009.02.03 벡터는 벡터일 뿐
  8. 2009.02.01 충돌처리
  9. 2009.01.28 통계자료 수집
  10. 2009.01.27 개발 계획
dev.log2009. 4. 9. 12:59
라이브러리, 특히 C++ 라이브러리 배포 시에 인터페이스'만' 배포하는 것은 상당히 귀찮은 일이다. 나같은 경우는 클래스에 nested type을 무척 많이 쓰고, 일부는 구현에만 사용하는 타입이기 때문에 nested type이 외부로 나가면 내부 구현을 까발리는 것과 다를 바가 없다. 물론 private 권한으로 숨겨놓을 수도 있지만, 뻔히 헤더 소스에 보이는 걸 숨겨놨다고 하기엔 옹색한 것도 사실이다. 그래서 만들고 있는 파일 스트림 라이브러리는 다음과 같이 하기로 했다.

배포용 헤더. 바이너리 라이브러리만 배포할 때는 요놈만 쓴다.
class stream
{
public:
    static stream* create( const string& strm_path );
    static stream* create();
    virtual ~stream();

    virtual int open( const string& strm_path ) =0;
    virtual int close() = 0;
    virtual int read( void* buffer, size_t size ) = 0;
    virtual int write( void* buffer, size_t size ) = 0;
    virtual size_t tell() = 0;
    virtual int seek( size_t offset ) = 0;

protected:
    stream() {}
    stream( const stream& ) {}
};
기본 생성자와 기본복사생성자를 protected로 막아놓고 Create로 쓰는 이유는, 어디까지나 인터페이스이기 때문. 구현 레벨에서 다형성 타입으로 생성하도록 한다.


구현용 헤더
class stream_impl
{
    virtual int open( const string& strm_path ) =0;
    virtual int close() = 0;
    virtual int read( void* buffer, size_t size ) = 0;
    virtual int write( void* buffer, size_t size ) = 0;
    virtual size_t tell() = 0;
    virtual int seek( size_t offset ) = 0;
};

class stream_file : public stream_impl
{
public:
    //...
protected:
    fstream _file;
};

class archive;
class archive_item;
class stream_pack : public stream_impl
{
public:
    //...
protected:
    archive* _pack;
    archive_item* _item;
};

class stream_class : public stream
{
public:
    stream_class();
    stream_class( stream_impl* impl );
    //...
protected:
    stream_impl* _impl;
};

class archive
{
    int open_pack( const string& path );
    int close_pack();

    archive_item* open( const string& path );
    int close( archive_item* item );
    int read( .. );
    int write( .. );
    int seek( .. );
    int tell( .. );
};
stream_class와 stream_impl을 분리한 이유는, 동일한 stream 객체를 서로 다른 종류의 스트림으로 다시 열 수 있도록 하기 위해서.

구현용 소스는 대략 다음과 같은 모양새가 된다.
stream* stream::create( const string& strm_path )
{
    stream_class* strm = new stream_class;
    strm->open( strm_path );
    return strm;
}

int stream::open( const string& strm_path )
{
    if ( _impl )
    {
        delete _impl;
        _impl = 0;
    }

    if ( search_package( strm_path ) )
        _impl = new stream_pack;
    else if ( search_file( strm_path ) )
        _impl = new stream_file;
    else
        return 0;

    return _impl->open( strm_path );
}

약간 귀찮긴 하지만 '싫어하는 사람'에게 라이브러리를 배포해야 할 때에는 유용할지도.. 생각해보면 위와 같은 모양새를 가리키는 디자인 패턴의 이름도 있을 거 같긴 한데, 찾아보기 귀찮다. ( ..)

Posted by uhm
dev.log2009. 3. 3. 18:17
회사에는 goto를 좋아하는 사람이 한명 있다. goto를 그냥 남발하는 게 아니다. 진심으로 goto를 좋아해서 쓴다 -_-a 이런 종류의 인간이 제일 난감한데, 이런 식이다. '남들이 다 쓰지 말라고 하는 거지만 난 잘 쓸 자신이 있다'는 식이다. 남들과 달리 잘 쓸 수 있으므로 쓰겠다는 입장. 그래서 모든 로직의 핵심을 goto로 구현해 놓고 자랑스러워한다. '이 로직은 goto로 완벽하게 짜봤지요' ㄷㄷㄷ

bool func()
{
    bool succ = false;
    mutex.lock();
    if ( do_something() == false )
       goto exit;

    if ( do_another() == false )
       goto exit;

    if ( do_blabla() == false )
       goto exit;

    succ = true;
exit:
    mutex.unlock();
    return succ;
}


사실 난 되도록이면 코드는 자기가 짜고 싶은 대로 짜면 된다;는 입장이라, 이 인간이 goto를 쓰건 말건 걍 놔 뒀었다. 그리고 위와 같은 코드는 일반적으로 용인되는 goto의 쓰임과 크게 어긋나지도 않기 때문에. 문제는 이런 부분.

void* get()
{
retry:
    mutex.lock();  

    if ( !available )
    {
        if ( try_alloc() == false )
            goto must_alloc
    }

    void* result = do_postprocess();
    mutex.unlock();
    goto done;   

must_alloc:
    mutex.unlock();

    if ( alloc()  )
        goto retry;
    return 0;

done:
    return result;
}

대충 이런식. 이 코드를 내가 디버깅해야 할 비상사태가 오면서 문제가 불거지기 전까지는 문제의 심각성을 몰랐다. -_- 뒤로갔다 앞으로 갔다 하는 goto의 흐름을 쫓다가 디버깅시간의 2/3가 흘러간 걸 보고서 고쳐놔야 겠다는 생각이 들었다.

사실 앞의 코드는 너무 쉽다. 그냥 true/false를 바로 리턴하도록 바꾸고 뮤텍스는 로컬 객체로 래핑해서 생성자/소멸자에서 lock/unlock을 부르게 하면 되니까. 뒤에 꺼는 좀 까다롭다. 분명히 루프이긴 한데, 루프의 종료조건이 뭔지 알기가 매우 힘들다 -_- 종료조건이라 하더라도 거기에서도 분기가 두갈래다. 깔끔한 코드를 만들기가 어렵다. 나름 도전의식이 생기는 코드랄까.

Posted by uhm
dev.log2009. 2. 23. 00:09
C++ 0x 표준안이 올해 확정된다는 소식을 들었다. Design & Evolution of C++에서 봤던 변천 과정에 한가지가 더해진다는 느낌. D&EC++은.. 읽다가 말기도 했고, 오래전이라 기억이 가물가물하기도 해서 한번 뒤져봤다.

1979 : C with Classes
Bjarne Stroustrup께서(이하 B.S.) 시뮬라에서 힌트를 얻어 C의 개량판을 구상하기 시작하던 시절이다. 시뮬라는 본격 객체 지향 언어였지만, CwC에는 그냥 ADT(abstract data type) 개념만을 집어넣고 C에서는 거의 하지 않았던 타입 체크를 강화하는 쪽으로 구현. 이때는 C 컴파일 단계 전에 파싱하여 C소스코드를 생성하는 전처리기로 구현했었다. D&EC++에 따르면, 당시의 CwC는 다음 기능을 갖고 있었다.

  • classes
  • inheritance
  • access control (private/public)
  • cons/des (new/delete)
  • monitor (call/return)
  • friend classes
  • type check (undeclared function, void args, conversion)
  • inline func
  • default args
  • assignment overloading

대부분은 아직까지 유지되고 있지만 변경되거나, 없어진 기능들도 있다. 이를테면, call/return 멤버 메소드를 이용한 - call에서 락을 걸고, return에서 락을 해제하는, 일종의 콜백개념 - 동기화 구현은 B.S.자신을 제외한 그 누구도 쓰지 않았기에 없애는 쪽으로 결정되었다고 한다 -_-a 그리고 당시에는 생성자와 소멸자 메소드가 new/delete 라는 이름을 갖고 있었다. 그리고 연산자 오버로딩은 = 연산자만 지원.

1982 : C++ (Cfront)
C++이란 이름을 처음 갖고 발표된 C++ release 1.0의 시기. 하지만 여전히 C의 전처리기로 구현되었으며, 그 전처리기의 이름은 Cfront. Cfront의 기능은 위의 것에 더하여 다음이 추가.

  • virtual functions
  • function/operator overloading
  • reference
  • const
  • new operator
  • type check ( func args, ... list)
  • line comment
  • scope resolution

이때는 가상함수를 통한 동적 다형성을 지원하면서 객체지향 언어의 면모를 갖추게 된다. 또한 타입 체크가 점점 강화되는 쪽으로 가는데, 그것은 초기 C++의 설계 정책중 하나가 C와의 하위호환성 보장이었기 때문에, C코드를 컴파일할 수 없는 언어 스펙은 보급이 곤란하기 때문이었다고나. 충분한 수의 C++유저가 확보되지 않은 상태에서는 점진성이 타당한 선택이었을 듯. 그외에는 사소한 차이점들. 지금과 같은 개념의 new연산자가 도입되면서, 기존의 new/delete대신 지금의 형태를 가진 생성자/소멸자가 도입되었다. 또한 이때의 오버로딩에는 overload라는 키워드가 필요했다. 1984년에는 The C++ Programming Language가 출간되기도.

1985 : C++ R2.0
사람들의 관심이 서서히 증가하면서 달라진 기능의 C++ release 2.0을 발표. 이 시기는 B.S.가 만든 Cfront 프리프로세서를 대체할 (진짜) 컴파일러가 여기저기서 만들어지기 시작한 때이다.

  • multiple inheritance
  • type-safe linkage
  • overloading resolution
  • init/assign definition in member-wise basis
  • dynamic initialization
  • new overloading
  • abstract class
  • static member func
  • const member func
  • protected members
  • member to pointer (->) overloading
  • pointers to members
  • libraries

B.S의 말에 따르면 R2.0으로의 변화는 기능의 추가라기보다는 제약의 해제라고 한다. 단1개의 베이스클래스에서 여러개의 베이스클래스를 허용한다든가, 그전까지 오버로딩 불가능했던 연산자들에 대한 허용이라거나; 하는 것들. 또한 지금의 형태를 가진 기본적 라이브러리가 구현되기 시작한 시기이기도 하다. 물론, 이때는 템플릿이 없었으므로 주로 stream IO나 문자열 라이브러리들부터 구현되었다.
   
1988 : C++ARM
Annotated Reference Manual이 발표되면서 지금의 C++의 모습이 거의 갖추어진다. 다음의 변화가 추가되었다.

  • template
  • exception
  • nested class
  • pre/post ++ overloading
  • local statics
  • volatile
  • STL

이 시기의 C++이 가장 많은 사람들에게 알려진 C++의 형태이다. <iostream.h> 헤더를 사용하던 형태가 바로 이때의 C++. 표준화가 이루어지기 직전이다. 이때의 C++ 문법들은 거의 지금 그대로 남아있다. 가장 중요한 변화는 템플릿의 도입인데, 이로 인해서 C++이 지원하는 프로그래밍 패러다임이 하나 더 늘어나게 되었다. 템플릿과 함께 STL도 도입.
   
1998 : C++98
표준화가 이루어진 C++의 스펙이다. ISO/IEC 14882로 검색해 보면 표준에 대한 설명을 찾아 볼 수 있다. 주요 변경사항은 다음과 같다.

  • runtime type information
  • namespace
  • casting operators
  • bool type
  • explicit template instantiation
  • explicit template args in template function calls

표준화 작업이 거의 10년이나 지속됐기에, ARM형태의 C++이 널리 퍼진 다음에 발표된 표준은 확산이 매우 더뎠던 걸로 기억한다. MSVC도 최근에 와서야 C++98 스펙을 거의 다 지원하게 되었으니 말 다한 셈. 이때부터는 표준라이브러리는 모두 std네임스페이스에 속하도록 정해졌으며 기존 ARM형태의 라이브러리와 혼동을 피하기 위해 표준헤더도 .h확장자를 떼는 쪽으로 결정.

   
2003: C++03
1998년 표준 문서에서 발견된 모순이나 오류들을 수정한 문서이다. 그다지 크게 달라지지는 않았으나 스펙이 명료한 표현으로 대체되었다. 따라서 현재 C++ 표준은 ISO/IEC 14882:2003 이다. 주목할만한 점이라면 vector의 메모리 연속성에 대한 보장이 표준에 의해 명시되었다는 점 정도.

   
2005 : C++TR1
C++ 표준 라이브러리의 확장을 위한 첫번째 technical report. C++유저들 사이에 널리 쓰이거나 요구되는 라이브러리를 정리한 공식 표준으로 ISO/IEC TR19768로 검색하면 관련 내용이 나온다.

  • tuple
  • array containner
  • unordered_map
  • regular expression
  • reference wrapper
  • polymorph wrapper
  • smart pointer
  • func binder
  • return type wrapper
  • random number lib

면면을 살펴보면 기존의 Boost 라이브러리에 있던 개념들이 다수 포함되었다. Boost 자체가 C++표준화 위원회의 임원들이 다수 포진하여 만든 라이브러리이니 당연한 결과일지도 -_-a 전체적으로는 요즘 기조에 맞게 템플릿의 활용도를 높이는 쪽으로 가고 있다.


2009 : C++0x
ISO/IEC14882:2003을 대체할 차기 표준안. 올해 확정되는 바로 그 C++ 스펙이다. 엄청나게 많은 점이 달라진다.

  • template >> priority
  • const expression
  • sizeof member without object
  • peer constructor
  • unrestricted friend
  • extern template instantiation
  • r-value reference
  • long long int
  • null type
  • enum class
  • attributes
  • explicit conversion
  • unrestricted union
  • static_assert
  • control of implicit member
  • initializer constructor
  • inheriting constructor
  • return type abduction
  • template typedef
  • string literals (encoding, raw)
  • user-defined literals
  • thread_local

사실 여기까지는 사소한 변화이다. C++ 유저들의 스타일을 근본적으로 바꿀 변화는 따로 있다.

  • type inference
  • vari arg template
  • concept
  • ranged for
  • lambda func

각 항목의 변화가 덩치가 너무 크므로 여기선 생략. 여튼 이로 인해 표준 라이브러리에 다음 구성요소가 추가된다.

  • tuple
  • range
  • unordered_map
  • regular expression
  • smart pointer
  • random
  • reference wrapper
  • polymorph wrapper
  • general function binder
  • threading (thread, mutex, condition, atomics)
  • type_traits
  • return type wrapper

라이브러리 구성요소는 TR1의 스펙이 거의 다 포함되는 쪽이며, 오히려 컨셉트나 가변 템플릿 매개변수 같은 언어 자체의 변경사항 덕분에 더 명료해진 편이라는 인상.

이런저런 것들이 바뀌었지만 대체적으로 기존 표준에 적합한 코드는 거의 다 제대로 동작한다. 오히려 더 간편한 표현을 가능하게 하는 요소가 생겼으므로 (람다나, 초기화목록 생성자, 범위기반 for 같은) 더 유연한 언어가 되었다고 봐야 맞을 듯.
하지만, 안그래도 '메저키스트의 언어'라는 평을 듣는 C++에 이런 것들을 추가하면 메저키스트 정도로는 끝나지 않을 것 같기도 하다. 뭐, 사용자도 사용자지만, C++98이 제대로 구현되는데 거의 10년이나 걸렸음을 감안하면, C++0x를 제대로 구현한 컴파일러는 2019년쯤에나 나올거 같다.

Posted by uhm
dev.log2009. 2. 17. 00:00
행렬을 구현하는 데에 있어서 가장 어려운 것은, 바로 메모리상의 배열 우선순위(major ordering)를 정하는 것이다. 단위 배열로 행벡터를 쓸 것인가 열벡터를 쓸 것인가를 결정하는 것인데, 행벡터는 행렬에 있어서 같은 행번호를 가진 원소가 서로 인접하도록 메모리 상에 배치하는 것이고, 열벡터는 같은 열 번호를 가진 원소가 서로 인접하도록 메모리 상에 배치하는 것. 어차피 둘 중의 하나 밖에 선택할 수 없기 때문에 심플한 문제이기는 한데, 좀 미묘한 문제가 걸려 있다.

우선, 행우선(row major) 배치는, 다음을 보자.


이와 같은 행렬이 행 우선 배열에서는 메모리 상에 선형으로 다음과 같이 배치된다.

 a00 a01 a02 a03 a10 a11 a12 a13 a20 a21 a22 a23 a30 a31 a32 a33

이는 C/C++의 2차원 배열 선언과 동일한 배치이다.

float a[4][4]

위와같은 선언은 메모리를 다음과 같이 배치한다.

a[0][0] a[0][1] a[0][2] a[0][3] a[1][0] a[1][1] a[1][2] a[1][3] a[2][0] a[2][1] a[2][2] a[2][3]
... a[3][0] a[3][1] a[3][2] a[3][3]

따라서, 배열의 첨자가 그냥 순서대로 [행번호][열번호]가 된다는 편리함이 있다. 행렬의 이름이 '행', '열' 순서이므로 이름과 잘 일치한다. 또한 C/C++의 기본 배열과 개념상 일치해 보인다는 장점이 있고, Direct3D에서 사용하는 방식이므로 별다른 변환 없이 Direct3D에서 사용이 가능하다. 유혹적이다.

반면, 열우선(column major) 배치는 행렬을 메모리에 배열하는 방법이 반대다.

 a00 a10 a20 a30 a01 a11 a21 a31 a02 a12 a22 a32 a03 a13 a23 a33

이를 2차원 배열로 표현한다면 [열번호][행번호]의 순서로 첨자를 부여해야 한다는 점이 C/C++의 표준과 불일치한다는 인상을 준다. 하지만 어차피 가로/세로의 선호는 사람에 따라 달라지는 것이므로 열이 앞이냐 행이 앞이냐 하는 문제는 표준에 정의되어 있지 않은 문제이다. 메모리를 가로 방향으로 나열해서 그렇지, 다음과 같이 나열하면 자연스러워 보인다.

 a00
 a10
 a20
 a30
 a01
 a11
 a21
 a31
 a02
 a12
 a22
 a32
 a03
 a13
 a23
 a33

이는 전적으로 메모리가 위아래로 뻗어있느냐 양옆으로 뻗어있느냐로 보는 것의 차이인데, 사실 어느 쪽을 택해도 무방하다. 물론 행렬을 표현한 2차원 배열에서 첨자의 순서가 '행','열' 순서가 아닌 점은 약간 불편할 것 같긴 하다. 하지만 흔히 쓰는 수학적인 (벡터를 세로로 적고 행렬의 뒤에 곱하는) 표현과 일치한다는 장점이 있고, OpenGL에서 사용하는 오더링이므로 OpenGL에서 별다른 변환 없이 사용이 가능하다.

ice 프로젝트의 요구조건중 하나가 OpenGL과 Direct3D의 동시 지원이었기 때문에, 가능한 방법은 3가지다
1. 행 우선 배치로 구현하고, OpenGL에서는 일일이 transpose하여 로드한다.
2. 열 우선 배치로 구현하고, Direct3D에서는 일일이 transpose하여 로드한다.
3. 둘 다 구현한다.
사실, 둘 다 구현하는게 바람직하긴 한데, 문제는 그렇게 할 경우에 클래스가 2개 생기므로 이름 공간이 더럽혀지는 결과가 초래되는 점이 아름답지 못하다. row_matrix와 col_matrix가 공존하는 구조를 용납할 수는 없는 법.

그래서 전에 벡터 클래스를 만들 때 SSE 스페셜라이제이션을 템플릿 매개변수로 컨트롤했던 것을 약간 이용하여, 역시 템플릿 매개변수로 major ordering을 결정하는 방법을 취하기로 했다.
enum SPECIALIZE_POLICY
{
    SPECIALIZE_DEFAULT,
    SPECIALIZE_SSE,
};

enum MAJOR_ORDER
{
    ROW_MAJOR,
    COLUMN_MAJOR,
};

// OpenGL용 열우선 배열을 기본으로 구현
template <class scalar_t, MAJOR_ORDER order = COLUMN_MAJOR, SPECIALIZE_POLICY policy = SPECIALIZE_DEFAULT >
struct matrix4t
{
    enum { MAJOR_VECTOR = order };
    typedef scalar_t                    scalar_type;
    typedef vector4t<scalar_t, policy>  vector_type;
    typedef vector3t<scalar_t, policy>  coord_type;
    union
    {
        vector_type v[4];
        scalar_type s[16];
    } m;
public:
    matrix4t() {}
    matrix4t(   scalar_type _11, scalar_type _12, scalar_type _13, scalar_type _14,
                scalar_type _21, scalar_type _22, scalar_type _23, scalar_type _24,
                scalar_type _31, scalar_type _32, scalar_type _33, scalar_type _34,
                scalar_type _41, scalar_type _42, scalar_type _43, scalar_type _44 )
                :m.v[0](_11,_21,_31,_41),
                 m.v[1](_12,_22,_32,_42),
                 m.v[2](_13,_23,_33,_43),
                 m.v[3](_14,_24,_34,_44)
    {
    }
    template <class scalar>
    explicit matrix4t( const scalar* a )
        :m.v[0](a[0], a[4], a[8], a[12] ),
         m.v[1](a[1], a[5], a[9], a[13] ),
         m.v[2](a[2], a[6], a[10],a[14]),
         m.v[3](a[3], a[7], a[11],a[15])
    {
    }
};

// Direct3D용 행 우선 배열을 위한 부분 스페셜라이제이션
template < class scalar_t, SPECIALIZE_POLICY policy >
struct matrix4t< scalar_t, ROW_MAJOR, policy >
{
    enum { MAJOR_VECTOR = ROW_MAJOR };
    typedef scalar_t                    scalar_type;
    typedef vector4t<scalar_t, policy>  vector_type;
    typedef vector3t<scalar_t, policy>  coord_type;
    union
    {
        vector_type v[4];
        scalar_type s[16];
    } m;

   
    static const matrix4t zero;
    static const matrix4t identity;
public:
    matrix4t() {}

    matrix4t(   scalar_type _11, scalar_type _12, scalar_type _13, scalar_type _14,
                scalar_type _21, scalar_type _22, scalar_type _23, scalar_type _24,
                scalar_type _31, scalar_type _32, scalar_type _33, scalar_type _34,
                scalar_type _41, scalar_type _42, scalar_type _43, scalar_type _44 )
                :m.v[0](_11,_12,_13,_14),
                 m.v[1](_21,_22,_23,_24),
                 m.v[2](_31,_32,_33,_34),
                 m.v[3](_41,_42,_43,_44)
    {
    }

    template <class scalar>
    explicit matrix4t( const scalar* a )
        :m.v[0](a[0], a[1], a[2], a[3] ),
         m.v[1](a[4], a[5], a[6], a[7] ),
         m.v[2](a[8], a[9], a[10],a[11]),
         m.v[3](a[12],a[13],a[14],a[15])
    {
    }
};

// SSE 템플릿 매개변수는 명시적으로 스페셜라이제이션할 경우에만 허용하도록 막아둠
template< class scalar_t, MAJOR_ORDER order >
struct matrix4t< scalar_t, order, SPECIALIZE_SSE >
{
    scalar_t error[0]; // SSE spcecialization is not allowed unless explicit
};

쓸 때는 어떤 오더링을 쓸 것인지와 SSE 스페셜라이제이션을 쓸 것인지를 명시하면 된다.

matrix4t<float, COLUMN_MAJOR, SPECIALIZE_DEFAULT >

물론, 위와 같이 쓰는 것은 불편하므로, OpenGL 모듈에서는 다음과 같이 타입으로 선언하는 것이 편리.

[render_ogl.h]
typedef matrix4t<float, COLUMN_MAJOR, SPECIALIZE_DEFAULT > matrix4;

물론, Direct3D모듈에서도 비슷하게 타입으로 선언할 수 있다.

[render_d3d.h]
typedef matrix4t<float, ROW_MAJOR, SPECIALIZE_DEFAULT > matrix4;

구현은 두개를 다 해야 하니 빡세도, 쓸때는 골라쓰는 재미가 있을듯; ice 프로젝트의 철학은 '클라이언트 측에서 엔진의 구성요소를 고를 수 있게 한다'는 것이므로.

Posted by uhm
dev.log2009. 2. 11. 01:02
회사에서 하는 금요 세미나. 저번주에는 K군이 크리티컬 섹션에 대해 발표했었다. K군이 발표에 삽질을 좀 했지만, 크리티컬 섹션 문제는 parallelism에서 매우 중요한 개념이므로 정리하고 넘어가자.

크리티컬 섹션이란, 두 개 이상의 쓰레드(혹은 프로세스)가 있을 때, 같은 공유자원에 접근하고자 시도하는 코드 구간을 말한다. 크리티컬 섹션이 왜 치명적인가 하면, 크리티컬 섹션이 아닌 구간에서는 패러럴리즘에 의해 잘못된 결과가 나올 리가 없기 떄문이다. 논리적으로 타당함에도 불구하고 패러럴리즘에 의해 잘못된 결과가 나올 수 있는 부분은 공유자원을 두 개 이상의 쓰레드에서 동시에 접근하려고 시도하는 곳 외에는 없다. 그래서, 다른 쓰레드와의 공유 자원에 접근하려고 하는 부분을 '치명적 구간'이라고 하는 것이다. 일부 번역서에서는 '임계영역'이라고 하기도 하는데, '제대로 관리하지 않으면 오류가 일어나는 부분'이라는 의미가 잘 살아나지 않는 것 같다. 개인적으로는 '치명적 구간'이라고 하기를 좋아하지만, 이래저래 (잘못된) 번역에 익숙해진 한국 프로그래머가 많으므로 난 그냥 '크리티컬 섹션'이라고 한다.

크리티컬 섹션을 제대로 처리해주지 않으면 잘못된 결과가 나오는 것은 전형적으로 다음과 같은 두 쓰레드를 생각하면 된다.

thread a :
int i=0;
void thread_a()
{
    i++;
}

thread b:
extern int i;
void thread_b()
{
    i--;
}

쓰레드 a와 b가 동시에 시작했다고 치면, 두 쓰레드가 종료했을 때 i의 값은 -1, 0, 1의 세 값중 어느 값이라도 가질 수 있게 된다. 이는 C++의 단항 증감연산자가 기계어로는 로드/산술연산/저장의 3가지 단계로 나뉘기 때문이다. 단순하게 생각하자면 A쓰레드의 로드/연산/저장이 순서대로 실행될 때 사이사이에 B쓰레드의 로드/연산/저장이 끼어든다고 보면 된다. 가능한 경우의 수는 많지만 대표적인 결과가 나오는 경우만 보면 다음과 같다.

A로드 > A연산 > A저장 > B로드 > B연산 > B저장 ==>  0
A로드 > B로드 > A연산 > A저장 > B연산 > B저장 ==> -1
A로드 > B로드 > A연산 > B연산 > B저장 > A저장 ==>  1

따라서 크리티컬 섹션 문제를 해결하는 것은 특정 쓰레드의 동작 사이에 다른 쓰레드가 끼어들지 못하도록 어떻게 하느냐 하는 것으로 귀결된다. 대략적으로 크리티컬 섹션 문제의 해결책은 다음과 같이 사용하게 된다.

wait( S )      // wait for entering critical section
..............    // critical section
signal( S )   // allow other threads to enter critical section

OS책에서는 크리티컬 섹션 문제의 해결책은 다음 조건을 만족해야 한다고 나온다. 중요하다.
  • Mutual Exclusion (상호 배제)
  • Progress (진행)
  • Bounded Waiting (유한 대기)
상호 배제는, 크리티컬 섹션 문제의 본질인, 한 쓰레드가 자원 R에 대한 크리티컬 섹션을 수행중일 때에는, 다른 쓰레드가 같은 자원 R에 대한 크리티컬 섹션에 들어가서는 안된다는 뜻이다. 진행 조건은, R에 대한 크리티컬 섹션을 수행중인 쓰레드가 하나도 없을 때에는, 어떤 쓰레드가 R에 대한 크리티컬 섹션에 들어가려고 하면 즉시 진행이 되어야 한다는 조건이다. 유한 대기는 말 그대로, 어떤 쓰레드가 R의 크리티컬 섹션을 수행하려고 할 때에는 다른 쓰레드의 R 크리티컬 섹션 진입이 유한한 횟수만큼만 이루어져야 한다는 조건. 당연한 소리같아보이지만, OS책에 나오는 크리티컬 섹션 문제의 솔루션들은 위 3가지 조건을 만족하게 만들기 까지의 발전과정이다. 언뜻 금방 생각할 수 있는 해결책들은 위 3가지 조건을 모두 만족하기가 쉽지 않다.

크리티컬 섹션 문제 해결에 가장 중요한 개념은 wait와 signal에 atomic operation이 도입되었다는 점이다.atomic operation을 뭐라 번역해야 할지는 모르겠지만, (원자적 연산;같은 구린 번역은 꺼져라!) atom의 원래의미인 '쪼갤 수 없는' 연산이란 뜻이다. (atom을 물질계에 적용한 용어인 '원자'가 어울리는 번역이 아닌 이유) 위에서C++의 단항 증감 연산자가 로드/연산/저장의 3단계로 나뉘어서 배열될 수 있는 데 비해, 아토믹 연산은 항상 단체로몰려다니고, 쪼개져서 배열될 수 없는 연산을 가리키는 개념이다. 현대적인 CPU는 모두 다 CPU의 기본 명령어중에 아토믹 연산이 명시되어 나오므로, OS는 크리티컬 섹션 문제의 해결책에 CPU의 아토믹 명령을 쓸 수 있다. 하드웨어의 도움으로 좀 더 우아한 해결책이 나올 수 있는 것은 자명한 일.

대표적인 해결책은 위대한 컴퓨터 과학자인 Dijkstra가 제안한 세마포다. 세마포의 기본적인 아이디어는 공유자원에 동시에 접근할 수 있는 쓰레드의 갯수를 미리 정해두고 지정된 수의 쓰레드만이 크리티컬 섹션에 진입할 수 있도록 한다;는 것이다. 2개 이상의 쓰레드가 동시에 같은 자원을 공유하는 크리티컬 섹션에 들어갈 수 있으면 counting semaphore, 오직 1개만이 크리티컬 섹션에 진입할 수 있으면 binary semaphore라고 한다. 사실 counting semaphore는 binary semaphore를 이용해서 구현할 수 있으므로 binary semaphore가 더 중요하다.
세마포를 이용한 크리티컬 섹션 문제의 해결책은 크게 두가지 구현방법이 있을 수 있다. 한 가지는 busy waiting, 혹은 spinlock이라고 부르는, 쓰레드가 계속 루프를 돌면서 크리티컬 섹션에 진입하기를 기다리는 방법이고, 다른 한 가지는 쓰레드 자체를 대기 상태로 바꿔버리고 세마포의 대기 큐에 들어가게 만드는 것이다. 각기 일장 일단이 있는데, 스핀락 구현은 크리티컬 섹션 진입에 컨텍스트 스위칭에 들어가는 오버헤드가 없다는 점은 좋지만 싱글 프로세서 시스템에서는 쓸 수 없다는 단점이 있다. (한 쓰레드가 CPU에서 계속 루프를 돌고 있는데 다른 쓰레드가 CPU에 올라갈 수 있을 리가 없다) 반면, 쓰레드를 대기 상태로 바꾸는 해결책은 싱글 프로세서 시스템에서도 별다른 문제 없이 쓸 수 있지만, 컨텍스트 스위칭 비용이 들어가게 된다는 점이 좋지 못하다.
결국, 크리티컬 섹션 진입 빈도에 따라 적절한 방법을 선택하는 것이 중요하다는 말씀.

Posted by uhm
dev.log2009. 2. 7. 18:33
일상적으로 통용되는 단위가 두가지 이상이라면 매우 헷갈린다. 미국은 미터법(metric system)과 영국단위(imperial system)의 차이 때문에 우주선[각주:1]을 하나 날려먹은 적도 있다. 그만큼은 심각한 것은 아니지만 회사에서 K군이 카메라 FOV를 조정할 때 라디안(radian)과 도(degree)의 차이 때문에 무척 헷갈려 하는 걸 본 적도 있다.

라디안은 우아하기 때문에 수학자나 공학자, 물리학자들이 좋아하고, 도는 역사가 오래기 때문에 세상 다른 모든 사람들이 선호하는 각도의 단위이다. 하지만 세상 모든 사람들이 우아하지 못한 단위를 사용한다고 해서 우리네 프로그래머까지 그런 단위를 써야만 한다는 것은 어불성설이라는 굳은 믿음을 갖고, 심심하던 차에 각도 클래스를 만들어 봤다.

기본 요구사항은 2가지.
  1. 어떤 각도를 나타내는 값이 도인지 라디안 인지가 항상 명확해야 한다.
  2. 도와 라디안의 변환은 인간이 신경을 쓰지 않도록 자동적으로 이루어져야 한다.
1번 요구사항은 그냥 angle = 3.5f; 라고 했을 때, 이 3.5가 도인지 라디안인지는 코드만 보고는 알 수 없기 때문에 혼동의 여지를 준다는 뜻이다. 이를테면, angle = radian(3.5f); 같은 식으로 이루어지면 항상 명확할 수 있다.
2번 요구사항은, 라디안을 받아들이는 함수에 실수로 도 단위로 90.f라는 값을 넣더라도, 1번에 의해 어떤 단위가 사용되고 있는지 항상 명시되므로, 자동으로 변환돼야 인간의 실수가 오류를 불러일으키지 않을 수 있다는 것.

const float pi = 3.14159265358979323846f;                           // 물론, float 타입은 이렇게 큰 정밀도를 저장하지 못한다.
const float pi_half = 3.14159265358979323846f*0.5f;

class radian;
class degree;

class radian
{
public:
    radian() {}
    explicit radian( float v ) : _value( v ) {}
    radian( const degree& r );

    operator float() const { return _value; }
    radian& operator=( float f ) { _value = f; return *this; }
    radian& operator=( const degree& d );

private:
    float _value;
};

class degree
{
public:
    degree() {}
    explicit degree( float v ) : _value( v ) {}
    degree( const radian& r );

    operator float() const { return _value; }
    degree& operator=( float f ) { _value = f; return *this; }
    degree& operator=( const radian& r );

private:
    float _value;
};


radian::radian( const degree& d )
{
    _value = static_cast<float>(d) * pi / 180.f;
}

radian& radian::operator=( const degree& d )
{
    _value = static_cast<float>(d) * pi / 180.f;
    return *this;
}

degree::degree( const radian& r )
{
    _value = static_cast<float>(r) * 180.f / pi;
}

degree& degree::operator=( const radian& r )
{
    _value = static_cast<float>(r) * 180.f / pi;
    return *this;
}

각 클래스의 float을 받아들이는 생성자가 explicit인 이유는, 함수 인자로 그냥 float 값을 넣을 때 어떤 단위를 의도하는지를 명시할 것을 강제하기 위해서이다. explicit이 아니라면 다음과 같은 일이 일어난다.

class radian
{
public:
    radian() {}
    radian( float v ) : _value( v ) {}
};

void rotate( radian r ); // radian을 받아들이는 함수
....
rotate( 90.f );              // 인간이 90도를 의도하며 함수를 호출하면 원치 않는 동작

하지만 float 생성자를 explicit으로 선언함으로써, 위와 같은 의도가 명확치 않은 코드는 아예 컴파일 단계에서 제거해 버릴 수가 있다. 컴파일 에러를 통해서;

class radian
{
public:
    radian() {}
    explicit radian( float v ) : _value( v ) {}
};

void rotate( radian r ); // radian을 받아들이는 함수
....
rotate( 90.f );              // ERROR!!!
rotate( radian(90.f) );   // 이렇게 하면 동작하지만 코드를 씀과 동시에 이상함을 발견하게 된다.
rotate( degree(90.f) );  // 이것이 원하는 동작.

그 밖의 경우에는 그냥 자연스럽게 동작한다.

radian a( pi/3.f );  // pi/3 을 지정
degree b = a;       // 도로 변환하면 60도
b = 90.f;               // 90도를 지정
a = b;                  // 라디안으로 변환하면 pi/2

이런 방법은 약간만 잘 이용하면 m/ft, ms/s, kg/pound 등등 다른 단위가 이용될 수 있는 모든 부분에서 인간의 헷갈림에 의한 실수를 원천봉쇄할 수 있지 않을까 싶다;

  1. Mars Climate Orbiter는 단위계의 차이로 파괴된 우주선이다. 추력을 설정할 때 지상의 운영 프로그램은 파운드 단위를, 기체의 제어 프로그램은 kg 단위를 기준으로 제작되어 발생한 사고. [본문으로]
Posted by uhm
dev.log2009. 2. 3. 22:19
벡터는 벡터일 뿐, 3차원 벡터는 좌표 3개가 아니다.
3D게임 프로그래밍을 시작하는, 특히 2D게임을 만들다가 3D로 전향하려는 사람들에게서 잘 드러나는 것 같은데, 벡터를 벡터로 보지 않고 계산해야 할 좌표 3개로 보는 경향이 있는 것 같다. 사실, 벡터를 조작하여 얻고자 하는 무언가는 대부분의 경우 주어진 벡터로부터 특정한 방향을 가진 벡터, 혹은 주어진 벡터의 길이와 관계된 것일 경우가 많다. 이런 것을 구하기 위해서는 벡터를 좌표 3개로 분할할 필요가 없는데도, 습관처럼 좌표를 쪼개서 계산한다면, 벡터 연산에 익숙하지 않기 때문일 것 같다.

3차원 공간상의 벡터에 정의된 연산은 대략 반전, 덧셈, 뺄셈, 실수 곱셈, 실수 나눗셈, 그리고 내적과 외적이 거의 전부다. 이를 적절히 이용하면 간략한 표현으로 원하는 결과를 얻을 수 있는데, 좌표로 쪼개서 계산하면 고려해야할 예외적 상황이 증가하여 오히려 코드가 복잡해지는 결과가 초래되곤 한다.

오늘 본 문제는 '어떤 점에서 선분에 내린 수선의 발이 그 선분을 분할하는 비율'이다. 조금 더 상세히 정의하자면 선분의 시작점 s, 끝점 t가 주어졌을때, 임의의 점 p에서 내린 수선의 발 f에 대해서 |sf|/|st|의 값을 구하라는 것이다. 이런 문제는, 고등학교 수학시간에도 나오는 문제이지만, 이를 좌표로 쪼개서 풀려고 다음과 같이 하는 것을 보았다. (정확히 기억하고 있진 않을 수도 있지만)
  1. 각 벡터 p, s, t를 한 평면, 이를테면 xy평면에 투영하여 p', s', t'으로 한다.
  2. xy평면에서 선분s't'의 방향은 ( tx-sx, ty-sy )이다.
  3. xy평면에서 선분s't'과 직교하는 선분의 방향 d는 ( -ty+sy, tx-sx )이다.
  4. p'의 s'에 대한 변위 o를 구한다. 이때 o( p'x-s'x, p'y-s'y )이다.
  5. 점 o를 지나고 d와 평행한 직선과 선분 s't'의 교점 q를 연립방정식으로 구하면 그 점이 수선의 발.
  6. qx/(tx-sx)가 구하고자 하는 값이다.

대충 돌아가기는 하겠지만, 몇가지 예외사항이 존재한다. 우선 과정1에서 선분st가 xy평면에 수직일 경우 다른 평면을 골라 투영해야 한다. 또한 6단계에서 선분s't'이 y축에 평행하면 0/0의 꼴이 되어 부정이 되므로 역시 다른 좌표축을 골라야 한다. 여러가지 복잡한 예외를 고려해야 하기 때문에 결과적으로는 코드 길이가 원래보다 2배 정도 길어지게 마련이다. 하지만, 이는 내적의 성질을 이용해서 다음과 같은 간략한 방법으로 구할 수 있다.

이렇게 하면 선분의 방향이 어떠하든 일반적인 해를 구할 수 있다. 내적은 두 벡터의 길이의 곱에 사잇각의 코사인을 곱한 것과 같다는 성질을 이용한 것인데, 벡터의 길이에 코사인을 곱하면 다른 쪽 벡터에 투영된 길이가 나온다는 점을 생각하면 되겠다.

물론, 이런 방법으로는 길이의 비만 구할 수 있기 때문에 수선의 발 자체가 필요한 경우에는 따로 계산을 해야 하겠지만, 그때에도 위 결과로부터 직접 구할 수 있다. 선분 ts와 선분 fs의 길이의 비를 이미 구했으므로, 선분 ts를 이 비율대로 곱하기만 하면 수선의 발이 직접 구해진다. 따라서 수선의 발 f는 다음과 같이 구할 수 있다.

벡터에 정의된 연산이 몇개가 안되므로, 성급하게 벡터를 좌표로 쪼개려고 하는 것보다는, 벡터 연산으로 요리조리 조작해 보는 편이 더 일반적으로 유효한 결과를 가져온다. 3D프로그래밍의 시작은 벡터를 좌표의 집합이 아닌, 벡터 그 자체로 보는 것이라고나.


Posted by uhm
dev.log2009. 2. 1. 23:29
회사에서는 1주일마다 주간회의때 주제 하나씩을 잡아서 간략한 설명형식의 세미나를 한다.
지금까지 다뤄왔던 주제는 다음과 같다.
  • STL 컨테이너
  • 시간복잡도
  • 컴파일 & 링크
  • 프로세스와 쓰레드
  • 비동기 환경에서의 문제해결
  • 메모리 할당자
  • 커스텀 자료구조 설계
  • lua 스크립트 언어
  • GUI 설계변경
  • 곡선표현
  • 물리연산
  • 소프트웨어 설계 방법론
  • 애니메이션 기법
  • 커스텀 데이터 매니징
  • CPU 아키텍쳐
  • 회전변환
  • 개발 프로세스 리뷰

다는 생각이 안나지만, 대략 이러한 종류의 주제들로 약 8개월동안 진행해 왔다. 단순계산으로 24가지 주제를 다뤄온 셈인데, 이제부터라도 기록을 남기기 위해 포스팅을 해 놓아야 겠다는 생각이 든다.

지난주의 주제는 충돌.
충돌계산의 핵심은 매개변수(parametric form) 방정식이다.
좌표평면에서 x절편 A, y절편 B를 가지는 직선의 방정식은 일반적으로 다음과 같이 쓰곤 한다.
y = -(B/A)x + B
이때 A' = -B/A 로 정의하면 간략히 다음과 같이 쓸 수 있다.
y = A'x + B
이와 같은 형태는 표현은 간단하지만, 직선이 y축과 평행한 경우는 절대로 표현이 불가능하다. 따라서, 평면에서 임의의 직선을 표현하는 좀 더 나은 방식은 음함수 형태로, 다음과 같이 쓰는 것이다.
Bx + Ay - AB = 0
이와 같은 형태는 평면상에서 임의의 직선을 표현할 수는 있지만, 특정한 조건을 만족하는 점을 계산하려면 (이를테면, 두 직선의 교점) 여러차례의 이항과 소거를 거쳐야 하는 단점이 있다. 또한 3차원 이상의 공간상에서의 직선은 이와 같은 형태로 표현이 불가능하다는 결점이 있다.
매개변수 방정식에는 위와 같은 결점이 없다. 위의 2차원 평면상의 직선은, 매개변수 t에 대하여, 다음과 같이 쓸 수 있다.
x = -At + A
y = Bt
이는 다시, 벡터 방정식으로 a=(A,0), b=(b,0)으로 정의하면, 직선 l은, 다음 식으로 표현된다.
l = (b-a)t + a
이러한 형태의 표현은 3차원 이상의 공간에서도 일반적으로 성립하며, 표기도 간단하고, 매개변수 t의 범위를 제한함으로써 선분이나 반직선등을 용이하게 표현할 수 있다. 또한 한가지 변수 t만 결정하면 직선상의 한 점을 지정할 수 있으므로, 풀이도 비교적 용이하다. 기본적인 충돌 계산은, 충돌 대상이 되는 도형을 매개변수 형태로 표현하는 것으로 시작한다.

보통 충돌 시스템을 구현할 때에는 간단한 기하도형을 몇가지 정해놓고 시작하는데, 일반적으로 다음과 같은 도형들이 충돌계산에 사용되곤 한다.
  • 직선
  • 선분
  • 캡슐
  • 실린더
  • AABB
  • OBB
  • 삼각형

대략 9개 정도의 도형이 널리 이용되는데, 이들에 대한 구현을 모두 하려면, 각 도형이 다른 도형, 혹은 같은 도형과 충돌할 수 있으므로, 45 가지 경우를 구현해야 한다. 이에 대한 설명을 모두 하는 것은 길고 시간이 오래걸리므로, 여기에서는 직선-구, 직선-삼각형의 경우만 다룬다.

일반적으로 직선 l은, 직선의 방향벡터 d와 직선위의 한점을 가리키는 위치벡터 p가 주어질 때, 실매개변수 t에 대하여 다음 형태로 쓸 수 있다.
l = dt + p
또한 일반적인 구 s는, 중심 c와 반지름 r만으로 완전하게 정의할 수 있으므로, 구의 방정식은 벡터 형태로 다음과 같이 쓸 수 있다.
|s - c| = r
이와 같은 형태는 계산이 곤란하므로, 내적 형태로 다음과 같이 쓸 수 있다.
(s-c)·(s-c) = r*r
이때, 구 s와 직선 l의 교차점은 s = l 로 놓고 풀어 직선의 매개변수 t를 결정하는 작업이다. 구의 방정식에서 s = l을 대입하고 전개하면, t에 대한 2차방정식을 구할 수 있으므로, 이 2차방정식의 근으로 교점을 결정할 수 있다. 이 방정식이 2개의 실근을 가지면 직선은 구를 관통하며, 1개의 중근을 가지면, 직선은 구와 접하고, 허근을 가지면 직선은 구와 만나지 않는다.

3차원 공간상에서 삼각형과 직선의 충돌은 먼저, 삼각형을 매개변수 형태로 표현하는 것으로 시작한다. 삼각형 ABC에서, 벡터CA를 a, 벡터CB를 b라고하고, 점C의 위치벡터를 c라고 재명명하면, 삼각형 내부의 영역 q는, 두 매개변수 u,v에 대하여 다음과 같이 표현된다.
q = au + bv + c (u >= 0, v >= 0, 0 <= u+v <= 1 )
여기서 삼각형과 직선의 교점을 구하는 것은, 직선 l이 주어졌을 때, q = l로 놓고 풀어 직선의 매개변수 t와 삼각형의 매개변수 u,v를 구하는 문제로 바뀐다. l을 대입하면, 풀어야할 방정식이 나온다.
dt + p = au + bv + c
매개변수에 대한 항을 이항하면, 다음과 같다.
dt - au -bv = c-p
표현을 간단히 하기 위해 a' = -a, b' = -b, o = c-p 로 치환하면, 다음과 같이 된다.
dt + a'u + b'v = o
이는 3차원 벡터 (t,u,v)에 대한 전형적인 선형변환이므로, 행렬 형태로 바꾸면 다음과 같다.
dx
a'x
b'x
×
t =
ox
dy
a'y
b'y
u
oy
dz
a'z
b'z
v
oz
이때 행렬 (d, a', b')을 M이라고 쓰고, 벡터 (t,u,v)를 s라고 다시 쓰면,
Ms = o
곧, M의 역행렬을 M'이라고 하면
s= M'o
따라서, M의 역행렬을 구하고 벡터 o를 계한하여 둘을 곱하면 세 매개변수 t, u, v를 모두 결정할 수 있다. 유일한 해가 존재하고, u,v가 삼각형의 매개변수 조건을 만족하면, 직선 l과 삼각형 q는 교차한다.
이때, M의 역행렬을 구할 수 없는 경우는 직선과 삼각형이 평행하거나 삼각형이 직선을 포함하는 경우이므로, 이때는 삼각형의 세변과 직선을 직선-직선 간의 충돌 계산으로 교차 여부를 검사해야 한다.

Posted by uhm
dev.log2009. 1. 28. 23:38
ice 프로젝트를 시작하려다보니, 기초 수학 클래스의 성능을 측정해야만 했다. 그래서, 옛날 R모 게임을 만들던 시절에 만져본 언리얼엔진2의 스탯 수집방식을 좇아서 비슷하게 만들어 보기로 했다. 기본 방식은 수집할 스탯의 이름과 타입을 등록하여 인덱스를 지정한 후 수집할 구역의 시작과 끝을 지정하는 것. 여기에 시간 통계를 위한 API콜은 별도의 레이어로 분리하면 대략적인 틀이 나온다.
class syscore
{
public:
    static int64 clock()
    {
        int64 begin;
        QueryPerformanceCounter( (LARGE_INTEGER*)&begin );
        return begin;
    }
    static int64 clockpersec()
    {
        int64 freq;
        QueryPerformanceCounter( (LARGE_INTEGER*)&freq );
        return freq;
    }
};

class stat_collector
{
public:
    stat_collector() { _freq = (float)syscore::clockpersec(); }
    void flush();
    uint32 enroll( const string& name, uint type );
    void start( uint index );
    void stop( uint index );

    float mean_stat( uint index );
    float inst_stat( uint index );
    float total_stat( uint index );
    int   sample_count( uint index );

    class block_stat
    {
    public:
        block_stat( stat_collector& collector, uint index )
            :_collector( &collector ), _index( index )
        {
            _collector->start( _index );
        }
        ~block_stat()
        {
            _collector->stop( _index );
        }
    private:
        stat_collector* _collector;
        uint            _index;
    };

    enum stat_type
    {
        STAT_TIME,
        STAT_COUNT,
    };

private:

    struct stat_item
    {
        stat_item( const string& name, uint type )
            : _count(0), _name(name), _type(type)
        {}

        uint   _count;
        string _name;
        uint   _type;
    };
    std::vector<sint64> _prv_stats;
    std::vector<sint64> _cur_stats;
    std::vector<stat_item> _stat_info;
    float _freq;
};

void stat_collector::flush()
{
    //_prv_stats = _cur_stats;
}

uint32 stat_collector::enroll( const string& name, uint type )
{
    assert( _prv_stats.size() == _cur_stats.size() );
    assert( _prv_stats.size() == _names.size()  );
    uint32 index = _cur_stats.size();
    _prv_stats.push_back( 0 );
    _cur_stats.push_back( 0 );
    _stat_info.push_back( stat_item( name, type ) );

    return index;
}

void stat_collector::start( uint index )
{
    _prv_stats[index] = _cur_stats[index];

    switch ( _stat_info[index]._type )
    {
    case STAT_TIME:
        _cur_stats[index] -= syscore::clock();;
        break;
    case STAT_COUNT:
        break;
    default:
        assert( "unkown stat type!!!!!!!!!" && 0 );
    };
}

void stat_collector::stop( uint index )
{
    switch ( _stat_info[index]._type )
    {
    case STAT_TIME:
        _cur_stats[index] += syscore::clock();
        break;
    case STAT_COUNT:
        _cur_stats[index]++;
        break;
    default:
        assert( "unkown stat type!!!!!!!!!" && 0 );
    }

    _stat_info[index]._count++;
}

float stat_collector::mean_stat( uint index )
{
    switch ( _stat_info[index]._type )
    {
    case STAT_TIME:
        return _cur_stats[index]/(_freq * _stat_info[index]._count);
    case STAT_COUNT:
        return (float)_cur_stats[index]/_stat_info[index]._count;
    default:
        assert( "unkown stat type!!!!!!!!!" && 0 );
        return 0;
    }
}


float stat_collector::inst_stat( uint index )
{
    switch ( _stat_info[index]._type )
    {
    case STAT_TIME:
        return (_cur_stats[index]-_prv_stats[index])/_freq;
    case STAT_COUNT:
        return (float)_cur_stats[index]-_prv_stats[index];
    default:
        assert( "unkown stat type!!!!!!!!!" && 0 );
        return 0;
    }
}

네이밍 컨벤션은.. C/C++ 표준 위원회의 스타일을 따라가 봤다.
사용법은,
#define TEST_LIST() \
    TEST( l = c.length() )                   \
    TEST( c = vector_t::cross( a, b ) ) \
    TEST( l = vector_t::dot( b, c ) )      \

stat_collector _stats;

template <class vector_t>
void test_run( const char* filename, uint stat_index )
{
    static vector_t a, b, c;

    std::ofstream log( filename, ios::app );
#define TEST( expression ) #expression "\n"
    log << "=======================================" << endl;
    log << TEST_LIST();
    log << "---------------------------------------" << endl;
#undef TEST
    for ( int count = 0; count < 10; ++count )
    {
        vector_t::scalar_type x = (float)rand();
        vector_t::scalar_type y = (float)rand();
        vector_t::scalar_type z = (float)rand();
        volatile vector_t::scalar_type l = 0;
        a = vector_t( x, y, 0 );
        b = vector_t( -y, x, 0 );
        c = vector_t( x, y, z );

        _stats.start( stat_index );
        for ( int i = 0; i < 10000000; ++i )
        {
#define TEST( expression ) expression;
            TEST_LIST();
#undef TEST
        }
        _stats.stop( stat_index );
        log << _stats.inst_stat(stat_index) << std::endl;
    }
    log << "======== " << _stats.mean_stat(stat_index) << " sec/sample ==========" << std::endl;
}

int WINAPI WinMain( HINSTANCE , HINSTANCE, char* , int )
{
    uint imp_stat, exp_stat;
    imp_stat = _stats.enroll( _t("imp"), stat_collector::STAT_TIME );
    exp_stat = _stats.enroll( _t("exp"), stat_collector::STAT_TIME );
    test_run<vector3def>( "log_imp.txt", imp_stat );
    test_run<vector3sse>( "log_exp.txt", exp_stat );

    return 0;
}

이름과 타입을 등록하고, 측정할 구간을 start/end로 지정하면 끝. TEST_LIST는 테스트 대상이 어떤 코드였는지에 대한 로그를 남기기 위한 매크로.

부족한 부분은 나중에 수정하자.

Posted by uhm
dev.log2009. 1. 27. 23:02
설도 지났으니, ice 개발 계획을 본격적으로 잡아야 겠다;는 생각이 들었다.
전체적으로는 각 기능간 커플링을 없도록 제작하여 기능별로 독립적으로 사용할 수 있도록
작업하는 것이 목적. 제네릭 프로그래밍을 엔진 레벨에서 적용해 보는 것도 이 프로젝트의
목적중 하나.
  1. 벡터/행렬 클래스
    - 템플릿 기반으로 SSE 특수화 구현
  2. 드로잉
    - OGL/DX 공용 드로잉, 다중 쓰레드 구현
  3. 맥스 플럭인/익스포터
    - 맥스 뷰포트로 렌더링, 바이너리/텍스트 포맷으로 저장
  4. 장면 트리
    - octree/BSP
  5. 애니메이션
    - 버텍스 스키닝/애니메이션블렌딩, 익스포터 제작
  6. 셰이더
    - 맥스의 머티리얼과 대응하는 개념으로 제작, 맥스 셰이더 플럭인 제작
  7. 에디터
    - height field/BSP+PVS, 독립 어플리케이션으로 seamlessness 구현.
  8. 파티클
    - 맥스 플럭인 제작
  9. 물리 시뮬레이션
    - 충돌/IK/강체역학/마찰/스프링+댐퍼, 맥스 플럭인
  10. 그림자
    - 부드러운 경계
Posted by uhm