머신러닝용 데스크탑 업그레이드 후기…

지난해 회사를 옮기고 난 후 필요에 의해 스터디도 많이 하고 논문도 원없이 보고 있는거 같다.

처음엔 도대체 이게 뭔가 싶었는데, 논문들을 계속 보다보니 왠지 이젠 스크래치로 구현도 가능할 것 같아서 실현을 해보기 위해 지난 2월 데스크탑을 업그레이드 했다.

그 결과물들은 요기:

Continue reading 머신러닝용 데스크탑 업그레이드 후기…

XLA를 소개합니다.

최근 업무 관련해서 XLA를 알게 되었는데, 재밌는 프로젝트인데 반해 관련된 자료를 찾는게 쉽지 않길래 한번 소개를 해보면 좋을 것 같다는 생각이 들었습니다.

우선 XLA (Accelerated Linear Algebra)는 Tensorflow의 서브 프로젝트로 그래프 연산의 최적화 / 바이너리 사이즈의 최소화 등을 목적으로 하는 컴파일러입니다.

Continue reading XLA를 소개합니다.

slacker 기반 slackbot 만들기

재밌어보이길래 python으로 간단한 슬랙봇을 만들어볼까 하고 알아봤더니 slackbot이란 모듈을 사용하면 슬랙봇을 쉽게 만들 수 있을것 같아서 슬랙봇을 만들어봤다.

그런데 파이썬 프로세스는 멀쩡하게 살아있지만 하루 정도가 지나면 봇이 disconnected 상태로 바뀌는 문제가 지속적으로 발생하는 문제가 있었다. 관련해서 예제 코드들을 찾아봐도 별다른 부분이 없길래 며칠 동안 디버깅을 하면서 문제를 해결해봤다.

우선 인터넷에 떠도는 slacker 기반 echo 봇의 기본 골격은 아래와 같았는데…

Continue reading slacker 기반 slackbot 만들기

공개 서체: 네이버 나눔고딕_코딩

얼마전 네이버에서 고정폭 서체인 ‘나눔고딕_코딩’ 서체를 OFL(Open Font License)로 공개하였고, gd를 이용해서 뽑은 12pt 샘플은 다음과 같습니다.

나눔고딕_코딩 12pt 샘플

gd의 문제로 인하여 영문과 한글의 폭이 동일하게 출력되었는데, 맥이나 윈도우, 리눅스(약간의 설정 필요) 등에서는 영문과 한글의 폭이 2:1 이다보니 서체 이름에서와 동일하게 코딩용으로 사용하기에 딱이겠네요.
* http://dev.naver.com/projects/nanumfont
덧: 서체 이름에 사용된 언더바(‘_’) 때문에 맥에서 약간의 문제가 있었는데, 서체가 업데이트 되면서 이름이 ‘나눔고딕코딩’으로 바뀌었고, 맥에서도 문제 없이 사용할 수 있게 되었습니다.

공개 서체들 소개…

내 눈엔 순천향체가 젤 이뻐보인다. 참고로 프리뷰에서 ‘아햏햏, 똠방각하’가 제대로 보이질 않는다면 한글 2350자만을 지원하는 서체임.

