smart and get things done

내가 template metaprogramming을 좋아 하지 않는 이유

런타임 디버깅에 익숙한 개발자들에게는 개발 난이도가 올라가면서, 코드의 가독성의 난해함으로인해 유지 보수의 어려움이 있는데다가, 그런 코드작성에 익숙한 개발자를 뽑기도 힘든데, C#에 익숙해진 나로서는 그 늘어나는 컴파일 타임을 견딜 자신이 없어서 이다.

최근 시간이 좀 생겨서 처음으로 언리얼엔진을 깔아서 이틀 정도 살펴 볼 기회가 있었음

비주얼 스튜디오 2015를 사용하고 있는데 엔진 소스 받고 인텔리센스 문제 때문에 계속 비주얼 스튜디오가 크래쉬가 나고 있음. 

짜증남...

update2을 받아서 설치하니 더이상 크래쉬가 나지 않음

엔진을 빌드하고 에디터 실행, 횡스크롤 샘플 프로젝트를 기반으로 한 새 프로젝트를 생성 해봄.

블루 프린트 좀 살펴 보다가, 테스트 삼아 프로젝트에 포함된 캐릭터 지우고 우리 프로젝트에서 사용하는 캐릭터 중 하나를 연결 해 볼려고 함.

샘플 캐릭터를 참고해서, 애니메이션 블루프린트 새로 하나 만들어서 이동, 걷기, 점프, A 공격키까지 적용 되는 애님 그래프를 하나 만들어 봄

캐릭터 블루프린트를 애니메이션 블루프린트에서 참조 하는 방법을 몰라 한참 헤맨것을 제외하고는 생각 보다 쉽게 전환이 됨.

C++ 코드 연동을 한번 해 보고 싶어서, Pawn을 상속 받는 MyCharacter 클래스를 하나 만들어 봄.

프로젝트를 만들고 블루프린트만을 사용할 때 프로젝트가 생기지 않고, 새로운 클래스를 생성하는 시점에서 새로운 프로젝트가 생기는 구나.

프로퍼티 설정하는 거 테스트 해보기 위해서, 테스트 코드 몇 개 추가하고 빌드 시도.. 

빌드를 하니 링크 에러가 남...

먼일이지 하는 중 에디터를 닫고 프로젝트를 빌드 하니 빌드가 잘 됨.

다시 에디터를 띄우니까 링크 에러가 남. 

디버그 모드로 실행 해 보니, 에디터에서 디버거를 자꾸 종료를 시킴.

짜증남..

여기까지가 1일차

다음 날 회사 와서, 같이 일하는 프로그래머 한테 위에 문제를 이야기 하고 짜증내면서 에디터 다시 닫고, 빌드 실행시키고, 다시 에디터 띄우고 디버그 모드로 실행하니, 새로운 에디터가 뜸....!!

머지? 순간 당황스러웠음.

뒤에서 이걸 지켜 보던 프로그래머가 한마디 함.

C++로 개발 할 때는 디버그 모드로 실행하면 프로그램이 실행되는 게 당연한건데, 요즘 유니티로만 개발하니까 생기는 착각이라고 함.

아 그렇구나, 바로 납득이 됨.

그리고 바로 짜증이 나서, 바로 에디터랑 프로젝트 닫아 버리고, 지금 까지 쳐다도 안보고 있음.....

// 이 코드는 구현의 예만을 보여주기 위한 것으로
// 실제 사용하기 위해서는 예외 처리나, 메모리 할당 등의 
// 추가적인 구현이 필요.
#include 
#include 

#define SAFE_FREE(buf) if( buf ){ free(buf); buf = 0; }
#define MEM_PTR		unsigned char*

class stack_allocator
{	
	void	_alloc_buffer(size_t stacksize)
	{
		_free_buffer();
		buffer_ = (MEM_PTR)malloc(stacksize);
		top_ = buffer_;
		bottom_ = top_+stacksize;
	}

	void	_free_buffer()
	{
		SAFE_FREE(buffer_);
	}
public:
	stack_allocator(size_t stacksize = 1024):buffer_(0), top_(0), bottom_(0)
	{
		_alloc_buffer(stacksize);
	}

