블로그는 귀차니즘

  전 컴퓨터에 관심을 가진지 꽤 오래되었습니다. 멋도 모르고 단순히 친구들과 놀기 좋아할 5~6살 때 쯤 외삼촌 집으로 놀러가게 되었다가 286컴퓨터를 만나게 되었죠. 컴퓨터를 봤을 당시엔 뭐라고 얘기할까요^^ 어린 애가 TV를 보고 하염없이 빠져있는 기분이랄까 그러한 기분을 느끼고 흥미를 가지게 되었습니다.
  어떤 화면에서 매력을 느꼈었냐면 흔히 5~6살 정도에 로보트같은 장난감을 가지고 놀 수 있는데, 컴퓨터 화면엔 여태껏 보지 못했던 F-14 Tomcat 비행기가 그려져 있었던 것이지요. 지금 생각해보면 단순히 선으로 그려 지금 그리라고 한다면 쉽게 그릴 수 있는 그런 단순한 그림이 그려져 있는 QMouse 화면을 보고 그렇게 빠져들었는지는 저도 잘 모르겠습니다.
  그 이후 프로그래머이신 아버지께서 한 회사의 전산실에서 일하셨기 때문에 COBOL개발을 위해서 외삼촌께서 사용하시던 컴퓨터를 받아 사용하게 되었고 덕분에 저도 도스 게임을 무척 많이 즐길 수 있었습니다. 그래서 일까요? 컴퓨터를 여지껏 벗삼아 지내온 기간이 길다보니 어느새 제 삶에서 뗄래야 뗄 수 없는 부분이 되어버린것 같습니다. 그와 동시에 사양에 대한 욕심 또한 무척 크게 되었고 말이죠.
 
  그래서 컴퓨터를 하고 관심을 가지다 보니 컴퓨터에서 가장 느린 매체이자 컴퓨터 성능의 발목을 잡는 하드디스크를 대체할 부품이 나오길 고대 하고있었습니다. 그런데 한 2년 반 전쯤인가 3년 전쯤인지 삼성을 비롯해서 SSD 라는 플래시 메모리 디스크를 사용한 디스크 개발에 나선다고 하더군요. 그리하여 여태껏 기다리고 기다려 여러번의 소소한 지름 끝에 결국엔 이번에 SSD를 지르게 되었습니다. 제가 여태껏 사본 물품 중 단일로는 제일 비싼 가격의 부품이죠. 바로 한성 울트론 4000S 64G( 25만원 )입니다. 많이 부담스럽습니다.
  하지만 기대감이 큰 것도 있고, 바로 액세스 타임이 0.2ms 라는 것을 생각하니 그 정도는 투자할 만한 가치가 있다라고 판단이 되더군요. 그리하야 몇 일전 부품을 사고 장착한 뒤, 여태껏 사용하고 있던 SSD의 후기를 간략하게 나마 남겨봅니다.



  HD Tach라는 하드디스크 벤치 프로그램에 존재하는 8mb의 테스트 결과는 위 스크린샷과 같습니다. 그래프가 무슨 산 봉우리가 겹쳐져 있는 듯한 모습입니다.



  이 스크린샷은 8mb 가 아닌 32mb의 옵션을 주고 테스트한 스크린샷입니다. 8mb 스크린샷과 차이가 꽤 많이 날겁니다. 그래프가 좌우로 축소 되었으니까요^^;; 그래도 제가 사용하는 HDD WD400G 하드가 80mb 에서 60mb 까지 그래프가 대충 그려진다고 한다면 차이는 어느정도 느껴지시겠죠^^

  다른 사이트에서도 이미 많이 올라오는 SSD 벤치마킹 정보, 솔직히 체감할 수 없는 벤치마킹 정보는 이쯤하여 접어두고, 실제 사용하면서 느꼈던 부분을 적어보도록 하겠습니다.

1. 액세스 타임으로 인한 시작 메뉴의 접근이 빠르다.
     일반적인 상황으로 윈도우즈를 자주 사용하므로 그 중에서도 가장 많이 사용하는 Windows XP 부분의 예를 든다면 제가 사용하는 Windows XP x64 에서 시작 메뉴를 비롯하여 프로그램 메뉴는 무척 빨리 뜹니다. 테마를 다 죽이고 고전 테마로 사용하는 저이기 때문에 테마모드에서의 부드러운 페이드인 효과로 숨겨지는 로딩시간이 HDD로 하면 어느정도 존재하게 되는데, 이 부분은 거의 바로바로 뜬다고 생각하시면 됩니다.
   