패키지 서체이름 스타일 구분 프리뷰
나눔글꼴 나눔고딕 Regular 한글 11,172자
Bold 한글 11,172자
나눔명조 Regular 한글 11,172자
Bold 한글 11,172자
나눔고딕코딩 나눔고딕코딩 Regular 한글 11,172자
Bold 한글 11,172자
다음체 다음 Regular 한글 2,350자
SemiBold 한글 2,350자
렉시굴림 렉시굴림 Regular 한글 2,350자
서울 서체 서울 남산체 Light 한글 11,172자
Regular 한글 11,172자
Bold 한글 11,172자
ExtraBold 한글 11,172자
서울 한강체 Light 한글 11,172자
Regular 한글 11,172자
순천향체 순천향체 Regular 한글 2,350자
아리따체 아리따 Light 한글 11,172자
Regular 한글 11,172자
SemiBold 한글 11,172자
Bold 한글 11,172자
은글꼴 은돋움 Regular 한글 11,172자
Bold 한글 11,172자
은그래픽 Regular 한글 11,172자
Bold 한글 11,172자
은궁서 Regular 한글 11,172자
은바탕 Regular 한글 11,172자
Bold 한글 11,172자
은필기 Regular 한글 11,172자
Bold 한글 11,172자
한겨레결체 한겨레결체 Regular 한글 11,172자
ttf-alee 은진 Regular 한글 11,172자
은진낙서 Regular 한글 11,172자
구슬 Regular 한글 전용
반달 Regular 한글 11,172자
방울 Regular 한글 11,172자
네이버 사전체 네이버 사전체 Regular 한글 11,172자
연체체 연세 제목체 Regular 한글 2,350자
연세 소제목체 Regular 한글 2,350자
연세 로고체 Regular 영문, 숫자
조선일보 명조체 조선일보 명조체 Regular 한글 11,172자
문화부 글꼴 Regular 한글 2,350자
백묵 글꼴 Regular 한글 11,172자

위 결과는 cairo+freetype을 이용해서 렌더링한 결과입니다. 사용된 소스는 아래 URL에서 확인하실 수 있습니다.
* http://mytears.org/tmp/cairo/text.c

CG: dithering

팩스에서 처럼 이미지를 흑/백 으로만 표현할 수 있는 경우에도 어느 정도의 명암을 표현하기 위한 방법으로 아래와 같은 오리지널 이미지가 있을 때…

한 픽셀 값은 0~255 사이의 값을 가진다고 하고, 128 이상의 값은 하얀 색으로, 128 미만 값은 검은 색으로 표현하면 결과는 다음과 같다.

보다시피 디테일은 거의 사라져버리기 때문에 이런 것을 피하기 위해 디더링이란 기법을 사용하곤 한다. 수식으로 이를 표현해보자면 다음과 같고…

말로 설명하자면 랜덤 값을 더해준 뒤 128 을 기준으로 Thresholding 을 한다! 정도로 표현이 가능할 듯… 이론적으론 매우 간단하지만 효과는 확실하다. -16~16 의 랜덤 값을 이용하여 dithering 한 결과는 다음과 같다.

-32~32 사이의 랜덤 값을 이용할 경우는…

확실히 좀 디테일이 조금 생겨나는 것을 확인할 수가 있다. 장비들이 좋아지면서 이런 식의 트릭들에 대한 연구는 사라져가는 것 같다. -_ㅠ
위 테스트에 사용한 코드:

메모리 복사 코드 최적화…

kldp 를 눈팅하다가 오늘 재밌는 문서를 읽게 되었습니다. 2001년도에 AMD 에서 나온 문서였는데, 그 내용이 상당히 흥미로워서 몇 가지 내용을 옮겨볼까 합니다.
메모리에서 연속된 값들을 다른 곳으로 복사하기 위해 사용할 수 있는 가장 간단한 어셈블리 코드는 다음과 같습니다.

rep movsb 명령은 repeat move single byte (바이트 단위로 값들을 반복해서 옮긴다.)라는 의미를 가집니다. esi 가 가리키는 곳에 있는 값을 edi 로 ecx 에 있는 개수 만큼 복사하게 됩니다. 이렇게 할 경우 일초에 약 620MB 를 복사할 수 있다고 하네요.
이 코드를 byte 단위가 아니라 4 byte 단위로 반복해서 복사를 하도록 하면 어떻게 될까요? 우선 코드는 다음과 같이 변하겠네요.

