Study 2014/02/02

TSG: TAOCP Vol. 1 MMIX(2014/1Q)

지난주에 만들었던 예제 코드에서 이해가 안 가던 부분을 정리했다. Data segment에 버퍼를 잡고 화면에 프린트할 문자열을 채워 넣기 위해 아래와 같이 버퍼를 선언했는데: 

LOC     Data_Segment
BUF     OCTA    0

Base address 가 없다는 에러와 함께 mmixal 이 컴파일을 실패하는 것이다.

LOC     Data_Segment
dtop    GREG    @
BUF     OCTA    0

이렇게 dtop 이라는 레지스터를 하나 잡고 현재 주소(@)를 저장하면 컴파일이 된다. 이는 MMIXAL 의 주소 참조 방법 때문인데, BUF 를 레이블로 사용하면 Immediate 를 바로 넣는 것이 아니라 적당한 근처의 주소(레지스터에 저장된)를 찾아서 그곳에서부터 offset 을 더한 값을 사용한다. 이 때 offset 범위가 그리 크지 않기 때문에(대략 128 정도?) 문제가 된다. Data_Segment 의 주소는 다른 곳들과 상당히 많이 떨어져 있기 때문에 다른 레지스터에 저장된 주소로부터 뛰어오기는 너무 멀다. 따라서 Data_Segment 이후의 - 그리고 BUF 이전의 - 주소를 레지스터에 저장해야 하는 것. 이름은 dtop 이 아니어도 상관 없다.

MMIXAL.pdf 에 따르면,

If no base address is close enough, an error message will be generated, unless this program is run with the −x option on the command line

mmixal 에 -x 옵션을 주면 따로 주소를 저장하지 않아도 알아서 넣는다고 한다. 실험해본 결과 dtop GREG 0 이 없어도 동작 했다.

Docker

LinuxContainer 를 적당히 wrapping 해놓은 툴박스같은 느낌이다. 어느 정도 레이어인지 좀 생소해서 문서를 천천히 읽어보고, 튜토리얼도 따라해보며 시간을 좀 썼다. 제대로 이해한 것인지는 모르겠지만, 아래는 지금까지 써본 소감.

우리가 흔히 말하는 OS 로서의 리눅스는 크게 두 개의 레이어로 이루어져 있다.

  1. 커널
  2. 배포판

VirtualBox, VMWare, Hypervisor 등의 가상화는 각 시스템들이 독립된 커널 레이어를 가진다. 윈도에서 쓰던 CoLinux 도 리눅스 커널을 윈도에서 실행시킨 프로젝트로, 커널 레이어를 만들고 그 위에 리눅스 배포판이 설치되는 구성이다.

Docker - 정확히는 lxc - 는 호스트와 게스트가 커널을 공유한다. 한마디로, 부팅 과정이 없다. 환경을 준비하는데 어느 정도의 시간이 걸리긴 하지만 ubuntu, centos 등의 유명한 배포판은 그냥 가져다 쓸 수 있는 형태로 이미 준비되어 있고, 그 외 여러가지 용도별로 만들어진 돌아다닌다. 직접 이미지를 준비하는 것도 새 OS 설치하는 과정과 완전히 똑같이 할 수 있다. (Dockerfile 이라는 괜찮은 방법도 있지만) 이렇게 독립된 환경 - 이미지 - 이 준비되고 나면 여기에서 프로세스를 실행시키는 것은 매우 가벼운 일이 된다. 이렇게 독자적인 환경을 가지고 실행된 프로세스를 Container 라 부른다. Read the whole story

… 당연하게도, 커널을 공유하기 때문에 호스트와 게스트가 모두 리눅스여야 한다는 제약이 있다.

Docker 사용법을 좀 익히고 나서 ipython notebook server 를 구성하는 Dockerfile 을 작성했다. ipython notebook server 의 비밀번호를 일부 사람들에게 알려주었는데, 사실 그 안에서 내 계정으로 바로 머신에 접근이 되는 상황이었다. 결과는 만족할 만 하다. Docker Container 안에서 ipython notebook server 가 실행되고 이 포트가 외부로 연결되어 서빙된다. 실행할 때에는 ipython notebook server 를 실행시키는 대신 dgoon/ipy 컨테이너를 그냥 실행시키면 되고, 컨테이너 내부 계정을 털어도 호스트를 보지는 못한다.

