멀쩡한 CPU와 보드를 버리면서 느낀 것


부동산 중개업을 하는 친척으로부터 컴퓨터 관련 SOS가 와서 가보니 
전원넣고 10분정도는 마우스 커서가 안움직일 정도로 부하가 걸리더군요.



그 컴퓨터를 써 본 적이 있어서 당연히 예상하고 있었던 문제죠.
원인은 심플... 메모리 부족으로 인한 과부하~ (현재 512M) 
 -- 부팅시 백신, 메신져에 의한 메모리 부족으로 인한 스와핑 발생
대책도 심플... 메모리 증설. (2G 예정)

메모리를 구입해주기 위해, 케이스를 열고 메모리 스펙을 파악하는 순간...
뜨악. DDR_1이네. DDR_1 1G가 44.000원이니까, 2G로 증설하면 88,000원.
배보다 배꼽이 더 큰 상황.


고객의 니즈(컴이 꼬졌다!!!)도 있고해서
그래서 결국 CPU/보드/RAM 떼어내고,
테크노마트가서 E2220/G31_775보드/DDR_2 구입했네요.

.
.
.

이번에 멀쩡한 CPU/보드/RAM을 버리면서 느낀게
메모리는 (크게 비싸지도 않으니) 훗날을 위해 넉넉하게 꽂자.
(멀쩡한 컴도 메모리 부족앞에서는 대책없다)








by 경후니 | 2009/09/19 12:08 | 트랙백 | 덧글(5)

문서를 대하는 우리의 자세

문서에 관한 블로그가 연달아 올라오길래 생각난 김에 글 좀 씁니다.

필자가 느끼는 문서에 관한
시시비비의 본질은 문서를 요구하는 사람만 있고, 문서를 만드는 사람은 없다는 것이다.
왜 그렇까?


가슴에 손을 얻고 말을 해보자.
당신은 누군가를 위해 문서를 만들어서 인수인계를 해 본 경험이 있습니까? (Yes / No)


그럼 왜 문서를 만들지 않을까?
가장 큰 이유는 문서를 만들지 않으면 이익이 너무 크기 때문이다.
어떤 이익인가 하면
윗사람은
    `입만 가지고` 일을 시킬 수 있고, 문제가 생기면 `내가 언제?`라면서 발을 뺄 수 있다.
아랫사람은
    `해당 업무는 나만 알기 때문에 아무도 나를 짜르지 못한다!!!`는 안전장치 역할을 한다.

만약에 문서를 만들도록 교육받은 사람 A가 있다고 하자.
남들 다 퇴근하는 시간에 밤 12시까지 머리 싸매면서 목차 뽑고, 문장 다듬어 가면서 서류를 뽑았다고 하자.
A가 제대로 된 문서를 만들어 윗사람에게 보고하면
  1. 윗사람은`당연한 것`이 하나 추가된 것으로 생각하고
  2. 회사에서는 제대로된 문서가 있으니 A를 짤라도 별 일이 없을 것이라 생각하고
  3. 인수인계를 받는 신입 B도 `당연한 것`으로 생각할 것이다.
  4. A가 짤려서 다른 회사로 옮겼는데 어느날 갑자기 B가 문서 내용 설명해달라고 전화질을 한다.
(1)(2)(3)(4)에서 보듯이
A는 밤새워서 코딩하는 것도 모자라, 문서 만들어서 공유해봤자 이익은 커녕 불이익만 받게 된다.







이상은
   문서를 만들고 공유하는 것이지만
현실은
   문서를 만들지 않는다.
   문서를 만들어도 존재를 알리지 않는다.

PS.1>
  글을 잘 쓰는 것은 코딩하는 것보다 몇배나 어렵다.
  조그만 함수의 설명문조차도 제대로(=제3자가 보아서 납득할 수 있는 수준) 다는 것도 상당한 훈련이 필요하다.