2. 파일 검색은 무척 빠르다.
     WindowsKey + F 키를 눌러 표시되는 창에서 파일 검색을 하게 되면 일반 HDD 같은 경우 별도의 메모리 캐싱 프로그램을 사용하지 않는 이상 파일을 찾을 때 많은 시간이 걸리게 됩니다. 왜냐구요. 일반 7200RPM 하드 같은 경우 액세스 타임이 12ms 정도 걸리기 때문입니다. 그에 반해 SSD는 0.2ms이구요. 실질적인 체감은 "*.exe"로 옵션을 Windows가 설치되어 있는 SSD드라이브로 주고 검색을 하면 약 1초 정도에 1000여개의 exe 파일이 단숨에 검색됩니다.놀란만 하죠^^; GIGABYTE 에서 출시했었떤 I-RAM 동영상을 보면서 파일 검색을 무척 부러워 했었는데, 그 것을 체감하고 사용한다니 기쁩니다.
   
3. 단일 디스크 혹은 램이 넉넉하지 않을 경우..
     제가 사용한 한성 울트론 SSD는 SLC 기반이 아닌 MLC 기반 SSD이기 때문에 약간의 설정을 해주어야 합니다. 그리고 하드웨어 환경도 받쳐주어야 하지요. 저 같은 경우는 램이 6기가이기 떄문에 램디스크로 1기가를 잡아 512는 Temp 폴더 용도로 사용하고, 512는 256 익플캐시, 256 파폭캐시로 사용합니다. 그리고 웨스턴 디지털사의 400G, 200G 하드도 따로 존재하고 있구요.
     만약 SSD를 단일 드라이브로 사용하고 램도 부족할 경우 프리징(?) 현상을 자주 겪으시게 될지도 모르겠습니다. 프리징이란 시스템 전체는 아니고 프로세스가 약간씩 딜레이 된다고 표현하면 될까요? 1~2초 정도 잠시 멈추는 경우가 종종 있습니다. 그래서 램디스크와 Prefetch비활성화, Index 비활성화는 필수라고 할 수 있죠.

  더 말씀을 드리고 싶은 부분이 있긴 합니다만 아직 저도 그리 길게 사용한건 아니라서 딱히 더 정리된 자료가 없군요. 아시다 시피 SSD나 HDD나 4KB의 랜덤액세스 쓰기 능력은 엄청 취약합니다. 그래서 기존 HDD용으로 사용하는 OS설정의 변경이 필수적이라고 할 수 있죠^^;
  사실 제가 Windows Kernel의 HDD I/O Process 부분을 알 수 없기에 따로 얘길 드리지는 못하겠지만 아마도 프리징이 약간씩 생기는 증상은 아마도 기존 HDD의 랜덤 액세스에 맞춰져 있는 처리 알고리즘이 원인이 아닐까 합니다. 물론 용량이 적은 데이터의 랜덤액세스가 취약한 건 사실이지만 이토록 걸릴것 같지는 않기 때문이죠. 뭐 2세대 제품에는 버퍼메모리가 달려나와서 이 점을 보완했을 지도 모르겠지만 제가 써보지도 못했고 앞으로 1년 후에나 써볼 수 있지 않을까 해서 따로 적기도 뭐합니다;;.
  하지만 이런 단점이 있음에도 불구하고 어느정도 사용해본 결과 역시 돈 값은 한다. 라는게 제 생각이군요. 제가 컴퓨터에 대해선 매니아틱한 면이 있기 때문에 그렇게 생각하는 것인지는 모르겠지만 아무래도 비싼건 사실이기에 막상 싸다라고 얘기하기도 그렇긴 합니다. 뭐 일단 이 정도로 글을 마무리 하면서 이 글이 SSD에 대해서 고려하시는 분들에게 도움이 되었으면 생각이네요^^.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

  개인적으로 오늘 더욱 확실히 알고 싶어 컴퓨터에 대한 기초를 자세히 공부하고 있는 도중 x64에 대한 궁금함이 몇몇 부분에 대해서 드는 것이 있었습니다. 사실 x64 라는 것을 맨 처음 AMD(Advanced Micro Devices)의 K8 Hammer 시리즈에서 나올때 부터 관심을 가지고 있었던 터라, 754소켓 플랫폼인 뉴캐슬당시 그 쪽 방향으로 업그레이드 하게 되었고, XP x64를 나오기 기다려, 데몬(Daemon)또한 x64버젼이 나오길 기다렸던 기억이 생생합니다.
  그 당시 인상적인 기억으로는 32비트 XP 에서 기본 계산기로 50000! 명령어를 내렸을 때, 20초 걸렸던 것이 64비트 XP에서는 50000!에 대한 경과시간이 10초 내외였던 것이 있었습니다. 그로인해 당시 엄청난 성능적 이득이 있을것이라 생각하였지만 실질적으로 여러가지 복합적인 이유로 인해 그다지 성능적 이득이 없었던 현상이 있긴 했습니다.
  나름대로 64비트에 대한 선망을 가지며 많은 자료를 찾아보고 했으나 지금 생각해보니 기초에 대한 많은 부분을 조사하지 못하고 그냥 무작정 열망했었던 것이 아닌가 하는 생각이 갑지가 들어서 자료를 찾아보게 되었습니다. 64비트 프로그래밍을 하기 위해 가장 쉽게 접할 수 있는 IDE는 아무리 생각해도 VS.net 2005, VS.net 2008이라고 할 수 있습니다. 물론 다른 컴파일러도 64비트 플랫폼 설정을 할 수 있고, 컴파일을 진행할 수 있지만 자료를 쉽게 찾을 수 있다고 생각하기 때문에 VS를 선택했습니다. VS.net 을 설치할 때 마다 x64 Compiler를 체크하여 설치하긴 했지만 실제 개인적으로 사용하기 위해 개발했던 유틸을 제외하고는 개발하여 배포한적이 없었습니다. 그 만큼 x64에 대한 관심이 부족하지 않았나라고 생각합니다.
  64비트 프로그래밍에 대한 염두에 두어야할 점을 생각하면 다음과 같은 점이 있더군요.


  한 번 찾은 자료를 정리해 보았는데, 보기보다 많은 차이점이 존재하는 군요. 특히 __int64 라는 것은 기존 x86 Legacy 코드들과의 소스레벨 호환성을 위해서가 아닌가 생각합니다. 기존 소스를 많이 변경해야 한다면 문제점이 많이 생길테니까요. 그래서 32비트에서도 WORD를 32비트로 지정하지 않고 DWORD를 추가함으로써 지원했던것이 이유가 아닐까 합니다.
  개인적으로 특히 __fastcall을 통한 많은 성능 향상을 할 수 있을것 같네요.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

  2008년 1월 24일 컴퓨터를 드디어 사게 되었죠. 2007년 12월 17일 4주 훈련을 위한 훈련소에 들어가기 전부터 컴퓨터 업그레이드에 대한 생각은 깊었습니다. 하지만, 4주 동안 내려갈 가격을 우려해 참고 또 참았죠. 그리고 4주 후 결국 지르게 됩니다. 사양은 대충 E8200에 램 4GB 정도랄까요. 자세히 밝히지는 않겠습니다. 업글 후 CMOS 보드 옵션을 보다 보니 처음 보는 옵션이 떡 하니 존재하고 있었습니다.
  그건 바로 High Precision Event Timer라는 부분이었죠. 그냥 단어 뜻으로 보면 고정밀 이벤트 타이머라고 해석할 수 있습니다. 그런데 웬일인지 이게 또 궁금해지더라고요. 그래서 결국 시간 날 때마다 검색을 해봤습니다. 그랬더니 대충 한 사이트에서 정의가 나오더군요.

