'전체 글'에 해당되는 글 215건

  1. 2009.09.24 loop 의 비용 3
  2. 2009.08.25 속 나츠메 우인장 (続夏目友人帳) 1
  3. 2009.08.17 그리스인 조르바 / 니코스 카잔차키스, 이윤기 역
  4. 2009.08.13 냄새나는 한국의 인종차별 3
  5. 2009.08.04 네x버 광고가 보기 싫어욧! 8
  6. 2009.07.29 vim - temporary highlighting 1
  7. 2009.07.28 일본 드라마 비망록 (+추천) 2
  8. 2009.07.28 vim - power of :g 5

loop 의 비용

Computing 2009. 9. 24. 14:25

아래와 같은 두 개의 프로그램이 있다. 어느쪽이 더 빠를까?


물론 source 2 가 빠르다.


이처럼 당연한 것을 가지고 질문을 하는 데에는 이유가 있다.

source 2 로 만든 코드보다 source 1 으로 만든 코드가 훨씬 읽기 쉬운 코드라고 가정하자. 그럴 경우 아래와 같은 취사 선택의 문제가 발생한다 :

source 1 으로 얻을 수 있는 코드의 가독성을 위해서 source 2 로 얻을 수 있는 성능을 희생할 것인가,
아니면 source 1 으로 얻을 수 있는 코드의 가독성을 희생해서라도 source 2 의 성능을 선택할 것인가?

물론 경우에 따라 해야만 하는 선택이 다르다. 그래서 각각의 경우 어떤 선택을 하는 것이 최선일지 판단하기 위해 다음과 같은 실험을 해 보았다:

우선 소스 코드를 리스팅하자.

물론 clee 님의 포스팅에 나온 소스도 가능하겠지만, 그 소스의 경우, 컴파일러가 루프 안의 내용을 최적화해버리는 데다가, 메모리 접근이 거의 전혀 없는, 오로지 register 에서만 루프 안의 동작이 발생하므로 위의 source 2 처럼 만드는 것이 훨씬 더 빠르며, 그같은 경우에는 당연히 source 2 처럼 프로그램을 만들어야 한다. clee 님이 테스트에 사용한 소스를 이용해 테스트를 하면 source 2 처럼 만드는 것이 두 배 가량 빠른데, 당연한 결과이다. 컴파일러의 최적화 등으로 인해 루프를 도는 비용이 프로그램 실행 전체 비용의 대부분을 차지하게 되어 버렸기 때문에, 루프를 두 번 돌면 당연히 두 배의 비용이 들게 된다.

그러나 나는 보다 일반적인 경우를 테스트하고자 하였기 때문에 루프 안에서 inline 시킬 수 없는 다른 object file 에 있는 함수를 호출하도록 하였다. 그리고, 소스를 약간 다듬다 보니,, Makefile 과, command line argunemt 까지 받도록 하는 프로그램이 되어 버렸는데... (직업병이다 -_-) 아무튼, 보다 일반적인 경우를 테스트하고자 하는 의도로 위에서처럼 복잡한(!) 테스트코드를 만들었다.

어디, 그럼 실험 결과를 체크해 보자 :

shawn.ygdrasil:~/work/loop$ make all
gcc -c -o a.o a.c
gcc -c -o loop.o loop.c
gcc -o a a.o loop.o
gcc -c -o b.o b.c
gcc -o b b.o loop.o
shawn.ygdrasil:~/work/loop$ time ./a > /dev/null

real    7m42.794s
user    7m34.228s
sys    0m2.209s
shawn.ygdrasil:~/work/loop$ time ./b > /dev/null

real    7m44.419s
user    7m34.048s
sys    0m2.304s

shawn.ygdrasil:~/work/loop$ time ./a --noio

real    0m10.286s
user    0m9.625s
sys    0m0.032s
shawn.ygdrasil:~/work/loop$ time ./b --noio

real    0m8.734s
user    0m8.259s
sys    0m0.026s

어라... 이것 참... io 를 사용한 경우에는 두 개의 루프를 사용한 a 가 더 좋은 성능을 보였다 -0-
물론, io 를 사용하지 않은 경우에는 예상한 대로 루프를 하나만 사용한 b 가 더 좋은 성능을 보였다.
이거.. 뭔가 잘못되었나 ... 다시 한번.

shawn.ygdrasil:~/work/loop$ time ./a > /dev/null

real    7m42.785s
user    7m34.448s
sys    0m2.473s
shawn.ygdrasil:~/work/loop$ time ./b > /dev/null

real    7m42.235s
user    7m33.867s
sys    0m2.430s