	void*	alloc(size_t size)
	{
		MEM_PTR ret_ptr = top_;
		top_ = ret_ptr + size;
		if( top_ > bottom_ )
		{	// check overflow
			return 0;	//throw exception;
		}
		return ret_ptr;
	}
	
	friend	void* operator new( size_t size, stack_allocator& mem, int count);
	friend	class scoped_mem_stack;

	MEM_PTR	get_top()
	{
		return top_;
	}
protected:
	void	restore(MEM_PTR ptr)
	{
		top_ = ptr;
	}
private:

	MEM_PTR	buffer_;
	MEM_PTR	top_;
	MEM_PTR	bottom_;
};

void* operator new( size_t size, stack_allocator& allocator, int count = 1)
{
	return allocator.alloc(size*count);
};

class scoped_mem_stack
{
public:
	scoped_mem_stack(stack_allocator& allocator):allocator_(allocator)
	{
		backup_top_ = allocator_.get_top();
	}

	~scoped_mem_stack()
	{
		restore();
	}

	void	restore()
	{
		allocator_.restore(backup_top_);
	}
private:
	stack_allocator& allocator_;
	MEM_PTR			 backup_top_;
};

stack_allocator	g_stack_allocator;

struct test_struct
{
	char	buffer[100];
};

void main()
{
	scoped_mem_stack guard(g_stack_allocator);

	MEM_PTR back_ptr = g_stack_allocator.get_top();
	MEM_PTR back_ptr2 = back_ptr;
	assert(back_ptr == g_stack_allocator.get_top());

	void* test_ptr = new(g_stack_allocator) void*;
	back_ptr +=sizeof(void*);
	assert( back_ptr == g_stack_allocator.get_top());

	test_struct*	test_struct_ptr = new(g_stack_allocator) test_struct;
	back_ptr += sizeof(test_struct);
	assert( back_ptr == g_stack_allocator.get_top());

	test_struct**	test_struct_ptr_ptr = new(g_stack_allocator, 5) test_struct*;	
	back_ptr += sizeof(test_struct*)*5;
	assert( back_ptr == g_stack_allocator.get_top());
	guard.restore();

	assert(back_ptr2 == g_stack_allocator.get_top());
}

ØMQ(Zero Message Queue라고 약자가 아닐까 생각됩니다)

Lightweight messaging framework으로 보입니다.

LGPL 라이선스를 따르는 Opensource이며, C++로 작성이 되어 있어서 매우 빠르다고 합니다.

특징적으로는

1. 초당 4,100,000개정도의 메시지의 처리가 가능하다고 하며
2. broker, directory service등의 몇가지 message model들을 사용하고
3. AIX, FreeBSD, HP-UX, Linux, Mac OS X, OpenBSD, OpenVMS, QNX Neutrino, Solaris and Windows등의 OS을 지원하며
4.  C, C++, Java, Python, .NET/Mono and Fortran 등의 API들을 지원한다고 합니다.

많은 기능들을 생각하면, 다운로드 가능한 소스의 크기가 생각보다 작다는 것에 좀 놀랍습니다.(압축을 풀면, 테스트가능한 바이너리들까지 포함해서, 1.26MB 밖에 안됩니다).

소스를 잠깐 살펴 봤는데, 최근에 본 C++ 라이브러리들에 비해서 코드가 상당히 직관적이어서 보기가 좀 편한 편입니다. (소스 파일 이름을 보고 이런 기능이 있겠구나 하고 보면, 다른 파일을 볼 필요없이 대부분의 구현이 그 파일내에 있습니다. 이런게 직관적인거죠 :) )

얼마전부터 메시지 기반의 서버 솔루션을 생각하고 있었는데, Axum을 포함해서 ØMQ까지 비슷한 솔루션들을 자주 접하게 되네요.
역시나, 병렬프로그래밍에서 메시징기반 솔루션이 대세인가 봅니다.

사이트에 가보면, 10Gb 이너넷상에서 실행한 테스트 결과을 볼수 있는데요.

1byte의 메시지 전송 속도가 28.45 마이크로 세컨드 정도가 나온다고 하는데, 1byte의 메시지는 현실성이 없으므로 별로 의미가 없어 보이고, 512byte의 메시지 전송 속도가 33.08 마이크로 세컨드 정도 나온다고 합니다.