써 보니, 개발과 배포 사이의 간극을 줄이는 용도로 아주 훌륭할 것 같다. Docker is the Future of deploy system! 커널 버전에 민감한 프로그램이 아니라면 개발 머신에서 동작하는 컨테이너가 그대로 배포에 사용되기 때문에 개발머신에서는 되는데 배포해놓으면 안도는 상황 을 꽤 잘 막아줄 수 있을 것으로 보인다.

Coursera compdata-004

4주 강의의 마지막 주였다.

  1. Literate programming
  2. Plotting 할 때 색을 사용하는 방법, 팔레트 사용법 등
  3. Regular expression

을 설명했다. Literate programming에 대한 이야기는 지금 열심히 연습중인 ipython notebook 이랑 많이 오버랩된다. SWeave, knitr 의 대부분의 기능은 ipython notebook 으로 커버될 듯 하다. 그냥 파이썬이나 열심히 해야겠다. 그래프 그릴 때 색 사용하는 방법에는 사실 별 관심이 없어서 그냥 흘려들었고, Regular expression 은 거의 다 아는거라 R 에서 어떻게 하는지 문법만 챙겨 보았다.

과제는 Regex 로 패턴 찾아 개수세기였는데 지금까지 프로그래밍 과제 중 가장 쉬웠다. … 너무 쉬워서 허무할 정도.

Signature track 으로 강의를 들었으니, 나중에 Data Science Specilization 테크트리를 탈 때 R Programming 강좌는 패스해도 된다. 이 강의로 크레딧을 인정해 준다고 한다. 기왕 이리 된거 나중에 저 코스를 다 들어볼까 생각중. 2014/04/07 에 첫 강좌가 시작된다.

일단 이 강좌는 마무리하고 내일부터는 ModelThinking 으로 간다. 10주짜리 꽤 긴 코스로 이걸 듣고 나면 위의 Data Science Specialization 이 준비되어 있지 않을까?

Image segmentaion, registration

JH 의 부탁으로 Medical imaging 분야에서 사용되는 툴, 라이브러리들을 익히고 있다. 3DSlicer 에서

  1. dicom series 를 읽어와,
  2. Volume rendering / Crop ROI or VOI
  3. Image Segmentation | 영상 분할
  4. Image Registration | 영상 정합

하는 방법을 조금 보았다. 3DSlicer 의 인터페이스가 직관적이지 않은 것, 내가 이 분야에 전문지식이 부족한 것, 요구사양이 꽤나 높은 것(맥북에어 애도 ㅠㅠ)이 합쳐져서 작업의 효율이 나지 않고 있다. 특히 Segmentation 이 생각처럼 잘 안된다. 왠지 저것만 되면 나머지는 다 풀릴 것 같은 느낌이 든다.

물론 풀린다는건 3DSlicer UI 로 작업이 가능하다는 얘기고, 이걸 파이썬 모듈을 사용해서 스크립트 작성, 자동화를 하는 것까지 될지는 모르겠다.

UI도 그렇고, 저장소 구성도 그렇고, 오랜 시간을 지내온 프로젝트의 기운이 가득하다. 올인원 패키지를 만들고 싶었는지, 파이썬 2.7 을 그냥 포함( ..) 하고 있다. … 빌드를 하긴 했지만 결국 libPythonQt.so 를 로딩하다 segmentation fault 가 떠서 못 쓰고 있다. 그냥 받아서 설치한 디렉토리에서도 같은 에러가 난다. Slicer 실행 후에 Python interpreter 띄우면 되는데, 왜 안될까.

pydicom 이라는 라이브러리가 있어서 dicom series 를 읽어서 Volume을 만들어보려 했는데, JH 가 사용하는 데이터에서는 몇몇 파일이 InstanceNumber 가 없다며 에러가 났다. 3DSlicer는 이런 예외처리를 해주고 있나보다.

직접적으로 관계가 있을지는 모르겠는데, nipy 라는 흥미로운 라이브러리를 발견해서 ipynb 서빙용 컨테이너에 설치해 두었다.

Comments