비슷한 결과치가 나왔다. 역시 io 가 들어가니 정확한 측정은 힘든 모양이다.
그래서 수회 같은 실험을 반복했지만, a 나 b 가 별반 차이 없이 비슷한 시간이 걸린 것으로 측정되었다.

--noio 옵션을 주었을 경우에는 평균적으로 b 가 1.5초 정도 빠른 성능을 보였다.

여기서 얻을 수 있는 결론은, (당연하겠지만) 루프 안에서 실행하는 루틴에 소요되는 시간이 루프 그 자체를 도는 시간 보다 훨씬 큰 경우라면, source 1 처럼 루프를 나누어서 여러번 돌게 해도 별반 차이가 없으며, 루프 자체를 도는 비용과 루프 안에서 실행되는 루틴의 비용이 큰 차이가 나지 않는 경우라면 source 2 처럼 루프를 한번만 돌게 하는 것이 더 좋다는 결론이다.

특히, 위의 분홍색 실험 결과처럼 중간에 io 가 끼어 있는 경우라면 루프를 나누든지 하나로 하든지 아무런 차이를 느끼지 못하는 결과를 얻을 수 있다.

좀 더 정량적으로 각 함수가 사용한 시간을 알아 보기 위해서 gprof 로 분석을 해 보았다. gprof 를 쓰기 위해서는 gcc 에 -pg 옵션만 추가해 주면 된다.

먼저, noio 옵션으로 실행시킨 결과이다 :

./a --noio 의 결과

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total          
 time   seconds   seconds    calls  ns/call  ns/call  name   
 42.05      3.88     3.88 1000000000     3.88     3.88  loop1_noio
 39.21      7.49     3.62 1000000000     3.62     3.62  loop2_noio
 17.61      9.12     1.62                             main
  1.97      9.30     0.18                             loop2_io
  0.00      9.30     0.00        1     0.00     0.00  process_arg

granularity: each sample hit covers 2 byte(s) for 0.11% of 9.30 seconds
index % time    self  children    called     name
                                                 <spontaneous>
[1]     98.0    1.62    7.49                 main [1]
                3.88    0.00 1000000000/1000000000     loop1_noio [2]
                3.62    0.00 1000000000/1000000000     loop2_noio [3]
                0.00    0.00       1/1           process_arg [5]
-----------------------------------------------
                3.88    0.00 1000000000/1000000000     main [1]
[2]     41.7    3.88    0.00 1000000000         loop1_noio [2]
-----------------------------------------------
                3.62    0.00 1000000000/1000000000     main [1]
[3]     38.9    3.62    0.00 1000000000         loop2_noio [3]
-----------------------------------------------
                                                 <spontaneous>
[4]      2.0    0.18    0.00                 loop2_io [4]
-----------------------------------------------
                0.00    0.00       1/1           main [1]
[5]      0.0    0.00    0.00       1         process_arg [5]
-----------------------------------------------
20억번의 loop 에 소요된 시간은 1.62초였다. main 함수의 다른 부분은 무시해도 좋다.
전체 수행 시간에서 순수하게 loop 를 돌기위해 소요된 시간은 17.61%

./b --noio 의 결과

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total          
 time   seconds   seconds    calls  ns/call  ns/call  name   
 46.30      4.07     4.07 1000000000     4.07     4.07  loop1_noio
 38.89      7.48     3.41 1000000000     3.41     3.41  loop2_noio
 11.60      8.50     1.02                             main
  3.22      8.78     0.28                             loop2_io
  0.00      8.78     0.00        1     0.00     0.00  process_arg

granularity: each sample hit covers 2 byte(s) for 0.11% of 8.78 seconds
index % time    self  children    called     name
                                                 <spontaneous>
[1]     96.8    1.02    7.48                 main [1]
                4.07    0.00 1000000000/1000000000     loop1_noio [2]
                3.41    0.00 1000000000/1000000000     loop2_noio [3]
                0.00    0.00       1/1           process_arg [5]
-----------------------------------------------
                4.07    0.00 1000000000/1000000000     main [1]
[2]     46.3    4.07    0.00 1000000000         loop1_noio [2]
-----------------------------------------------
                3.41    0.00 1000000000/1000000000     main [1]
[3]     38.9    3.41    0.00 1000000000         loop2_noio [3]
-----------------------------------------------
                                                 <spontaneous>
[4]      3.2    0.28    0.00                 loop2_io [4]
-----------------------------------------------
                0.00    0.00       1/1           main [1]
