Thursday, September 16, 2010

Stack overflow 시 minidump

http://sweeper.egloos.com/2420307

지금 현재 프로젝트에서 google-breakpad 를 쓰고 있는데,

얘도 위의 것과 비슷한 원리로 덤프를 남기고 있다.

위의 링크에서는, stack overflow 발생시 thread 를 하나 생성해서 덤프를 찍는 방법을 쓰고,

google-breakpad 같은 경우는 이미 시작부터 dump 용 thread 를 만들어서 그 thread 가 주가 되어서 dump 를 남긴다.

배현직님 께서 카페에 쓰신 글 중, dump 안남고 죽는 경우.
3가지 정도로 기억합니다. Pure virtual function. CRT check. Stack overflow. 앞 둘은 핸들러 루틴 오버라이드로 해결되며 뒷것은 타 스레드에서덤프남기기 혹은 sp레지스터 변경하기로 해결돼요.

CRT check 는 안걸려봐서 모르겠지만,

Pure virtual function 과 stack overflow 는 google-breakpad 로 dump 남기는 걸 확인했음.

Tuesday, September 14, 2010

A current trend in programming (2010)

요즘에 느끼는 프로그래밍 관련 트렌드는 - '멀티코어' 에서 성능이 잘 나오는 프로그램을 만들자. - 인 거 같다.
I feel something that the current trend in programming is to write a good code for better performance in multi core CPU.

물론, 멀티코어는 아주 오래전 부터 있던 거니깐... 막 요즘의 트렌드라고 할 수는 없겠지.
Of course, this is not a new trend. The multi core CPUs were already used very long time ago.

내가 처음 서버 개발에 뛰어 들었던 2001 년에도, 우리 서버 Dell 머신은 CPU 가 4 개 였었지.
When I started a server programming in 2001, our server machine - DELL - had 4 CPUs.

아키텍쳐는 현재의 하나의 Unit 에 N 개의 코어가 달린 것과는 완전 다른 것이지만.
The architecture is totally different from current CPUs which have N-cores in one unit.

여튼 오래된 이슈임에는 틀림없다.
Anyway, that's pretty old issue.


그 때의 나는 완전 생초보였고, 그냥 프로그래밍 하기도 힘들어 죽겠는데
멀티코어는 나의 능력을 벗어나는 부분이었다.
I was a very beginner in programming at that time so that I couldn't have enough skill for multi core programming.

비록, 멀티쓰레드 프로그래밍을 하긴 했지만, 그건 어디까지나 쓰레드 프로그래밍.
Even though I programmed in multi threading environment, that was in application level thread programming. 

내부를 많이 뜯어보지 않고 Application 단에서 쓰레드를 돌리는 그런 수준의 프로그래밍이었지.
I didn't take a look deeply into the core level.


헌데 언제부터냐... 2007년 쯤 인 듯.
By the way, a someday in 2007.

GDC 세션 중에서 GPU 로 프로그래밍 하는 부분을 보고 깜짝 놀랬던 기억이있다.
I was surprised by a GPU programming session in GDC.

어셈블리 짜듯이 뭔가 복잡해 보이는 instruction 들로 코딩을 하는...
It just looked like assembly which has a lot of complex instruction for programming.

그때는 그냥 아 뭐 저렇게 힘들게 굳이 코딩을 해야 하나 라는 생각을 하고 넘어갔었는데,
I couldn't have any good reason to use the difficult instructions at that time.

이미 그 때에 CPU 와 GPU 를 조금 더 가깝게 활용하는 프로그래밍이, 새로운 트렌드가 될 거라는 느낌을 받았지만,
애써 외면해왔었다. '굳이 꼭 해야하느냐' 라는 생각이 컸었기 때문에.
I thought we do not need a sort of complex coding even though I got a feeling that it would become a new trend to use CPU and GPU in direct way.


그 후로 몇 년동안의 프로그래밍 이슈 중 하나 컸던 게 있었다면
- Lock 을 최대한 줄이자 - 이었던 거 같다.
For last a couple of years, one big programing issue was that reduce 'lock' as possible.

Lock 을 하면서 발생하는 여러가지 부수적인 성능저하 요인 때문에, 코어가 아무리 늘어나고 늘어나도 프로그램의 성능이 전혀 나아지지 않기 때문이다.
That is because there are lot of facts which couldn't give a good performance even though an application uses lots of threads, and a machine has multi core cpu.

LockFree 알고리즘을 시작으로, Lock 을 최대한 피하는 구조, Lock 없는 병렬처리 늘리기 등등.
So, we got a couple of new trends that Lock-Free algorithms, avoiding lock architectures, parallel processing without locking and more.

그런데 이런 식의 접근 방법은, 생각보다 내포되어 있는 문제가 꽤나 많고,
(Compiler 의 명령어 재배치, Lock Free 의 Hazard Pointer, 무한루프. 제한적인 Thread 사용을 하게 되는 OpenMP. 여러 제약이 있는 TBB 의 Concurrency)
However, these approaches have a couple of problems.
(Instruction reorder by compiler optimizations, Hazard pointer and infinite loop in Lock free, limited threading of openMP and lots of restriction in TBB concurrency algorithm)

프로그래밍 할 때 신경써야 할 부분이 너무나도 많은 데다가,
그렇다고 또 획기적인 성능 향상이 이루어 지는 것도 아니었다.
There are too many concerns in writing codes even though it can't give a pretty better performance.


이러다 보니, 다시 재조명 받게 된 것이 차라리 CPU 를 직접적으로 활용하자 인 듯.
So now, the old trend comes again. Using CPU instruction more and directly.

CPU 가 더 빠르게 연산을 처리할 수 있도록 자료구조, Align 도 맞추고,
Cache 적중율을 높이기 위한 작업도 해주고,
CPU 별로 가지고 있는 확장 명령어도 써주고,
(A well designed data structure for better cpu operations, aligns, make cache hit more and use extension instruction in CPUs)

사실 위에 언급한 부분들은, 386, 486, Pentium 시절에 많은 프로그래머들이 고민했었던 이슈인 거다. (물론, 난 그때 프로그래밍 할 줄 몰랐음.)
It is actually techniques which were used for 386, 486 and Pentium CPUs. And a lot of programmers had thought and used it long time ago. (Of course, I didn't know a programming at that time.)

지금 시대에선, 이 모든 것들을 멀티코어에 맞게끔 짜주어야 한다는 게 더해진 거지.
It comes again with a big issue - multi core.

게다가, GPU 까지 써가면서 프로그래밍을 해야할 상황이 눈 앞에 온 거 같다.
In addition, we are about to use GPU programming as well.

물론, 이렇게까지 하지 않아도 프로그램은 잘 돌아갈테지만. :)
I'm sure that an application will work very fine even though programmers don't use those techniques for their applications.

얼마전 어디서 살펴본 Programming Quiz 에서도 이 쪽에 관련된 부분이 꽤나 등장했었고
However, it's obviously a new trend that we definitely need to know. (If we use C/C++)

요새 출간되는 책만 살펴봐도 이 쪽 관련된 책이 많이 출간이 되고 있다.
There are a couple books released which explain it.

그간 애써 모른척하고 있었지만, 이제는 발벗고 나서서 알아야 할 듯. ㅋ
I have tried to avoid this LoL, but, I can't do it any more. I need to study right now.



+ 역시 아무생각없이 짤 수 있는 C# 이 최고인건가.
+ That's why I like C#. It makes my brain empty.


짧게 쓰려고 했었는데 다 쓰고 나니 엄청 길군 -_-;