사회적 웃음

웃음에는 두 가지가 있다고 하는데, 정말 즐겁고 재미있어서 행복해서 웃는 웃음과, 좋은 인간관계를 만들기 위한 사회적 웃음이 그 두 가지이다. 나이가 들어갈 수록 많은 인간관계를 형성하기 때문에 행복한 웃음보다는 사회적 웃음이 더 늘어나게 되기 마련이다.

웃는다는 건 상당한 에너지를 소모하는 것이라, 웃음다이어트라는 것도 있지만, 사회적 웃음은 정신 에너지 역시 소모하는지 더 많은 에너지가 소모되는 것이리라.

하루종일 사회적웃음을 짓고 오만 생각을 다 하다보니 머리가 너무 아프다. 피곤하기도 하고.

(생후 두 살이 되면 사회적웃음을 짓는다고 하니 어릴 때부터 어느 정도의 가식은 본능적으로 나타나는 것일게다... 그저, 항상 그렇지만은 않기를, 그런 것이 필요없는 행복한 인간관계가 하나라도 있기를 바라는 건 그저 욕심일뿐일까...

Fluxus...

플럭서스(Fluxus)는 1960년대의 전위적인 미술의 한 방향이었다. 그 시초는 리투아니아계 미국 미술가 George Maciunas가 사용한 플럭서스에서 유래한다. 그 흐름의 주요 참여자로는 백남준, 요셉 보이스, 존 케이지 등이 활약하였다. - from Wiki...

가 아니고...

크크섬의 비밀 OST때문에 알게 된 기획사 플럭서스. 홈페이지는
http://www.fluxusmusic.com/
음반기획사에 관심을 가지는 경우는 별로 없었는데 크크섬 덕분에 W를 검색하고 그러다보니 기획사 홈피까지...

소속가수들이 정말 괜찮은 듯.
러브홀릭, 이성열, 클래지콰이, W, My Aunt Mary, Winter play, 이바디, 알렉스 라니...
(홈피순서대로..)
다들 나름대로의 색깔을 가진 밴드나 가수들. 꽤나 매력적인 라인업이 아닌가...

서로 도와가면서 새로운 색깔의 음악을 만들어내는 것을 보니 앞으로의 활동도 기대되는 색깔있는 기획사인듯...

이바디 노래나 들어봐야겠다. 호란 보컬도 매력있으니... (점은 좀 떼주고 싶긴하다. ㅋ)

(다시한번 크크섬OST 강추드리옵니다. 구매후 후회없으실줄 아뢰오...)

이상한 여자 구별법

오늘도 어김없이 하릴없이 인터넷질을 하다가 흥미로운 글을 발견

너무 길기도 하고 퍼다 놓기도 뭐해서 링크만 건다. (스크롤 압박이 장난아님)

http://clien.career.co.kr/zboard/view.php?id=free&no=578369

읽다가 생각난 건... 이런 건 여자만의 문제가 아니라는 것. 발현의 양상이 다를 뿐, 남자들도 매우 자기 중심적이고 결여된 사람들이 많다. 너무도 자기중심적인 나머지 다른 사람들의 말을 들어도 들은 줄도 모르고 자기 얘기만 해야하는 사람들. 사회 생활도 잘 하는 것처럼 보이지만 주변과 심각한 문제를 안고 있는 사람들. 뭐.. 남자의 경우에는 변태로 발현하는 것 같지만...

아이쿠. 나도 조심해야지...

CUDA shared memory bank conflict

CUDA 프로그래밍의 필수적인 과정은 coalesced data access pattern을 확보하는 것인데, 방법은 여러가지지만 두 가지 정도의 방법이 많이 쓰이는 것 같다.

첫 번째 방법은, 데이터를 restructuring해서 global memory에 항상 coalesced access를 할 수 있도록 알고리즘과 맞추는 것이다. 이 방법은 애초에 데이터 연관성이 없는 대량의 데이터를 처리하고자 할 때 사용할 수 있는 방법이고, 이를 위해 알고리즘 구성시 동시에 메모리 구성을 잘 결정해야 한다. 당연한 말이겠지만, 이 방법으로는 메모리 구성을 나중에 바꾸기가 매우 번거롭기 때문에 애초에 신중히 디자인 해야 한다.

두 번째 방법은, 대부분의 CUDA 예제에서 채택하는 방법으로 shared memory를 버퍼로 두어 global memory access를 모두 shared memory를 통하여 하는 방법이다. 이 때는 알고리즘에 데이터 연관성이 있다 해도 빠르게 access 가능하므로 일반적으로 사용할 수 있다.

그런데 shared memory를 통해서 coalesced access를 확보하고 비교적 빠른 속도를 얻었지만, 프로파일링을 해보면 warp serialize가 많다는 warning이 뜨는 경우가 있다. 도대체 이게 뭔가 싶어 검색을 해 봐도 그리 속시원한 대답은 없고, 잘 디자인된 예제의 경우에는 warp serialize가 모두 0이기 때문에 비교도 안되고 답답하다. 그러다 오늘 programming guide를 다시 읽어보다 눈에 띈 것이 shared memory도 32bit 단위로 bank가 만들어져 있다는 것. 지금 하고 있는 작업이 8bit 단위의 데이터를 쓰기 때문에 block내의 옆 thread가 동일 bank에 접근하게 되고 이 때문에 충돌이 일어난 것이다. 이를 알려준 것이 warp serialize 경고.

한 thread에서 4개의 연속된 8bit에대해 연산을 하면 warp serialize는 완벽히 피할 수 있다. thread수가 1/4로 줄어버리긴 했지만, struct로 32bit 연산을 하는 thread라면 이런 문제는 잘 발생하지 않는다. (그래서 예제에서는 거의 발생하지 않는다. 거의가 float 연산이므로.)

그런데 문제는 지금 첫 번째와 두 번째 coalesced access pattern을 모두 사용하고 있다는 점. bank conflict를 피하려고 4개씩 묶어냈더니만, global memory coalescing이 깨져버린다. 당연히 bank conflict가 일어나더라도 global memory coalescing을 확보하는 것이 빠르다. 그렇지만 global memory를 재구성하면 피할 수 있지 않을까 싶은데... 그 짓까지 해야하나 하는 생각이 들어 관둬버렸다.

전부 두번째 방법으로 하면 되지 않을까 싶겠지만 지금도 너무 shared memory사용량이 많아서 thread수를 늘리기가 어렵다. shared memory를 펑펑쓰면 그만큼 concurrent thread수가 줄어드니까 성능이 그리 향상되지 않는다. 이것도 어찌보면 trade-off 관계.

더 짜증나는 건 GPU time은 아주 작은데 CPU time이 엄청 크다고 프로파일러가 얘기하는 것이다. 간단한 커널인데도 오버헤드가 큰 이유를 잘 모르겠다.

이래저래 모르는 게 너무 많다.

구글 크롬

구글에서 새로운 웹브라우저를 내놓으면서 웹시장에도 진출했다. 구글 제품이 늘 그렇듯이 깔끔한 디자인에 꽤나 빠른 속도를 자랑한다. 역시나 ActiveX 때문에 한국 웹사이트에서 문제가 발생한다는 보고가 많은 듯 하지만 일반적인 웹표준을 지키는 사이트에서는 별로 문제가 생기지 않는 듯.

하루 이틀 써보니까 꽤나 빠른게 마음에 들고, 구글에서 얘기하기로는 한 탭이 다운되어도 다른 탭에 영향이 없다는 것 같은데, 아직 죽은 적은 없어서 확인이 안된다. 빠른 건 자바스크립트엔진이 빨라서라는데, 그것보다는 사파리와 같은 렌더링 엔진을 쓰기 때문인 것 같다. 많은 사이트에서 크롬을 아직 사파리로 인식하고 있다.

시스템 리소스는 생각외로 꽤나 많이 쓰는 것 같다. 플래시처리에 문제가 있는지는 모르겠지만 한국 포탈 접속, 특히 다음 관련 사이트를 접속하면 CPU 점유를 무시하기 어려울 듯. 아마 하나에서 문제가 생겼을 때 다른 탭에 영향을 안 주려고 별도 프로세스로 돌리는 것 같은데, 덕분에 메모리나 리소스 관리는 윈도우가 다 하는 것 같다. 다음만 들어가면 30%잡아버리니... 조금은 문제일지도. 어짜피 요즘 리소스는 남아도는 경우가 많으니까 싶기도 하지만, 듀얼코어정도가 아니면 좀 문제가 되지 않을까 싶기도 하다.

특히나 눈에 띄는 건, 이 블로그를 그나마 최대한 맥에서 작업할 때와 비슷하게 렌더링하고 있다는 점. 어짜피 웹폰트를 쓰지 않는 이상에는 완전히 똑같이 띄워달라고 요구하기 어렵다는 건 알겠지만, 윈도에서 이 블로그를 보면 다 굴림체로 나와버려서 아주 보기가 싫다. 원래는 명조체인데.. (하긴 맥의 고딕은 못생기기로 악명높으니 명조로 안나왔으면 블로깅 하기 싫었겠네.) 익스플로러나 파이어폭스 모두에서 그리 나와 버렸으니 좌절이긴 했지만, 크롬에선 최대한 명조로 나와주고 레이아웃이 깨지지도 않았다는 것이 인상적이네. 약간 가는 글씨체로 나오긴 했지만, 내 컴퓨터에서만 그런 건지도 모르지.

넷스케이프 부터 시작해서, 익스플로러, 파이어폭스, 오페라, 웹마, 크롬까지 안깔아본 브라우저도 없는 듯 하고, 지금은 파이어폭스를 쓰고 있지만, 아마 윈도에선 크롬으로 바꾸게 되지 싶다. 한국에선 어쩔 수 없이 익스플로러 쓰는 일이 잦겠지만, 그냥 웹질에는 크롬의 빠른 반응 속도가 마음에 든다.

빨리 맥 버전도 나왔으면 좋겠네. 글구 맥용 피카사도 얼른 나오길...

(사진을 많이 찍는다면 구글 Picasa를 깔아보는 것도 좋을 듯. 정말 간편한 원클릭 뽀샵질과 어떻게 가능한지 모르겠을정도의 빠른 브라우징이 매력적. 그래서 맥용 피카사를 기다리는 사람이 많은 것 같다.)

논어 학이(學而)편에서

키즈에서 때아닌 인문학논쟁이 붙더니 결국은 고전강독까지 하기 시작했다.
철없이 지냈던 대학 새내기 시절, 그저 수업시간에 읽었던, 그리고 조금 관심이 생겨 찾아보았던 논어의 몇 구절이 떠도는 것을 보면서, 다시 한 번 읽어보게 된다.

다음은 논어 학이편의 몇 구절. 연결된 구절은 아니지만...

子曰 學而時習之 不亦說乎,
有朋 自遠方來 不亦樂乎,
人不知而不 不亦君子乎.

子曰 不患人之不己知 患不知人也

배우고 때로 익히면 또한 기쁘지 아니한가
벗이 먼 곳에서 찾아오면 또한 즐겁지 아니한가
남이 나를 알아주지 않아도 노여워 하지 않음이 또한 군자가 아니겠는가

남이 나를 알아주지 않음을 걱정하지 말고 내가 남을 알지 못함을 탓하라.

퍼온 해석이 어쩌면 조금은 서툰 해석일지도, 조금은 틀린 해석일지도 모르겠지만, 그 나름대로의 의미가 있다. 중학교때, 고등학교때, 대학교때, 그리고 지금 다시 읽을 때마다, 말 뜻은 같으나 느껴지는 것이 다르니 신기한 문장이다.

나만이 아니라 아마도 이 한 사람이 한 말이 수 천 년동안 읽히고 또 읽히면서 사람들에게 때로는 다른, 때로는 같은 의미로 받아들여지면서 감동을 주었으리라. 기술이 발전하고 사회가 변화했지만, 사람들의 삶의 원리는 그 때나 지금이나 그대로인지 모르겠다. 지금도 여기 누군가에게 읽히며 그대로의 생명력을 과시하듯 뿜어내는 말들인 것을 보면, 그래서 고전은 고전인가보다.

'배우고 익히는 것'과, '먼 곳에서 벗이 찾아오는 것'을 같이 늘어 놓을 수 있다는 것. 그러면서도 남이 나를 알아주지 않는 것보다 내가 남을 알지 못하는 것이 더 큰 문제라는 문제의식. (아마 공자는 자신을 알아주는 사람이 없다는 약간의 피해의식이 있었던 것 같긴 하지만...) 이러한 배움과 관계에 대한 의식적인 도전이 수천년 동안 지속되어왔고, 아마 앞으로도 그렇겠지. 단지 나에게만 주어진 문제는 아니었던 것이다. 그리고 아마, 앞으로도 명쾌히 해결될 문제는 아니겠지만 언제 어디서든 그 나름대로의 가치가 항상 있는 화두이니까.

고전의 향기는 그래서 씹을수록 더욱 퍼져나가는 신기한 약초와도 같은 가 보다. 아마 시간이 더 지나서 또 다른 경험을, 생각을 갖고 다시 씹었을 땐 또 다른 맛이 나겠지.

덧... 어줍잖은 후학의 조그만 생각을 덧붙여보자면, 내가 남을 알지 못하는 것보다 더 큰 문제는, 내가 나를 알지 못하는 것. 스스로 하고 있는 일이 얼마나 깊이가 없는 자신의 이익만을 위한 것임을, 때로는 자신의 이익조차도 아닌 무엇을 위한 일인지조차 알 수 없는 그저 남을 상처주는 것 뿐 다른 의미는 없는 일임을, 전혀 인식하지 못하는 것이다. 그런 사람이 너무도 많음을 보면서, 아니 어쩌면 나도 다를 바 없음을 인식하면서, 다시 한 번 고전을 곱씹어 본다.