shl 인스트럭션은 두개의 오퍼랜드를 가지며 (shl operand1 operand2) operand1 에 있는 값을 operand2 에 있는 값만큼 왼쪽으로 shift 를 시키게 됩니다. movsd 는 mov single dword[1] 라고 보시면 됩니다.
결과적으로 이렇게 코드를 수정함으로 인해 1초에 640MB 를 복사할 수 있게 됩니다. 3% 정도 성능 향상이 생기네요.
그런데 최근에 나온 프로세서들에서는 rep 같은 복잡한 인스트럭션을 내부적으로 RISC 명령으로 바꿔서 실행하다 보니, 그리 효율적이지 못하답니다. 그러므로 rep 를 사용하지 말고 반복문을 사용해보도록 합시다.

코드가 뭔가 좀 길어졌죠? 위 코드를 c로 표현하면 아래와 같습니다.

c로 표현하니 어디서 많이 쓰던 코드죠? 쨌든! 이렇게 하니 1초에 650MB 를 복사할수 있었고 결과적으로 1.5% 정도 성능이 향상되었답니다.
그럼 여기다가 Loop 코드를 최적화 하는 기법인 Loop Unrolling 을 적용해봅시다. [2]

자 룹을 펼쳤더니 1초에 640MB 를 복사하였고, 결과적으로 1.5% 만큼 성능이 떨어졌습니다. 하지만 다행히도 Loop Unrolling 을 적용하고 나니 최적화를 할 여지가 많아졌네요.
캐쉬를 좀 더 잘 활용할 수 있도록 코드 순서를 바꿔봅시다.

이젠 1초에 660MB 를 복사할 수 있게 되었고, 3% 만큼 성능 향상이 일어났습니다.
여기서 끝이 아닙니다. 첨에 movsb 대신 movd 를 사용해서 1byte씩이 아닌 4byte 씩 복사를 하는 방법을 통해 최적화를 진행했었는데요, MMX 를 사용할 경우 movq 등의 인스트럭션을 이용해서 한 번에 8byte 씩을 복사하는게 가능해집니다. 또한 mm0~7 이라는 특수한 레지스터를 활용할 수 있으니 8*8 = 64 즉 한번에 64byte 씩을 복사해봅시다.

MMX 용 레지스터들인 mm0~7 은 FPU stack 의 일부를 활용하게 되므로, 이 레지스터 값을 바꿔주게 될 경우 FPU 와 관련해서 문제를 일으킬 수 있습니다. EMMX 는 이를 방지하기 위해 사용해야 하는 인스트럭션이 되겠습니다. 하여튼 이렇게 바꾸니 1초에 705MB 를 복사할 수 있게 되었고, 7% 만큼 성능이 향상되었습니다.
이젠 movntq 라는 인스트럭션을 통해 cache 를 우회해서 writing 을 진행해봅시다.

movntq 를 활용한 다음에는 write buffer 를 비워주기 위해 sfence 를 사용해야 한다는군요. write 부분이 movq 에서 movntq 로 바뀌었고 emms 앞에 sfence 가 들어간 것을 제외하면 코드는 동일합니다. 하지만 성능 향상은 60% 로 굉장하네요. 1초에 1130MB 를 복사할 수 있었다고 합니다.
이젠 prefetch 도 활용해봅시다.

위 코드에는 현재 복사할 차례의 512 바이트를 미리 읽어두라는 의미의 prefetchnta 인스트럭션이 추가되었습니다. 한 번에 복사하는건 64Byte 인데 왜 512Byte 를 읽으라고 했는지 살짝 의문이네요. 제 생각에는 문서를 작성하신 분이 버그를 낸거라고 생각합니다.
하여튼 이젠 1초에 1240MB 를 복사할 수 있게 되었고, 10% 만큼 더 성능 향상이 생겼네요.
지금까지의 방법만으로도 꽤 많은 성능 향상이 있었지만, 한 번에 한 캐쉬 라인[3]만을 활용하고 있습니다. 하지만 실제 CPU 에는 훨씬 많은 캐쉬 라인이 존재하므로 이를 더 잘 활용할 수 있도록 코드를 수정해보겠습니다.