High Precision Event Timer( HPET )은 인텔과 마이크로소프트가 멀티미디어 프로그램이나 시간에 민감한 프로그램의 요구를 반영하고자 서로 협력해 개발한 것이다. 원래 HPET 은 이름이 멀티미디어 타이머였으나 마이크로소프트의 DirectX 타이머와 혼란을 일으킬 것을 피하고자 이름을 바꾸었다.

  이 정도로 설명이 나왔습니다. 하지만, 이 것으로는 궁금증을 충족시킬 수는 없겠죠?^^ 그래서 더 읽다 보니 HPET의 이점이 간단하게 설명되어 있더군요.
  실제 마이크로소프트의 테스트 엔지니어들은 HPET 초기 모델에 대해서 테스트를 진행하고 있었답니다. 그런데 이게 뜻밖으로 시스템 성능을 높여주고, 시스템의 정밀도를 높여주어 전체적으로 시스템 수행속도가 빨라졌답니다. 그것은 자신들의 OS인 Microsoft Windows에서 API를 호출함으로써 증명이 되었는데, 유저모드 함수인 QueryPerformanceCounter과 커널모드 함수인 KeQueryPerformanceCounter API를 1000천 호출하고 시간을 재어봤는데 차이가 꽤 나왔다고 합니다. 그 수치는 QueryPerformanceCounter 에서 약 24%, KeQueryPerformanceCounter에서 61%의 성능차이였다네요. 뭐 제가 전기 땜쟁이는 아니라서 이게 왜 이렇게 차이 나는지는 잘 모르겠지만 그냥 수치로 봐도 엄청난 차이인것 같습니다.( 매직 그래프일지도 모르겠습니다^^ )
  그 이유가 적혀있는 설명을 보니 기존의 타이머들은 이론적으로 최대 해상도( 최저 주기겠죠^^? )가 1밀리세컨드고 실제 걸리는 해상도가 2밀리세컨드 였답니다. 게다가 기존 타이머는 1밀리세컨드씩 늦을 수 있기 때문에 결과적으로 가장 최저시간은 3밀리세컨드로 잡아서 사용할 수밖에 없었다고 합니다. ( 이 것은 윈도우 타이머라고 하네요. )
  그런데 멀티미디어 프로그램( 동영상 플레이어를 포함해서 게임도 포함이겠죠^^? )들은 1밀리세컨드의 정확성이 필요했고,  현재 타이머들은 겨우 그럭저럭 써먹을 정도밖에 안 되었기 때문에 새로운 것이 필요해서 나온 것이라 합니다.
  여기서 한 가지 궁금한 것이 생기지 않나요? 그럼 어떻게 지금까지 돌아가던 프로그램들은 잘 돌아갔는지 말입니다. 그 해답을 보니 Large playback Buffer 와 Busy Waiting과 같은 편법을 이용해서 이제까지의 개발자들은 프로그램을 개발했다고 합니다.( 이 것 또한 궁금해 지네요^^ 다음에 한 번 조사해 봐야 하겠습니다. 게임이나 동영상 플레이어는 DirectX Timer 를 사용하여 문제가 없었답니다 ). 그런데 이게 결국 반응성도 떨어뜨리는 등의 성능의 발목을 잡는 게 되었다고 하네요. 이제 원인이 나온 것 같습니다!! 편법을 사용하지 않음으로 인해서 성능이 올라간 것 같군요. 순전히 저의 이상한 해석으로 인한 추측일 수도 있겠지만 아마 별다른 말이 없는 것으로 보아 위 원인이 맞는 듯합니다.
  그럼 HPET의 기능은 고해상도의 주기밖에 없는가? 이것이 또 궁금해지겠군요. 대답은 "아니오."입니다. HPET을 사용함으로써 생기는 이익은 적어도 10mhz 마다 타이머의 클럭을 증가 시킬 수 있으며, 주기적 비주기적 타이머 등 좋은 기능들을 지원한다고 합니다.
  그렇다고 해서 기존에 나온 OS들도 이 기능을 사용할 수 있느냐? 고 묻는다면 그 대답 또한 "아니오."입니다. 왜냐하면, 인텔이 밝힌 스펙 명세서에 따르면 이 기능을 사용하려면 OS 개발자들이 따로 지원을 해주어야 한답니다. 결국, 현재 나와있는 Windows Vista 혹은 새 버젼의 FreeBSD 등을 제외하고는 지원이 되지 않는다는 말이죠. 뭐 아쉽지만 어쩌겠습니까? 새로운 기술은 발전하는데 예전의 OS는 패치를 하지 않으면 코드는 그대로이니 지원하지 않는 게 당연하겠죠^^. 그래도 언젠가는 패치로 지원이 될 것 같습니다.
  그냥 처음 보는 단어에서 시작한 웹 서핑이 이런 결과를 낳게 될 줄은 몰랐군요. 그런데 이런 기능들이 조금씩 추가가 될 때마다 압박이 심히 거세어져 옵니다. 사실 제가 대학생활을 마치기 전에 만들고 싶은 것이 바로 하나의 OS이기 때문이죠. 하지만 이런 재미있는 것을 볼 때마다 흥미가 생기는 것 또한 어쩔 수 없나 봅니다^^ 역시 컴퓨터 쟁이기 때문일까요?? ㅎㅎ. 그래도 이런 것들을 볼 때마다 배울 게 대단히 많다고 생각하는 저는 행복합니다. HPET이라는 단어에서 시작한 조사를 마치며 이만 잠수해 봅니다. 혹시 설명을 더 보고 싶으시면 아래의 링크로 들어가보시는 것도 좋을듯 합니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.