[5]      0.0    0.00    0.00       1         process_arg [5]
-----------------------------------------------
10억회의 loop 에 소요된 시간은 1.02 초였다. main 함수의 다른 부분은 무시해도 좋다.
전체 수행 시간에서 순수하게 loop 를 돌기위해 소요된 시간은 11.60%

루프를 두번 도는 것과 한번 도는 것의 차이는 전체 수행시간에서 불과 6% 밖에 나지 않는다. 그것도 10억번씩이나 돌린 루프인데 말이다. 게다가, 루프 안에서 실행되는 함수 또한 정말 간단한 일을 수행한다. 그런데도 각 함수(loop1_noio, loop2_noio) 의 총 수행 시간이 main 의 수행시간보다 큰 것은 오히려 함수 호출 비용이 함수 본체를 수행하는 비용보다 더 컸기 때문이 아닌가 하는 생각이 든다.

제일 처음에 제기했던 아래의 취사 선택 문제에서 :

source 1 으로 얻을 수 있는 코드의 가독성을 위해서 source 2 로 얻을 수 있는 성능을 희생할 것인가,
아니면 source 1 으로 얻을 수 있는 코드의 가독성을 희생해서라도 source 2 의 성능을 선택할 것인가?

대부분의 경우 전자를 선택하는 것이 합리적인 선택이라는 결론에 다다를 수 있다.

다시 한번 결론을 확인하면, 루프 안에서 함수 호출 없이 모든 계산이 이루어지는 루프는 당연히 한번만 루프를 돌도록 프로그램을 만들어야 하겠으나, 일반적으로 프로그램을 만들 때에는 루프 안에서 꽤나 많은 함수 호출이 있게 된다. 그럴 경우 만약 로프를 "단계별로" 두번, 세번 돌게끔 프로그램을 작성하는 편이 코드의 가독성이 좋다면, 루프를 한번만 돌게끔 해서 얻는 눈꼽만큼의 (정말 눈꼽만큼이다!!!) 성능 이득은 과감히 버리는 편이 합리적인 선택이라는 것이다.


여태껏 나는 당연히 루프를 두 번 돌면 비효율적일 것이라는 선입견을 가지고 깊이 생각해 보지도 않은 채 후자처럼 (source 2 초럼) 프로그램을 만들어 왔다. 그런데, 엊그제 문득 위와 같은 생각이 들어서 실제로 테스트를 해 보니 내가 생각한 바와 같이 루프를 두 번 도는 것이 비효율적이긴 하나 그렇게 비효율적이지도 않다는 결론이 나왔다. 나름대로 고정관념이나 선입견을 잘 피해 간다고 자신하고 있었지만, 전혀 그렇지 않았다는 사실을 깨닫고는 충격을 받았다.

:

속 나츠메 우인장 (続夏目友人帳)

아니메, 드라마 2009. 8. 25. 13:51

나츠메 우인장(夏目友人帳)은 정말로 훌륭한 TVA(TV Anime)이다.
포스트에서 언급했듯이, 쓸쓸함(寂しさ), 외로움, 그리움(懐かしさ)등과 같은 인간의 각종 감정을 매우 효과적으로 잘 묘사했기 때문이다. 또한, TV 아니메가 필수적으로 가져야 하는 요소인 "재미" 또한 빼놓지 않고 지니고 있다.
게다가 전체 분위기에 딱 어울리는 음악과, 끝까지 무너지지 않고 일정 수준 이상으로 유지되는 작화의 질까지, (이정도면 최상급 작화에 속한다) 훌륭한 애니메이션이 가지고 있어야 할 요소를 아주 잘 갖추고 있다.

2009년에 그 속편이 제작되었지만, 한번에 몰아서 보는 내 시청 습관상 묵혀 두었다가 지난주에 시청을 하였다.

물론 이번에 제작된 속 나츠메 우인장(続夏目友人帳:ぞくなつめゆうじんちょう)도 매우 훌륭한 아니메임에 틀림없으나 시청하는 내내 약간 아쉬웠었다. 내가 이 아니메에서 가장 훌륭하다고 생각했던 그 분위기가 부족했 때문이다.

전편(이하 1기로 지칭)에서 스토리들의 중심을 이루고, 시청자의 감정을 끌어내는 역할을 요괴(あやかし) 하나하나의 이야기(사연)가 주로 맡아서 수행했다. 그렇지만, 이번 속편에서는 등장하는 요괴 하나하나에 대한 이야기가 모자랐다.  따라서 시청자가 이야기의 등장인물에 감정이입을 할 수 있는 기회가 부족하게 되었고, 결과적으로 1기에서 보여 주었던 찡한 감동(이런 단어 쓰기 매우 간지럽다-_-)에 비하면 맹맹한 아니메가 되어 버렸다.