PS.2>
  제대로 문서 하나 만드는데 기본 수천만원 들어간다.
  (문서 한권이 어떤 사람 년봉에 필적한는 경우가 자주 생긴다.
   예를 들어 4명이서 3달동안 500페이지짜리 문서 하나 뽑았다고 생각해보자. 딱 1년 년봉이다)

PS.3>
 문서와 실제 구현이 다른 경우가 많이 발생한다.  이 문제에 대해 어떻게 대처할 것인가?
 경험적으로 볼 때,
 톱-다운으로 설계가 내려오면 파트별 인터페이스가 명확하기 때문에 비교적 문서 만들기가 쉽다.
 바텀-업이나, 한사람이 원맨쇼로 코딩을 되면 문서를 만든다고 해도,,, 구현과 문서가 완전히 따로 노는 경우가 발생한다.
 이런 경우 문서는 오히려 문서를 만들지 않는게 낫다.

PS.4>
  문서를 요구하면서도 정작 `문서의 규격` 조차도 안가지고 있는 회사(또는 윗사람)들이 비일비재하다.
 

by 경후니 | 2009/08/25 20:41 | 트랙백 | 덧글(3)

ARM CPU의 이해 - [1] 함수 호출

C언어 코드들을 샘플로 들어가면서 ARM이 왜 효율적인 아키텍쳐라고  불리는지 조금씩 알아봅시다.













--------------------------------------------
함수 호출
--------------------------------------------

펜티엄 계열에서는 함수 호출과 리턴에 각각 CALL, RET라는 명령어를 사용합니다.


  hello();
  // CALL _HELLO
  void hello() { return; }
  // RET

그런데 ARM에서는 함수 호출은 BL(CALL과 역할이 비슷)을 사용하고, 리턴은 MOV명령을 사용합니다.
함수 호출시 실행주소가 LR레지스터에 들어가므로
리턴할때 LR레지스터에 있는 주소를 PC(프로그램카운터)로 되돌리는 것만으로도
RET와 같은 효과가 나기 때문입니다.
(이 방식은 호출이 빈번한 함수의 경우, 스택에 매번 리턴 어드레스를 저장하지 않는다는 점에서 상대적인 장점을 가집니다)
당연한 이야기지만 이런 이유로 ARM에는 RET명령어가 없습니다.


  hello();
  // CALL _HELLO
  void hello() { return; }
  // MOV PC, LR

--------------------------------------------
파라메터 세팅
--------------------------------------------

펜티엄에서는 함수에 파라메터를 전달할때 모두 스택에 넣어야 합니다.
예를 들어, 4개의 파라메터를 가지는 함수의 경우 기본적으로 9개의
어셈블리 명령어가 필요합니다.


  hello(10,20,30,40)
  // MOV AX, 40
  // PUSH AX
  // MOV AX, 30
  // PUSH AX
  // MOV AX, 20
  // PUSH AX
  // MOV AX, 10
  // PUSH AX
  // CALL _HELLO


반대로 ARM같은 경우에는 4개의 파라메터까지는 그냥 레지스터에 넣고
함수 호출이 가능합니다. 기본적으로 5개의 어셈블리 명령어로 함수 호출이
가능합니다.

 
  hello(10,20,30,40)
  // MOV R1, 10
  // MOV R2, 20
  // MOV R3, 30
  // MOV R4, 40
  // CALL _HELLO

참고로, 펜티엄상의 PUSH, POP은 파이프라인의 효율적인 스퍼스칼라을 동작을 방해합니다. (*1)
같은 동작을 함에 있어
펜티엄의 경우 최소 10클럭이 필요하지만,
ARM에서는 이론상 최소 3클럭(MOV4개 1클럭, CALL 2클럭)만으로 함수 호출이 가능합니다.

