CUDA에서는 적절한 thread의 갯수를 알아내기 위해 CUDA occupancy calculator라는 excel 파일을 제공한다. 이 파일은 작성한 kernel function이 해당 GPU에서 몇 thread가 동시에 구동되는가를 계산해주는 역할을 한다.
계산을 위해 kernel 함수의 정보를 알려주어야 하는데, 필요한 정보는 사용된 GPU, 블럭당 thread, thread당 레지스터의 갯수, 블럭당 필요한 공유메모리의 크기의 4가지이다. GPU는 고정되어 있을것이므로, 사용된 레지스터수와 공유메모리 크기를 넣으면 최대 몇 thread를 구동할 수 있는지에 대한 정보가 그래프로 표시된다. 또한 MP당 가용 쓰레드나 점유율등도 표시되는 좋은 도구이기도 하다. CUDA의 경우 thread가 한계 이상인 경우에는 전체적으로 구동하지 않고 아무 말없이 넘어가버리므로 thread 갯수를 찾는 것은 매우 중요하다.
결국 사용한 레지스터의 수와 공유메모리 크기를 알아야 하는데, 이는 컴파일러가 어떻게 바이너리 코드를 생성했는가에 달려있다. 이를 위해 CUDA의 컴파일러인 nvcc에서는 --ptxas-options=-v 라는 옵션을 주면 아래의 예와 같이 이들 정보를 준다.
1>ptxas info : Compiling entry function '_Z12copyResidualPfS_iii'
1>ptxas info : 0 bytes lmem, 36 bytes smem, 1242688 bytes cmem, 4 registers
1>ptxas info : Compiling entry function '_Z14threshold_CUDAPfS_iif'
1>ptxas info : 0 bytes lmem, 36 bytes smem, 1242688 bytes cmem, 5 registers
1>ptxas info : Compiling entry function '_Z24eval_cost_and_count_CUDAPfPiiif'
1>ptxas info : 0 bytes lmem, 36 bytes smem, 1242688 bytes cmem, 17 registers
1>ptxas info : Compiling entry function '_Z14eval_cost_CUDAPfii'
1>ptxas info : 0 bytes lmem, 28 bytes smem, 1242688 bytes cmem, 15 registers
이 예에서는 4개의 kernel 함수가 있으며 각각의 함수에서 사용한 지역, 공유, 상수 메모리와 레지스터의 수가 표시된다. (이 예에서는 한 cu파일에 모두 있으므로 상수메모리사용량이 동일)
Visual Studio 2005에서는 이를 얻는 설정을 custom build setting에서 해주어야 한다. --ptxas-options=-v 옵션을 custom build option에 있는 Command Line 항목 맨 뒤에 붙여주자.
(custom build setting은 Solution explorer에서 해당 project이름에 우클릭하면 나타난다.)
Thursday, June 26, 2008
VS2005에서 CUDA 컴파일러 옵션 설정
Monday, June 23, 2008
병렬구조로 쓰기
논문작성에 있어서, 독자를 편하게 해주어야 한다는 것은 앞의 두 포스트에서 계속 얘기하고 있다.
그럼 어떻게 해야 편하게 읽히는 논문을 쓸 수 있을지 생각해봐야 한다.
대부분의 non-native는 논문이 제대로 씌여지지 않는 이유를 부족한 표현과 영어의 문제로 생각하곤한다. 물론 미려한 영어를 구사하거나 정확한 단어를 선택하는 것이 논문을 이해하는 데에 있어 매우 도움이 되는 것이 사실이다. 그러나, 실제로 readability를 높이는데 가장 중요한 것은 논의의 논리구조(logic)이다.
논리적으로 연결되는 구조는 언어가 약간 미려하지 않다 하더라도 이해에 크게 문제가 없다. 논리적으로 잘 연결되는 논문은 독자가 '왜' 이렇게 되었는가에 대한 생각을 따로 하지 않더라도 이해할 수 있도록, (최소한 이해한다고 생각할 수 있도록) 구성되어있다. 비록 언어적인 문제가 있더라도 이 부분에서는 이런 말이겠거니 할 수 있을 정도로 구성되어있다면 이해에는 크게 문제가 없게 된다.
논리적으로 가장 쉽게 받아들여지는 구조는 '병렬구조(parallelism)'이다. 특히 유사성이나 차이에 대해서 설명해야 하는 경우에는 반드시 병렬구조를 사용한다. 병렬구조는 매우 논리적이며 '예측가능'하므로 readability를 늘린다.
병렬구조로 논의할 때는 특히 완전한 병렬 형태를 만드는 것이 좋다. 모든 병렬적인 내용에 대해서 동일한 순서로, 동일한 문장구성을 사용하는 것이 최선이다. 특히 주의해야 할 점은, 병렬 구조 속에서 같은 내용을 서로 다른 단어나 표현을 사용하여 기술하는 것이다. 이 경우, 완전한 병렬구조를 취하지 못하게 되므로 독자는 표현의 차이에 주의하게 되며, 이 때 논문에서 논하고자 하는 내용에 집중하지 못하게 된다. '동어반복'을 피하기 위해 일부러 다른 표현을 고르는 경우가 종종 있지만 이는 매우 좋지 못하다. 지금 작성하고 있는 것은 문학작품이 아니라 객관적이어야 할 기술 논문임을 상기하자. 특히 non-native의 경우 다른 표현을 통해서 오히려 의미를 흐리는 경우가 많으니 주의하자.
물론 동일한 단어를 필요 이상으로 반복하면 지루하게 되므로 피해야 하겠지만, 의미가 흐려지는 것보다는 반복해서 의미가 명확한 것이 낫다. 이는 대명사등을 사용할 때도 마찬가지이다. 완전히 동일한 문장 속에서 다른 것이 하나 있을때 가장 그 부분에 주의하게 된다.
영어가 약할 수록 더 논리에 주의해야 한다. 이 때 가장 단순하면서도 강력한 방법이 병렬구조임을 명심하자.
블로그 Element 추가
그냥 생각나는 대로 포스팅하다보니, 어느새 글 수가 100개를 넘어버려서 나도 관리가 안되기 시작했다. 다른 블로그에선 카테고리에 따라 글 목록을 관리할 수가 있었던 것 같은데, 구글블로그에는 카테고리 기능이 없으므로 관리가 조금 더 어려운 듯 보인다.
구글 블로그에는 구글의 다른 제품들과 마찬가지로 카테고리 대신 레이블을 붙여서 관리하는데, 한 게시물의 여러가지 특성을 나타내며 다채롭게 인덱싱할 수 있다는 점은 매우 좋지만, 레이블당 글목록을 만들어내는 방법이 마땅치 않다. 그것 때문에, Hoctro블로그에서 만들었던 자바스크립트 기반의 Related Post를 넣어 사용하고 있긴 한데, 이게 원래 Recent post에서 시작된 것이어서인지, 자바스크립트의 문제인지 최근 25개의 게시물만을 인덱싱해주고 있다.
완전히 자동으로 해주진 못하더라도, 이전의 게시물을 비교적 빠르게 찾을 방법이 필요했다.
새로 추가한 것은 'Today's choices', 'Featured Labels', '게시물의 전체 리스트'의 세 가지이다.
1) Today's choices: 이것은 이전 게시물 중 10개를 골라, 빨리 접근할 수 있는 링크를 제공하는 것으로, 완전 수작업으로 만든다. (완전 수작업이라야, 그저 copy & paste이지만)
위 그림과 같이 이 기능은 단순히 링크 기능을 이용하여 만들고, 다시 수정하기 전까지는 그대로 유지된다. 블로그는 게시물이 시간 순서로 나열되므로 중요도에 따른 편집권이 없지만, 이와 같은 기능을 통해 약간의 편집권을 누리게 된다.
제목은 '오늘의 선택'이지만, 어지간해서 매일 편집하기는 어렵겠지.
(6월25일 수정)
다시 생각해보니 굳이 수작업으로 해야 할 필요가 없을 것 같았다. 그저 Today's Choice라는 Label을 하나 만들고 아래의 Featured Label을 구현하듯 Feed2js로 목록을 자동으로 생성하는 것이 더욱 간단하다. 이렇게 하면 Labeling을 바꾸어주는 것 만으로 간단히 골라낼 수 있다. 물론 rss feed가 빨리 update되지 않는 경우가 있으므로, 시간이 조금 더 걸리긴 하겠지만 간단히 고를 수 있고, 골라낸 게시물만 들어간 페이지도 쉽게 생성할 수 있으므로 더 좋은 방법이라 생각된다.
2) Featured Labels: 이것은 레이블에 연결된 게시물 리스트를 보여주는 기능이다. 
윗 그림에서 볼 수 있는 바와 같이 몇 개의 레이블을 정해서 그 해당하는 레이블이 달린 게시물을 나열한다. 레이블과 게시물이 많아지면 너무 길어져서 인덱싱이 오히려 안되므로 접었다 폈다 할 수 있는 기능을 넣는다. (이것에 대해서는 이전 게시물에 있고...)
동일한 레이블을 갖는 게시물리스트는 rss feed를 이용한다. 예를 들어 '가요'의 레이블에 대한 rss feed는
http://eaglface.blogspot.com/feeds/posts/default/-/%EA%B0%80%EC%9A%94
이다. 한글 레이블이므로 뒤에 붙는 레이블명이 그냥 영어 단어가 아님에 주의하자. (UTF-8 code인가?) 일단 rss feed를 얻은 후에는, feed2js 홈페이지에서 자동 feeding을 위한 자바스크립트를 생성한다.
이 때 기본적으로 25개를 최대로 주는 문제가 다시 발생하는데, 이는 rss feed를 줄때 ?max-results=1000을 뒤에 붙여주어 최대 1000개의 feed를 발생시키는 식으로 해결한다. 즉 결과 rss feed는
http://eaglface.blogspot.com/feeds/posts/default/-/%EA%B0%80%EC%9A%94?max-results=1000
의 형태가 된다. 이제 이를 접을 수 있는 페이지에 넣어서 만들면 끝.
레이블 맵을 자동으로 생성해서 만들지 않으므로 조금 손이 가지만, 오히려 너무 많은 레이블을 다 다루려면 페이지 로딩시간이 더 오래 걸릴 것이므로 손이 좀 가는 편이 나을 듯.
3) 게시물 전체 리스트
이는 앞에서 했던 것보다 더 간단하다. 전체 블로그의 rss feed를 넣어 자바스크립트를 만들어 내고 이를 게시한 후, 만들어진 페이지를 링크하면 된다. 역시 max-result를 충분히 많이 주어서 전체 리스팅이 나오도록 한다.
게시 시간순으로 정렬되므로 그리 효율적인 방법은 아닌것 같지만, 그래도 찾아볼 수는 있을테니 나름대로 유용할 수 있을 것 같다.
한 가지 주의할 점은, 이미 게시물이 많은 상태에서 이 게시물을 올리면 오늘 날짜로 만들어져서 중간에 생뚱맞게 매우 긴 post가 생긴다는 점이다. 이것은 게시직전에 post options에서 게시날짜를 첫 게시물이 게시된 날짜보다 과거로 설정하여 1번 게시물이 되게함으로써 간단히 피할 수 있다.
사실 다들 간단한 것이긴 한데, 차후에 템플릿을 바꾸게 되면 다시 해야 할 지 모르므로 포스팅해둔다.
Sunday, June 22, 2008
Billy Joel - Just the way you are
세상은, 사람은 변하지 않을 것 같지만 계속 변한다. 겉이든 속이든.
물론 아쉽게도 바뀌지 않는 것도 있지만...
그게 두려워서, 아니, 바뀌지 않을 것을 알기에, 그런 걸 보여주기가 두려워서
그래서였을까...
사랑을 하면 변하는 게 사람이지만, 항상 좋게만 변하는 것도 아닌 것 같아.
'당신 모습 그대로를 사랑하는 것', 어떻게 바뀌더라도, 그냥 그렇게...
그렇게 했을 것 같은데, 왜 물러서기만 했을까...
하지만... 그것도 나...