여기서는 cache 가 1024 개의 cache line 을 가지고 있다고 가정했네요. (16진수인 400h 는 10진수로 바꿀 경어 1024 가 됩니다.) 미리 캐쉬 사이즈만큼 prefetch 명령들을 내려놓은 뒤 값들을 복사하게 될 때 쯤이면 이미 값들이 캐쉬에 올라와있게 되니 딜레이를 줄일 수 있게 되겠습니다.
효과가 있을까 싶지만, 실제 1초에 1976MB 를 복사할 수 있었고, 59% 의 성능향상이 추가로 발생했습니다. 초기 코드에 비하면 300% 의 성능 향상이라네요. 신기하죠. 😉
전 상당히 흥미롭게 읽었었는데, (비슷한 걸 해본 경험도 있고 해서) 재밌었는지 모르겠네요. sfence 나 movqnta, prefetchnta 같은 캐쉬와 관련된 명령들은 정확히 무슨 용도인지 이해하지 못하고 있었는데 이 문서를 통해 이해할 수 있었던 것 같네요. 관심이 있으신 분은 아래 문서를 읽어보시면 되겠습니다. FPU 관련된 최적화도 다루고 있는데, 관심이 없어서 그 부분은 옮기질 않았습니다. 그럼 다들 즐거운 주말 보내시길 😉

Click to access AMD_block_prefetch_paper.pdf


[1] x86 호환 아키텍쳐에서는 사이즈를 byte, word, dword, qword, dqword 식으로 표현합니다. 이는 각각 1, 2, 4, 8, 16 바이트를 의미하며, word 가 2바이트이고 나머지의 앞에 붙은 알파벳들은 각각 double(*2), quad(*4), double quad(*8)를 나타내는 것이죠.
[2] Loop Unrolling 은 Loop 을 펼쳐서 파이프라인의 덕을 더 많이 볼 수 있도록 코드를 수정하는 방법입니다. 예를 들어


위와 같은 코드를

이렇게 바꿀 경우 branch 로 인한 pipeline hazard 도 줄일 수 있고, add instruction 도 1/4 만큼만 사용하게 됨으로 인해 성능이 향상될 여지가 많습니다.
[3] 메모리에 어떤 값을 읽어들일 때 CPU 에서는 바이트 단위로 값을 읽지 않고, block 단위로 값들을 cache 에 복사하는데, 이 block 의 크기를 cache line 이라고 표현합니다. 펜티엄 계열의 경우 대부분 64byte 입니다.

YUVPlayer 업데이트…

사실 저나 제 주위 사람들 말고는 쓰는 사람이 거의 없는거 같긴 하지만 하여튼 메모리 릭을 일으키는 몇 가지 버그를 잡았습니다.

  1. ::GetDC(hWnd) 후 ::ReleaseDC(hWnd,dc) 를 호출 하지 않아서 생기는 메모리 릭
  2. gdTexImage2D 를 반복 호출해서 생기게 되는 메모리 릭

정확하게 설명하면 위와 같구요. ::GetDC 로 받아온 Device Context 는 “꼭” ::ReleaseDC 를 호출해줘야 한다는 msdn 님의 가르침에 따라, 약간의 코드를 추가해줬습니다.
또한 gdTexImage2D 를 반복해서 호출하면 이전 텍스쳐 데이타가 사용하던 메모리 영역은 해제가 될 줄 알았는데, 실제로는 그렇지가 않네요. 텍스쳐 사이즈가 달라지는 경우엔 glDestroyTexture 후 glGenTexture, glBindTexture, glTexImage2D 를 차례로 호출해줘야 하고, 사이즈가 달라질 필요가 없는 경우라면 gdTexSubImage2D 를 사용하면 된답니다. 어려운 openGL 세상이에요.
자세한 수정 사항은 제 trac 페이지에서 확인하심 될 듯~
http://trac.unfix.net/browser/yuvplayer/win/yuvplayer/OpenGLView.cpp
p.s) trac 이 ajax 를 활용하도록 업데이트 되었네요.