C/C++ 계열의 언어에서 함수 호출이 엄청나게 빈번한데,
ARM이 펜티엄 계열보다 클럭이 낮아도 꽤 괜찮은 성능을 내는 이유중의 하나입니다.

 

 (*1) PUSH, POP은 RISC계열의 CPU들에서는 악(惡)으로 간주되어서
        명시적인 SP레지스터와 PUSH, POP 명령어가 없습니다.
        수퍼스칼라가 몇개건 PUSH, POP을 사용하는 동안에는 하나의 명령어만이 실행가능합니다.
        참고로, 대개의 RISC계열예서는 범용 레지스터중 하나를 SP로 사용하며
        그 SP조차조 ADD 또는 SUB 명령으로 PUSH, POP 효과를 냅니다.
 

by 경후니 | 2009/08/11 19:28 | 트랙백 | 덧글(0)

인도네시아의 소수민족이 한글을 공식 문자로 채택했답니다. 그후에 생길 일














이제 그 인도네시아 사람들은 컴퓨터 쓸때
한글 윈도 써야 하는건가요? 아니면 IME만 한글 쓰는 건가요?

한글 윈도우를 쓰건, IME만 쓰건
키보드는 어쩔수없이 한국서 수입해야 하겠지요?
아니면 키보드 위에 스티커라도 붙이도록 대량 원조를 해야 하는 걸까요?

PS>
인도네시아의 한 섬에서 어던 생각으로 한글(정확하게는 훈민정음이겠죠)을 도입했건간에
어떤 것이든 하나를 바꾸면 생각외로 바꾸어야만 하는 것들이 많죠.

by 경후니 | 2009/08/07 16:37 | 트랙백 | 덧글(4)

짜장면과 개발자 (갑 vs 을)


소프트웨어/하드웨어 개발에서 기능 추가는
짜장면 시켰을때 단무지나 젓가락, 만두 서비스와는 본질적으로 다르다.

아래에 첨부한 문신 사건과 같아서 부족한 것은 추가해 줄 수 있지만,
일단 들어간 것(=코드)는 못 빼준다.
SVN같은 걸로 관리한다고 해도 코드를 빼주는 것은 생각외로 ㅈㄴ 어렵다.
까딱 잘못하다가는 sw 전체를 버그 덩어리로 만들어 버린다.

고객의 요구를 문서화 하고 도장 받아놓지 않으면 아래 문신 사건과 같은 일을 당한다능...
고객은 "그런 것도 안해주냐고~"고 늘 ㅈㄹ을 하지만,
정작 고객의 마음은 갈대와 같아서,
일단 일이 벌어지고 나면 고객은 구두로 한 말은 나몰라라하고,
(갑은 언제나 '내가 언제요?'라고 말할 준비가 되어있다. 농담으로 듣지마라)
개발 담당자는 나락으로 떨어지고...
일 잘하다가 사표 쓴다는 얘기가 나오는게 아니다. -_-;













(내가 늘 신입들어오면
   1. 시키지 않은 것은 하지말고 (농땡이 피우라는 얘기는 아니다)
   2. 의심스러우면 팀장에 확인 받고 
   3. 막상 해보니 이게 아니다 싶으면 언제라도 와서 보고하
 라고 교육을 시켜도
 대개의 경우 사고가 터져서 험한꼴 당해봐야 정신을 차린다. 
 일이 터지고 나면 난 못 도와 준다능~~)

(참고 자료)
별 문신 3개를 그려 달라고 주문하고,
시술하는동안 깜빡 잠이 들었는데 
그 사이 왼쪽 얼굴에 별 문신 56개가 그려져 있었다며 
문신 아티스트를 고소했다.
그런데, 최근 독일의 한 방송과의 인터뷰를 통해 킴벌리의 주장이 거짓말이었음이 들통.
인터뷰중 킴벌리는 취재진이 카메라가 꺼졌다고 말하자
"문신이 괜찮았지만 자신에게는 어울리지 않았다" 고 고백.


by 경후니 | 2009/06/25 23:30 | 트랙백 | 덧글(0)

<< 이전 페이지다음 페이지 >>