다르게 생각해 보면, 이같은 내용의 변경 아닌 변경이 불가피할 수 밖에 없다. 2기에는 1기에 비해 나츠메의 주변인물들이 많이 등장하고 극중에서 보다 큰 비중을 차지한다. 즉, 나츠메 <--> 요괴 로만 형성되어 있던 관계의 너비가 인간 <--> 나츠메 <--> 요괴 의 형태로 확장되었다. 따라서 요괴 하나하나의 사연은 부족해질 수 밖에 없지 않았을까.

그럼에도 불구하고, 이만한 퀄리티의 아니메를 보는 것은 흔한 일이 아니다.

수작으로 평해도 되겠다.

단, 엔딩송의 포스는 1기의 것과 비교해서 손색이 없을 정도로 훌륭하다.
다만, 이야기에서 이어지는 감정이 부족한 관계로 그 포스가 제대로 역할을 해 내지 못한다는 것도 꽤나 아쉽다.


엔딩송 : 愛してる (아이시떼루 -_-)
노래 : 高鈴(こうりんー코우링)[각주:1]


ねえ もう少しだけ
もう少しだけ聞いていてほしい

ねえ もう少しだけ
もう少しだけ わがままいいですか

手に入れた途端に 消えてしまいそう
言葉をくれませんか

あなたがいる それだけでも
世界が変わってしまう

モノトーンの景色が
ほら鮮やかに映る

いつの間にか離れていた
手をつないで歩いてく

うまく愛しているかなぁ
あの空に聞いてみるの


愛してる전곡




----

  1. 1998년 결성된 일본 어쿠스틱유닛(unit - 우리나라의 '그룹'). 2003년 소니레코드에서 메이져 데뷔. [본문으로]
:

그리스인 조르바 / 니코스 카잔차키스, 이윤기 역

Books 2009. 8. 17. 23:15

"여행하시오?"
그가 물었다.
나는 고개를 끄덕였다.
"어디로? 하느님의 섭리만 믿고 가시오?"
"크레타로 가는 길입니다. 왜 묻습니까?"
"날 데려가시겠소?"


지나칠만큼 감정에 솔직하다.
흥이나면 춤을 추고 노래를 부르고.
동하는 대로 즉각즉각 움직인다.
이것저것 재어 보기 보다 일단 부딪히고 본다.


이러한 삶은 이미 서른을 훌쩍 넘은 나에게는 역시나 분에 넘치는 인생인 듯 하다.
행동하지 않아서 그런 것인가?

언제쯤에나 흥에 겨워 내 산투리를 꺼내서 연주할 수 있을까.


:

냄새나는 한국의 인종차별

잡동사니 2009. 8. 13. 23:11
:

네x버 광고가 보기 싫어욧!

Computing 2009. 8. 4. 23:48

