2011년 4월 29일 금요일

unity3d shiva3d airplay SDK comparison for online game



Issues
Unity3D
Shiva3D
AirPlay SDK
Platforms
+PC,Mac
+Palm
+bada,Symbian
Community
More
Less
Few
Native
Limited
Better
C++ only
Tool
Good
Fair
No
Rendering
Good

Fair

Limited

Socket
C# socket
only for Shiva Server
BSD socket
I18N
Unicode
Support
Not Sure
Total Score
90
70
51

현재까지 제가 알아본 바대로 적었습니다.
Unity3d가 인기가 많은 이유가 있네요.
C#을 싫어하지 않는다면, Unity3D를 선택해야 할 듯 합니다.
Unity3D를 쓰고, 서버를 구현한다면, C#으로 하는게 코드 공유가 되서
생산성에 좋을 듯 합니다. Photon Server 를 쓰면 될 듯.
Low Latency를 요하는 게임을 구현한다면, C++로 만들어야 할텐데, 코드 공유가 안되니,
서버 프로그래머가 따로 필요하겠네요.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

2011년 4월 7일 목요일

first milestone of tinyNetwork completed

tinyNetwork library의 milestone1이 끝났다.
거의 모든 코드가 template으로 되어 있다.

이제, 테스트 코드와 쓰레딩 모델들을 구현하는 concrete(구체적인)한 일들만 남았다.
같이 할 사람 있으면 좋겠다;;

이번달 말까지 마무리가 목표이다.
마무리 하면서, 새로운 프로그래밍 언어를 구상해야겠다.

2011년 4월 4일 월요일

strict keyword in C99

C99 표준부터 쓸 수 있는 keyword인 'restrict'는 나도 몰랐었다.
결론적으로 instruction 한두개를 절약하는데 매우 유용하다.

void updatePtrs(size_t *restrict ptrA, size_t *restrict ptrB, size_t *restrict val)
{
*ptrA += *val;
    *ptrB += *val; 
} 
 
이렇게 pointer앞에 restrict를 넣어주면, 
함수내에서 포인터 aliasing이 일어나지 않는다는 것을
compiler에게 알려준다. 또한, 서로 같은 포인터를 가리키지 않는다는 것을 알려준다.
그럼으로 compiler가 불필요한 instruction을 생성하지 않아도 되게 한다.
 
A. 다음은 restrict를 하지 않았을때의 instruction들이다.
---------------------------------------------- 
load R1 ← *val  ; Load the value of val pointer
load R2 ← *ptrA ; Load the value of ptrA pointer
add  R2 += R1   ; Perform Addition
set  R2 → *ptrA ; Update the value of ptrA pointer
; Similarly for ptrB, note that val is loaded twice, 
; because ptrA may be equal to val.
load R1 ← *val  
load R2 ← *ptrB
add  R2 += R1
set  R2 → *ptrB
---------------------------------------------- 
 
B. 다음은 restrict를 넣었을때의 instruction들이다.
----------------------------------------------  
load R1 ← *val 
load R2 ← *ptrA
add  R2 += R1
set  R2 → *ptrA
; Note that val is not reloaded,
; because the compiler knows it is unchanged
load R2 ← *ptrB
add  R2 += R1
set  R2 → *ptrB 
----------------------------------------------

B에서는 *val의 포인터 값이 바뀌지 않는 다는 것을 알기 때문에, 
val을 R1레지스터에 reload하지 않았다.
(위의 설명은 위키에서 가져왔다. http://en.wikipedia.org/wiki/Restrict )
 
이런 케이스가 얼마나 될꺼냐고?
nedtrie의 소스를 보다가 쓰고 있는 현장을 목격했다. ㅎ
 http://www.nedprod.com/programs/portable/nedtries/
여기를 보면 더 자세한 설명이 되어 있다.
GCC의 strict_aliasing flag을 켜는 것에 대해 써 있는데,
모두 켜도 되는지 확실해야 한다. 아마도 확신하기 쉽지 않기 때문에, 
개별적으로 써야 할 듯 하다.
http://cellperformance.beyond3d.com/articles/2006/05/demystifying-the-restrict-keyword.html
도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^


2011년 4월 3일 일요일

non-block lock free circular queue

non-block circular queue에 대한 내용이다.
one producer,one consumer환경에서 lock을 쓰지 않는 방법을 제시한다.
dream.eng.uci.edu/eecs123/15_NBB.pdf

다음은 저자 홈페이지
http://dream.eng.uci.edu/kim-kane.htm
저자가 한국인 교수님이다. ^^

TMO를 다운로드하면, NBB소스를 볼 수 있는데,
자세히 살펴보면 버그가 숨겨져 있다;;;;
공부겸 스스로 찾아보길 바란다. ^^

이 circular queue로 thread간 통신에 쓰면 lock을 쓰지 않아도 된다. ^^
다만, multiple producer/multiple consumer 상에서는 통하지 않는다.
multiple producer/multiple consumer에서는 producer lock/consumer lock을 사용하여 제어하면 될 것이다.

linux에서 memory barrier를 이용한 방법도 함께 소개한다.
다음 링크를 참조.
http://lxr.linux.no/#linux+v2.6.38/Documentation/circular-buffers.txt

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

2011년 4월 2일 토요일

100k problem? 1024cores?

이전에는 10k 즉, 동시접속 1만명이 문제였다면, 이제는 동시접속 10만명을 받으면서,
최적화하느냐가 문제인 것 같다.
앞으로 core수는 계속 늘어날테니까...
아주 많은 부분에서 최적화가 이루어져야 할 것이다.

일단 네트워킹 부분에서 시작하고자 한다.