8byte 크기의 메시지를 초당 2.8백만개 정도 처리 한다고 하는데요. 위의 사백만개는 어떤 환경에서 나온 수치인지 궁금하네요.

어쨋든 개인적으로 도움이 많이 되는 참고 자료라고 볼수 있을거 같네요.

코드를 좀더 살펴 보고, 다시 포스팅 해 보도록 하겠습니다.

위키디피아에서의 ABA Problem 설명은 lock free stack구현에서의 문제점을 예제로 들고 있습니다.

 


/* Naive lock-free stack which suffers from ABA problem.*

class Stack {


   volatile Obj* top_ptr;

   // Pops the top object and returns a pointer to it.
   Obj* Pop() {
     while(1) {
       Obj* ret_ptr = top_ptr;

       if (!ret_ptr) return NULL;       
       // ** 실행 구간 1
       Obj* next_ptr = ret_ptr->next;          
       // ** 실행 구간 2
       if (CompareAndSwap(top_ptr, ret_ptr, next_ptr)) { 
         return ret_ptr;
       }
       // The stack has changed, start over.
     }
   }
}; 

언뜻 봐서는 코드상으로는 크게 문제가 없어 보이며, 실제로도 자체 구현상으로는 거의 완벽한 
lock free stack이 구현된것으로 생각됩니다.
(** CompareAndSwap()은 인자 1,2가 같은값일때, 1번인자의 값을 3번 값으로 swap시킵니다. 
 Atomic Operations 이므로 매우 빠릅니다.)


그러나, 아래의 시나리오를 봅시다.


스택이 top->A->B->C 로 초기화되어 있다고 가정했을때, 

// --- 1번 Thread 작업 --

// 1번 Thread가 pop을 실행합니다.

 ret = A;
 next = B;

// --- 1번 Thread 작업 중 작업전환 -- 

// --- 2번 Thread 작업 -- 

// 2번 스레드의 pop이 실행됩니다.

 { 
   ret = A;   // 1번 스레드의 pop이 끝까지 실행되지 못했으므로, top은 A입니다
   next = B;
   CompareAndSwap(A, A, B)  // 성공, top은 B가 됩니다.
   return A;
 } // 스택상태는 top -> B -> C 이 됩니다.
 { // 2번 쓰레드가 한번더 pop을 실행합니다.
   ret = B;
   next = C;
   CompareAndSwap(B, B, C)  // 성공, top은 C가 되었습니다.
   return B;
 } // 스택상태는 top -> C 이 됩니다. 
 delete B;  // 2번 쓰레드에서 B값을 삭제 합니다.
 { // 2번 쓰레드에서 아까 위해서 pop된 A를 push합니다.
   A->next = C;
   CompareAndSwap(C, C, A)  // 성공,  top은 A가 됩니다.
 } // 스택상태는 top -> A -> C 이 됩니다. 

// --- 2번 Thread 작업 중 작업전환-- 


// --- 1번 Thread 작업 다시 실행-- CompareExchange(A, A, B); 
 // top과 return값이 모두 A이므로 성공이 됩니다.
 // 그러나 B는 2번 Thread에서 삭제가 되어 있으므로, 이 구간 부터, stack은 잘못된 메모리
 // 를 참조하게 됩니다.
 // 이 상황을 ABA Problem 이라고 합니다.

쉽게 일어나지 않을 상황 같지만, 일어나지 않는다는 보장도 없는 상황입니다.

물론 C#이나, Java같이 가비지컬렉션을 사용하는 언어에서는 발생되지 않을 문제이지만, 

C계열에서는 반드시 고려가 되어야 될 문제이기도 합니다. 

당장 생각나는 해법으로는 

1. 그냥 sync를 시키면서, 표준 stack을 사용

2. smart pointer를 사용

정도가 될거 같지만, 좀더 고민이 필요한 문제일거 같습니다

역시 병렬프로그래밍의 길은 멀고도 험한거 같네요 :)

// _set_purecall_handler.cpp
// compile with: /W1
#include <tchar.h>
#include <stdio.h>
#include <stdlib.h>

class CDerived;
class CBase
{
public:
   CBase(CDerived *derived): m_pDerived(derived) {};
   ~CBase();
   virtual void function(void) = 0;

   CDerived * m_pDerived;
};

class CDerived : public CBase
{
public:
   CDerived() : CBase(this) {};   // C4355
   virtual void function(void) {};
};

CBase::~CBase()
{
   m_pDerived -> function();
}

void myPurecallHandler(void)
{
   printf("In _purecall_handler.");
   exit(0);
}

int _tmain(int argc, _TCHAR* argv[])
{
   _set_purecall_handler(myPurecallHandler);
   CDerived myDerived;
}

_set_purecall_handler는 순수 가상함수가 호출이 되었을때 호출할 콜백 함수이다.

프로세스가 종료 될 때 콜백함수를 설정하는 atexit()와 비슷한 유사한 형태라고 할수 있다.

오늘 알게 되어서 부끄럽지만, 클래스의 생성자가 완료되기 전까지는 해당 클래스의 인스턴스는 같은 형식이라고

할수 없다고 한다.

위와 같은 꼴 때리는 코드를 작성할 일은 없지만, CDerived 클래스의 생성자가 CBase클래스에게 자신의 인스턴

스(this)를 넘기는데, 이게 유효한 코드라고 볼 수가 없다는 것이다.

언뜻 보면 문제가 없어 보이는 코드지만 CBase의 소멸자가 호출 될 때 에러가 발생한다.

해당 코드의 m_pDerived의 메모리 구조를 보면 위의 그림과 같은 요상한  구조가 만들어진다는 거다.

 500M 정도의 파일을 복사 했을때,

MFC의 CFile나 fopen/fread/fwrite 보다 20% 이상의 성능 향상을 볼수 있다.

진행상태를 나타내기 위해서 잘라서 읽을려면

CopyMemory 부분만 살짝 손대면 된다.

어차피 IO처리라서 큰 차이가 없을것으로 생각했는데..

생각보다 큰 성능 차이를 보여 준다.

최근에 한 삽질중의 하나..

파일 Sync를 마추기 위한 툴을 만들고 있는 중..  툴 내부에서 도스 명령어 copy를 실행할 필요가 있어서,

ShellExcuteEx()를 사용해서 아래와 같이 코드를 작성했다.

SHELLEXECUTEINFO si;
ZeroMemory(&si, sizeof(si));
si.cbSize = sizeof(SHELLEXECUTEINFO);
si.lpFile = _T("copy");
si.lpParameters = _T("c:\temp\*.* d:\temp");
si.lpVerb = _T("open");
si.nShow = SW_SHOW;
ShellExecuteEx(&si);

(생각나는대로 작성했으니, 코드가 컴파일 된다는 보장은 없지만, 의미상 이해는 되리라 생각한다.)

그리고 테스트를 해 보니, 실행이 안된다. 다른 실행파일들은 잘 만 실행되는데, copy만 유독 안된다.

한참 괴로워 하는 중.. 생각난것이 도스 시절 copy는 외부 명령어가 아니고, 내부명령어였던 것이다.

copy로 파일 검색을 해 보니, 역시나 copy.com 이나 copy.exe라는 파일은 없다...

흠 그렇군.. 그럼 윈도우즈에서는 cmd가 도스창이니, cmd를 이용하면 되겠구나 라는 생각에 약간의 삽질 후 아래와 같이 코드를 수정했다.

SHELLEXECUTEINFO si;
ZeroMemory(&si, sizeof(si));
si.cbSize = sizeof(SHELLEXECUTEINFO);
si.lpFile = _T("cmd");
si.lpParameters = _T("/C copy c:\temp\*.* d:\temp");
si.lpVerb = _T("open");
si.nShow = SW_SHOW;
ShellExecuteEx(&si);

잘된다.

당연한건데, 나만 몰랐던건가? 라는 자괴감이 든다... -_-

지나고 나서야 생각나는 건데 이 부분은 CI설정했을때도 비슷한 구문을 많이 접했었던건데..

** 참고로 /C 옵션을 주지 않고 실행하면 해당 명령을 실행한후 커맨드 창이 남아 있다. /C를 주어야 해당 명령 완료후 창이 종료 된다.