일본어를 배우고 있다.
그러다 보니 네*버 일어사전에 들어갈 때가 많고, 한번 들어가면 사전 창은 그대로 켜 둔 채로 컴퓨팅을 한다.
그런데, 때때로자주 사전 페이지의 오른쪽에 난삽한 플래쉬 애니메이션 광고가 뜬다. 그러면 CPU 사용량이 껑충 뛰어 오른다.
'아니, 내 허락도 없이 전력과 리소스를 잡아먹는 이런 악성 바이러스 같은!!!'
(( 사실, 그 광고 때문에 네이*의 서비스를 이용할 수 있는 것이지만, 짜증나는 것은 짜증나는 것이다.



그래서, 약간의 꽁수를 생각해 보았다.

웹페이지 소스를 보면, 저 광고는 ad.naver.com 으로부터 전송되어 온다.
그렇다면.... 그 주소를 아예 막아버리자. /etc/hosts 파일의 마지막에 한줄만 추가하자.

$ cat /etc/hosts
.
.
.
127.0.0.1 ad.naver.com

이제 다시 접속해 보면,


그림에서 보듯이, not found 가 나온다.

나는 내 PC 에서 웹 서버를 돌리기 때문에 저렇게 나오는 것이고, 웹서버를 안돌리는 사람이라면... 어떻게 나올까.. 아무튼 리소스 잡아먹는 플래쉬 광고는 안나올 것임에 틀림없다.

그럼, 네이놈 메인은 어떨까?
양심상 메인의 광고는 좀 봐 줘야 한다고 생각하지만,,,

네이* 메인의 광고는 서버 이름이 nv1.ad.naver.com nv2.ad.naver.com 등으로 되어 있는 것으로 봐서 아마 서버 이름이 주기적으로 바뀌지 않을까 하고 짐작이 된다.

물론, /etc/hosts 에 그냥 저 이름들을 넣어 두었다가, 매번 서버 이름이 바뀔 때마다 /etc/hosts 를 갱신해 주는 방법도 있지만, 이것은 왠지 아름다운 모습이 아닌 것 같다. 굳이 어떻게 해서라도 플래쉬 광고를 차단하겠다면, named 를 설치해서 운용하면 되지만, 그러면, 닭잡는데 소잡는 칼을 쓰는 격이니, *이버 혹은 다른 포탈사이트의 수익을 위해서라도 (무료로 서비스를 제공받고 있으니) 그정도는 참고 가도록 하자.

not found 라는 문구가 거슬리는 사람은 웹서버를 돌리고, 저 페이지(/adshow) 를 만들어서 빈 페이지로 해 두면 된다.


하아... 이제야 리소스 신경쓰느라 단어 하나 찾고 사전 창 닫는 삽질을 하지 않고 찾은 단어 페이지를 그냥 그대로 내버려 둔 채 살 수 있겠군!


주의!!! 이 글은 퍼 나르지 말아 주세요, 이런식으로 광고 차단하는 사람이 많아지면, 네이놈측에서 뭔가 수를 써서 이런 식으로 피해 가는 꽁수를 못쓰게 할 수도 있으니...

:

vim - temporary highlighting

Computing/vim tips 2009. 7. 29. 20:27

아주 큰 로그 파일 등을 꼼꼼히 분석하거나 할 때 가끔 이런 생각을 했었다 :
'이 단어만 잠시 하일라이트 시켜 두면 훨씬 보기 편할텐데'

예를 들어, 다음 그림과 같은 로그파일이 있다고 가정하자 :


그냥 이걸 편집기로 열어서 보면 위 그림에서 보다시피 너무 난삽해서 어디서부터 어디까지가 하나인지 구분하기 너무 힘들다.
이럴 때, 각 시작부분을 다음처럼 하일라이트 해 둘 수 있다면 한결 읽기가 수월해질 것이다 :


그런데 이것을 하느라 color scheme 지정해 주고, match 실행시켜주고 하기는 왠지 번거롭고 귀찮다.

그래서 스크립트를 하나 만들어 보았다 :


스크립트에서 해 둔 키 매핑을 기준으로 사용법을 설명하겠다.

shift-F10 을 누르면 아래에 위쪽 그림에서 보듯이 Keyword to highlight: 라는 프롬프트가 뜨고 현재 커서가 위치해 있는 부분의 단어가 출력된다. 이 상태에서 엔터를 눌러 주면 해당 단어가 위 그림에서 보듯이 하일라이트 된다.

ctrl-F10 을 누르면 하일라이트 되었던 것이 해제되어 원래 상태로 돌아간다.


색상은 세 가지로 만들어 두었다.

마음에 드는 색상으로 수정해서 쓰면 되겠다.

스크립트에서는 세가지 색상만 있는데, 더 많이 필요하다면 알아서 추가하면 되겠다.

키는 F10, F11, F12 에 각각의 색을 매핑해 놓았다.
즉, shift-F10/11/12 는 하일라이트, ctrl-F10/11/12 는 하일라이트 해제.


vim 이 실행될 때마다 항상 저 기능을 사용하고 싶으면, ~/.vim/plugin 에 적당한 이름으로 파일을 하나 만들고 위에 리스팅된 내용을 복사해 넣으면 된다.


나름대로 유용하게 쓰일 것 같다. 이히히..
(( 일하다 말고 엉뚱한데로 빠져서 두시간 가량 소비한 것 같네 -_-^
(( 정말 일 안된다 오늘...;;;


:

일본 드라마 비망록 (+추천)

아니메, 드라마 2009. 7. 28. 23:33

일본 애니메이션 비망록과 마찬가지로 잊어버리지 않기 위한 목적으로 만든 비망록이다.

분홍색 바탕 : 매우 강하게 추천
"재미없다" 거나 "보다가 중단했다" 는 등의 말이 없는 한 모두 일정 수준 이상으로 재미있었던 드라마들임.


  1. 프라이드(プライド)- 2004년 9월쯤 감상
    김탁구(木村拓哉)
    다케우치 유코(竹内結子)
    Queen 의 음악이 압권이다. "I was born to love you ~ every single beat of my heart ~"

  2. 런치의 여왕(ランチの女王)- 2005년 4월쯤 감상
    다케우치 유코(竹内結子)
    ”涙とともに食べた人でなければ、人生の味はわからない”

  3. 사랑따윈 필요없어. 여름(愛なんていらねえよ、夏)- 2004년 9월쯤 감상
    와타베 아츠로(渡部篤郎)
    히로스에 료코(広末涼子)

  4. HERO - 2009년 6월 감상
    키무라 타쿠야(木村拓哉)
    마츠 타카코(松たか子)
    아베 히로시(阿部寛)
    김탁구씨의 클리셰의 전형이지만, 그래도 그 맛에 그가 출연하는 드라마를 보는 것이니...

  5. 결혼 못하는 남자(結婚できない男)- 2009년 6월 감상
    아베 히로시(阿部寛)
    아베 히로시의 표정 연기는 압권이었다. 정말 맛있게 스테이크를 먹는다.
    아기자기한 재미가 가득한 드라마.
    우리나라의 리메이크판은 역시나... 뒷 부분으로 갈 수록 뒷심이 부족...;

  6. 미녀, 혹은 야수(美女か野獣)- 2009년 7월 감상
    마츠시마 나나코(松嶋菜々子)
    후쿠야마 마사하루(福山雅治)
    이 드라마 때문에 마츠시마 나나코에 홀딱 빠졌다. 남우주연인 후쿠야마 마사하루도 괜찮은 느낌.

  7. 야마토 나데시코(やまとなでしこ)- 2009년 7월 감상
    마츠시마 나나코(松嶋菜々子)
    이미 마츠시마 나나코 이외의 출연진에는 눈도 안가는 상태.
    상당히 재미있다.
    우리나라 리메이크인 "요조숙녀" 의 김희선양과 정말 비교됨.

  8. GTO - 2009년 7월 감상
    마츠시마 나나코(松嶋菜々子)
    소리마치 타카시(反町隆史)
    마츠시마때문에 보기 시작했지만, 역시, 주연배우인 소리마치도 괜찮았다.
    조~~ㅎ겠다. 마츠시마같은 부인을 얻어서....;;;

  9. 꽃보다 남자(花より男)- 2009년 7월 감상
    솔직히, 마츠시마가 나온다고 해서 보기 시작했다. 그러나,,, 정말 잠시 잠시 얼굴을 비출 뿐....;
    초반의 짜증의 도가니탕을 참고 이겨내어야만 하는 어려운 드라마이다.
    츠쿠시역의 여주인공이 마음에 들어 참고 끝까지 볼 수 있었다.

  10. 공명의 갈림길(功名が辻)- 2009년 4월 감상
    여주인공 치요역의 나카마 유키에는 별로였지만, 드라마는 좋았다. NHK 대하드라마.
    코링역으로 나온 나가사와 마사미(長沢まさみ +_+)가 매우 예뻤다.
    노부나가역으로 나온 타치 히로시(舘ひろし)의 카리스마가 압권.
    그 외 토요토미 히데요시나 도쿠가와 이에야스역의 다른 배우들 또한 매우 좋은 연기를 보여 줌.
    기모노가 참으로 예쁘다는 인상을 받았음.

  11. 아빠와 딸의 7일간 (パパとムスメの7日間)- 2009년 6월 감상
    아라가키 유이(新垣優位)
    타치 히로시(舘ひろし)- 노부나가의 그 카리스마는 어디로 가고... ㅠ_ㅠ)) 이런 짓을...ㅋㅋ;;;
    깔끔하고, 가볍고, 재미있게 볼 수 있는 드라마.

  12. 프로포즈 대작전(プロポーズ大作戦)- 2009년 6월 감상
    나가사와 마사미(長沢まさみ)- 어디서 많이 봤더라 하는 느낌이 들었는데, 아니나 다를까, 공명의 갈림길에서 코링역으로 나왔다.
    중간 부분이 꽤 질질 끄는 데다가, 남자 주인공의 우유부단함이 큰 마이너스 요인이지만, 보는 당시에는 벌겋게 충혈된 눈을 하고서 밤을 새어서 봤다.

  13. 오센(おせん)- 2009년 6월 감상
    아오이 유우(蒼井優)
    평면적인 전개. 편안하게 볼 수 있는 드라마이다.
    몽롱한 아오이 유우의 모습이 가장 기억에 남는 드라마.

  14. 파견의 품격(ハケンの品格)- 2009년 6월 감상
    시노하라 료코(篠原涼子)
    ”なにか” 라는 대사가 정말 잘 어울리는 여주인공이 나온다.
    이거 보고 잠시 정시 출퇴근을 했을 정도...;
    철의 여성같던 여주인공이 아나운서를 하면서 180도 다른 목소리로 “いかがですか〜” 하는 순간 터져나오는 웃음을 참는 일은 매우 힘들다.

  15. 하얀 봄(白い春)- 2009년 7월 감상
    아베 히로시(阿部寛)주연의 두번째(로 본) 드라마이다.
    꼬마애가 너무 깜찍하고 예뻤다.
    핏줄은... 서로 땡기는 것인가?

  16. 노부타를 프로듀스(ノブタを。プロヂュース)- 2009년 7월 감상
    토다 에리카(戸田えりか)를 알게 된 게 수확임.

  17. 장미없는 꽃집(薔薇のない花屋)- 2009년 7월 감상하다 중단.
    다케우치 유코(竹内結子)
    카토리 싱고(香取慎吾)
    신파극 비슷한 설정과 분위기가 과해서 중간에 관두었다.

  18. 맨하탄 러브스토리(マンハッタンラブスト-リ-)- 2009년 6월 감상하다 중단.
    코드가 맞지 않아서 3편까지 보다가 중단.

  19. 속도위반 결혼 - 2009년 7월 시청하다 중단.
    히로스에 료코(広末涼子)
    ’できちゃった結婚”이라는 재미있는 표현을 배울 수 있었던 드라마.
    애인으로 오해받는 여자배우가 너무 짜증나서 시청 중단.
    자막은 누가 제작했는지 몰라도, 번역을 못하는 정도의 차원이 아니라 아예 소설을 쓰더라는 -"-))

  20. 전차남(電車男)
    아주 재미있다. 정확히 언제 보았는지는 기억나지 않음.

  21. 의룡 1 / 2 - 2009년 8월 7일 시청
    재미있게 보았음.

  22. BOSS - 2009년 8월 10일경 시청
    그럭저럭 재미있게 봤음.
    여주인공이 그다지 마음에 드는 스타일은 아니었지만, 여주인공의 외모를 빼고 전체적인 출연진들의 연기나 스토리만으로 본다면, 괜찮은 편이다.
    눈이 가는 배우는, 타케노우치유타카 - 竹野内豊(たけのうちゆたか).

    잘생겼다. 연기도 잘한다.
    그리고, 토다에리카 - 戸田恵梨香(とだえりか)。

    토다에리카는 "노부타"에 출연한 것을 봤을 때 알게 되었는데, 참 예뻤다 +_+)) 이미지는 많이 다르지만 역시 BOSS 에서도 예쁘게 나옴. 근데, 버라이어티 쇼 같은데 나온 걸 보면 너무 말라서 뼈만 남았다는 느낌..;

  23. 호타루의 빛(ホタルノヒカリ)- 2009년 5월경 시청
    아야세 하루카(綾瀬はるか)외 다수
    정말 유쾌한 드라마. 왜 여태 기억나지 않았을까 의아함.
    건어물녀(干物女:ひものおんな)라는 용어를 유행시킨 드라마가 아닐까.
    아야세 하루카의 코멘트 : http://www.ntv.co.jp/himono/cast/ayase.html (주의 : 일본어 페이지)

  24. Mr. Brain - 2009년 8월 19일경 시청
    키무라 타쿠야(木村拓哉)
    아야세 하루카(綾瀬はるか)
    짧다. 8편. 아야세 하루카는 차~~암~~ 귀엽다. 귀여운 얼굴이 아닌데, 귀엽게 느껴진다.

  25. 갈릴레오(ガリレオ)- 2009년 8월 22일경 시청
    후쿠야마 마사하루(福山雅治)
    시바사키 코우(柴咲コウ)
    히로스에 료코, 카토리 싱고(香取慎吾) 등등...
    마치 미드 Num3ers 를 보는 듯 한데, Numb3rs 보다는 조잡하지만, 좀 더 재미있다.
    이 드라마를 보면서 일본의 미인은 다들 개성있게 이쁘다는 생각을 했다.

    柴咲コウ

    << 柴咲コウ >>



    여기 출연하는 시바사키 코우도 처음에는 별로이지만 볼 수록 은근히 예뻐지는 타입.
    마츠시마 나나코도 보면 볼 수록 예뻐지는 타입.
    우에노 쥬리도, 토다 에리카도,..
    그건 그렇고, 카토리 싱고를 장미없는 꽃집에서 처음 보아서 그런지, 참 힘없는 배우라고 생각했는데, 여기 나오는 걸 보고, '히야~~ 저런 연기도 하는구나' 하는 생각이 들었다. 역시, 성공한 데는 이유가 있는 법이다.

  26. 사랑해-용서(アイシテルー海洋(かいよう))- 2009년 8월 23일경
    약간 독특한 소재.
    여러가지 생각을 하게 하는 이야기임.

  27. JIN - 2009년 11월, 12월
    타임슬립을 해서 메이지 직전의 시대로 가게 된 의사의 이야기.
    방송될 때 실시간으로 본 첫번째 드라마.
    흥미진진한 스토리 전개가 백미임.



6,7월 사이에 정말 많이도 봤다
덕분에 일본어는 많이 늘었다. (정말이다)

무엇보다 큰 피해는 마츠시마 나나코에 빠져서 아직도 (2009.7.28) 허우적대고 있다는 것인데... ㅠ_ㅠ));;
망했다. 눈만 높아져서 ㅠ_ㅠ))

2009. 8. 23 - 매주 이렇게 방에 틀어박혀서 드라마나 애니메이션만 보고 있다...;;;


:

vim - power of :g

Computing/vim tips 2009. 7. 28. 18:19

팁의 출처 : http://vim.wikia.com/wiki/Power_of_g


회사에서 일을 하다가 trace 파일을 가공해야 할 필요가 생겼다.
다음과 같이 생긴 파일이다 :

[2009-07-28 13:45:36 T-1107208528] LogRecInfoInit :
[2009-07-28 13:45:36 T-1107208528]  blablablablablablablablablablablbalablablablablablabl
[2009-07-28 13:45:36 T-1107208528]  blablablablablablablablablablablbalablablablablablabl
[2009-07-28 13:45:36 T-1107208528]    blablablablablablablablablablablbalablablablablablabl
[2009-07-28 13:45:36 T-1107208528]  blablablablablablablablablablablbalablablablablablabl
[2009-07-28 13:45:36 T-1107208528] LogRecInfoInit :
[2009-07-28 13:45:36 T-1107208528]  blablablablablablablablablablablbalablablablablablabl
[2009-07-28 13:45:36 T-1107208528]  blablablablablablablablablablablbalablablablablablabl
[2009-07-28 13:45:36 T-1107208528]    blablablablablablablablablablablbalablablablablablabl
[2009-07-28 13:45:36 T-1107208528]    blablablablablablablablablablablbalablablablablablabl
[2009-07-28 13:45:36 T-1107208528]  blablablablablablablablablablablbalablablablablablabl
[2009-07-28 13:45:36 T-1107208528]    blablablablablablablablablablablbalablablablablablabl
[2009-07-28 13:45:36 T-1107208528]    blablablablablablablablablablablbalablablablablablabl
[2009-07-28 13:45:36 T-1107208528]    blablablablablablablablablablablbalablablablablablabl
[2009-07-28 13:45:36 T-1107208528]    blablablablablablablablablablablbalablablablablablabl
[2009-07-28 13:45:36 T-1107208528]    blablablablablablablablablablablbalablablablablablabl
00000000: c2 35                                               |.5              |
[2009-07-28 13:45:36 T-1107208528]    blablablablablablablablablablablbalablablablablablabl
00000000: 74 68 72 33                                         |thr3            |
[2009-07-28 13:45:36 T-1107208528]    blablablablablablablablablablablbalablablablablablabl
00000000: 69 6e 73 65  72 74 20 35  32 30 30 20  20 20 20 20  |insert 5200     |
00000010: 20 20 20 20                                         |                |
[2009-07-28 13:45:36 T-1107208528] blablablablablablablablablablablbalablablablablablabl)
[2009-07-28 13:45:36 T-1107208528] LogRecInfoInit :
[2009-07-28 13:45:36 T-1107208528]  blablablablablablablablablablablbalablablablablablabl
.
.
.

요점은, LogRecInfoInit: 라는 로그 이후에 여러 줄에 걸쳐서 정보가 나오는데,,, 이 상태로는 wc 같은 걸 이용해서 카운트를 한다든지 할 수가 없다. 그래서, 앞의 [ ] 안쪽의 부분을 지우고, LogRecInfoInit: 블록을 한줄로 만들어야 하는데.... ㅡ,.ㅡ)));;

이게 한두개가 아니고, 파일이 무려 십만라인이 넘는 파일이다.

간단한 ex 명령어 두 개로 해결했다 :

:g/2009-07-28/norm 0df]x
:g/LogRecInfoInit :/norm VnkJ

요점 :

:g/Pattern/cmd
cmd :
exe
norm ....

자세한 내용은 :help ex-cmd-index

: