reset.

GIL. python

shhyun — Tue, 28 Apr 2020 12:00:44 +0900

파이썬으로 고성능의? 아니 병렬화된 어떤 코드를 개발할 때, 항상 걸림돌이 되는 요소가 GIL(Global Interpreter Lock) 이다. ML 관련된 다양한 일들을 하면서, 파이썬이 상당히 각광받고 있는 것도 사실이지만, 반대로 이걸로 서비스를 개발하려고하면, 당면할 수 밖에 없는 문제가 바로 GIL 이다.

어? 근데 파이썬도 스레드를 지원하잖아요? 라고 묻는다면, 그 스레드가 여러개가 동시에 동작하더라도, 결국엔 하나의 스레드만 파이썬 오브젝트에 접근할 수 밖에 없기 때문에, 사실상 Single-threaded 프로그램과 다를 바 없으며, 그래서 원한만큼 효율을 높이는 데에는 한계가 있음을 알 수 있다. 이러한 특징으로 파이썬에서는 병렬화된 프로그래밍을 한다고 하면, 프로세스를 늘리는 형태로 만드는 것이 일반적이라 할 수 있고, 특히나 Django 나 Flask 같은 웹서버는 ASGI 같은 미들웨어와 함께 운용되는 것을 볼 수 있다.

참 아쉬운건 그래서 왜 GIL 이 적용되냐 라는 건데, 이 부분이 일반적으로는 파이썬의 구현체인 CPython 에서 내부적으로 Thread-safety 하지 않기 때문이라고 알려져 있다. 이게 결국엔 메모리 관리 방식에 있어서 Reference Counting 으로 인한 것이 같은데, 내부적으로 언젠간 이에 대한 변수들의 관리를 mutex 와 같은 것들을 atomic 이나 다른 것들로 바꾼다면 좋아질 것 같다는 생각도 든다.

문제라면, 파이썬의 개발 주체들이 이야기 하듯, 변수 관리에 대한 다른 방법들을 적용했을 때, 다중 스레드가 아닌 싱글 스레드의 성능 저하가 발생하지 않는 방법이 있다면, 그 개선안을 받아들이고 진행할 거라고 했었던 것 같다. 정확한 레퍼런스는 찾아봐야겠는데, 하도 오래된 기억들이라... 이게 아마 2007년? 8년? 이었던 것 같은데... 아마도 누구나 예상하듯, 그런 방안은 아직은 없다. 거의 저하가 없어 보이는 그런 방법들은 일부 있지만, 구현 복잡도나 관리 복잡도 측면에서 범용화시키기 어려운 부분이 있다. 그로 인하여 사실 파이썬은 여전히 그 넓은 사용성과 편의성에도 불구하고, 고성능에는 어울리지 않는다는 생각이 많이 든다.

Pytorch 도 TF-serving 도 그런 측면에서 serving 툴은 c++, java 같은 언어들을 활용하는 것이겠지만, 한편으로는 아쉬운 생각이 든다.

serving, pytorch.

shhyun — Thu, 23 Apr 2020 20:00:01 +0900

꽤나 오랜만에 글을 쓰는 것 같은데, 참 오랫동안 ML 관련된 일을 하고 있다. 개인적으로는 backend, bigdata 관련 개발자이기도 하고, ML 을 오랫동안 하고 있다는 것 때문에 최근에 많이 요구하는 일들 중 하나가 serving 이다.

serving 이 뭔데? 라고 물으신다면, scikit-learn/tensorflow/pytorch/mxnet 등등.. 다양한 ML 로 만들어진 Model을 서비스로 제공하는 방법을 말한다.

사실 scikit-learn 같은 경우엔 별 문제가 없다. scikit-learn 은 좀 헤비하다고 해도, 가벼운 수준이라 flask 같은 걸로 api 만들고, call 하면 그만이고, GPU 자원을 사용하는 것들도 없거나, 적어서 flask 만을 사용해도 별 무리가 없다. Tensorflow 도 마찬가지로 tf-serving 같은 것을 제공하기 때문에, model 에 대한 개발을 하고 있는 사람들이라면 큰 부담없이(?) serving 을 진행할 수 있다.

근데, 참 곤란한게 pytorch 다. 아무래도 그간 research 에 대한 지원에 집중하였기 때문에, production level 로 넘어가는 데 있어서 tf-serving 같은 기능들이 없고, flask 로 만드는 model deployment 정도 샘플이 전부였는데, 이걸로 서비스 한다고하면, 솔직히 웃음밖에 안나온다.

왜냐면, CPU 만 사용하여 inference 를 한다면 그나마 별 문제는 없는데, 보통 속도 문제로 GPU를 필히 사용한다. 이 경우, 뒷단에서의 I/O 를 처리하는 것과 그 데이터가 도착하고나서 GPU 자원을 Sharing 하는 부분/Batching 처리/Queueing 등을 구현하기가 생각보다 까다롭다. 게다가 python 에서는 무조건 발목잡는 GIL 이 있기 때문에, 이걸 피하려고 하는 다양한 방법들을 생각해야 하는 것도 영 거지같다. 그리고 GPU 메모리 관리 측면에서 flask 같은 곳에서 여러개의 input 이 동시에 들어갈 때, pytorch가 동적으로 input 을 여러 개를 잡으려고 하면, 그만큼 GPU 메모리를 더 잡으려고 하다가 exception 이 발생하거나 그런 부분들이 영 핸들링하기가 어렵다.

그래서 다양한 방법들을 고민 했었는데, 비동기식 io/aiohttp 를 활용한 컨셉으로 고민한 [1]과 같은 훌륭한! 코드도 공유되어 있는 그런 자료도 있고, 이는 실제로 꽤 훌륭하게 동작한다. 물론 Batching 관련해서 문제가 있긴 하지만, 그런건 개인이 알아서 처리하는게 맞다고 본다. 어쨌든 대부분 Pytorch 가 이제 Research 측면에서 워낙에 대세가 되어 가고 있으니 많은 연구/개발이 진행되고 있긴 하지만, 결국엔 Pytorch 는 강력한 경쟁자(?)인 tensorflow 가 제공하는 tf-serving 의 편의성, 안정성 등이 그립다보니, pytorch 를 production level 에서 쓰는게 맞나 라는 고민이 계속 드는게 사실이다.

하지만 역시 pytorch 도 마찬가지로 torchserve 를 들고 나왔다.

https://pytorch.org/serve/

TorchServe — PyTorch/Serve master documentation

Shortcuts

pytorch.org

근데 한번 전체적으로 코드를 훑어봤는데, 아직은 많은 부분이 부족해 보인다. 왜냐하면 backend pipeline 만 flask 에서 java based 로 변경된 듯한 느낌이고, 본인들의 가속엔진인 torchscript 는 아직 미활용 상태라고 보는게 맞는 것 같다. tf-serving 에서 제공하는 여러 기능 중, model archive 라던가 이런것의 기초적인 상태를 제공하고 있는 것 같고, 어떤 방향으로 발전시킬 지는 모르겠지만, tf-serving 의 기능을 최대한 다 흡수했으면 좋겠고, 그보다 더 발전된 방향을 보여줬으면 좋겠다. 지금 코드 내부의 내용들이 S3 등 cloud 에 꽤 친숙한 사용을 위한 기능들 위주로 먼저 깊이있게 개발이 스타트 되는 것처럼 보이는데, 개인적으로는 On-premise 타겟으로 먼저 좀 챙겨주는게 좋지 않나 싶다. GPU Instance 솔직히 너무 비싸서...

컨트리뷰터를 하나씩 살펴보니 이해가 간다. AWS 쪽에서 만든 Multi-model-server 를 이쪽으로 가져오고 있는 것 같고, 대부분이 AWS 관련자들인 것 같으니 이럴 수 밖에.. ㅎㅎ 방향은 잘 모르겠지만, 어쨌든 또 하나의 좋은 툴이 개발되고 있는 건 바람직한 일인 것 같다.

[1] https://medium.com/@ngoodger_7766/fast-gpu-based-pytorch-model-serving-in-100-lines-of-python-ed0fabd8cffb

P.S. 개인적으론 참 즐거운 시대가 왔다. ML 관련된 study 를 십여년간 해오고 있는데, 최근에는 EA 관련된 기술들도 인정받고 있다는 것이 감격스럽기도 하고, 한편으로는 두렵기도 하다. Resource 독점의 시대가 오고 있다는 생각도 들어서...

kalman filter, extended kalman filter, unscented kalman filter...

shhyun — Sun, 22 Apr 2018 21:29:24 +0900

kalman filter는 대부분 잘 알고 있고, 대단히 많은 내용들이 알려져 있기 때문에 핵심이 되는 내용 몇 가지 내용만 기록해두려 한다. wiki 나 다른 자료들을 보면, kalman filter가 prediction과 update라는 두 개의 흐름 구조를 갖고 있는 것을 쉽게 알 수 있다. 대체 prediction 과 update 는 어떤 원리를 기본으로 두고 하게 되는 것인가?

1. gaussian

kalman filter 의 update 는 bayes rule 을 기본으로 product 의 성질을 갖고 있다. 또한, prediction 은 convolution 연산에 해당(사실상 덧셈)하며, total probability 을 계산한다. 사실 이렇게 말로 써놓으면 뭔 말인가 싶은데, 그림으로 가볍게 살펴보면 그렇게 어렵지 않다. (물론, 개념적인 부분만 한정해서 그렇다.)

여기 그렇게 많이 보던 gaussian 이다. 평균 μ 와 편차 σ 를 따르는 gaussian 함수는 상기의 수식과 같이 정의된다. 다들 알고 있는 바와 같이 대부분의 자연 현상을 모델링 하는데 있어서 가장 많이 사용하는 함수로 알려져 있다. kalman filter 는 gaussian 을 다루는 filter 라고 할 수 있는데, 대체 prediction 과 update 는 gaussian 과 무슨 상관이란 말인가?

prediction 과 update 중 우선 update 를 살펴보면, 엄밀히 말하면, measurement update 인데, 위의 그림과 같이 구성되어 있다. 풀어서 설명을 하자면 prior p(x) 는 이전에 알고 있는 사전 지식에 해당한다고 생각하면 되고, measurement p(z|x) 는 센서로부터 취득된 데이터라고 생각하면 된다. 그리고 updated results 는 이러한 취득된 데이터로부터 갱신해 나가게 되는 새로운 확률분포 x 에 해당하는데, p(x|z) 를 계산하는데 bayes rule이 적용된다. 아래의 μ' 과 σ' 은 수식적으로 계산하는 부분을 정리했을 뿐이다. 즉, update 부분은 어떤 센서로부터 측정된 데이터를 알고자 하는 사전지식에 업데이트하기 위해 확률 분포를 정의하는 부분에 해당한다.

prediction 은 그럼 무엇일까? prediction 은 더 단순하고 간단한데, 이미 알고 있던 확률 분포에 다른 확률분포를 합산하여 새로운 값으로 갱신하는 역할을 한다. 즉, total probability 의 개념이 적용되며, convolution(addition) 연산이 내부적으로 사용된다.

정리하자면, 결국 kalman filter의 풀이 방식을 보면 bayes rule을 기본으로 활용하고, 측정된 값을 토대로 예측하기 위한 확률 분포를 정의하고, 기존에 있던 값을 의미하는 확률 분포에 더하여 새로운 확률 분포 값으로 갱신해준다고 할 수 있다.

그리고 위의 지식을 바탕으로 다시 해석해보자면, kalman filter 는 system 의 model 을 정의 했을 때, 그 모델의 노이즈나 에러에 해당하는 term 이 gaussian distribution 을 가진다고 가정하고, 위에 기반한 방식으로 system 에 발생하는 노이즈나 에러를 최소화 하는 형태로 시스템을 update 할 수 있다는 것이다. 그로 인해서 우리가 센서자체가 갖고 있는 노이즈들을 핸들링 하고, 더 정교한 tracking/estimation 등이 가능하다는 것인데... 얼마나 놀라운 일인가? 여기까지 공감이 간다면 kalman filter 는 대강 감이 올 것 같다.

그리고 extended kalman filter 나 unscented kalman filter 나 결국 다 kalman filter 이기 때문에 같은 구조를 가지고 있다. 그런데 대체 왜 다른 형태로 정의된 3가지 kalman filter 가 있는 것일까?

2. modelling

결국 kalman filter 에서 extended kalman filter, 그리고 unscented kalman filter 에 이르기까지 새로운 형태의 kalman filter 가 만들어지게 된 이유는 이 모델링 때문이다. 우리가 state transition equation 과 measurement equation 을 정의할 때, 부득이하게 non-linear term 이 발생하고, 여기서 이것을 handling 하기 위해 미분하여 jacobian 을 핸들링하게 되면, extended kalman filter 가 정의된다.

조금 더 자세히 말하자면, system 의 특성을 볼 때, 특정 구간에서 linearization 을 통해 문제를 해결할 수 있다면, non-linear function 을 taylor expansion 으로 풀어내고, 그 구간 내에서 jacobian 을 계산하여 핸들링 하면 extended kalman filter 가 된다. 즉, kalman filter 자체가 linear system 을 가정하고 만들어졌기 때문에, 이에 대한 non-linear extension 이 extended kalman filter 가 된다. 그러므로 extended 하는 방식에 있어서 수많은 modification 이 있는데, 대부분 system modelling 에 따라서 linearization 을 하는 방법들에 포커스가 맞춰져 있다.

또한, 여기서 한발 더 나아가서 이도저도 다 귀찮으니, state transition model 에 이러한 term 을 모조리 때려박고, gaussian process 로 모든걸 처리하게 되면 unscented kalman filter 가 정의된다. unscented kalman filter 는 일부 값을 sampling 하여, 임의로 약간의 변동성을 추가하여 그 값들을 가지고 gaussian distribution 을 계산하게 되는데, 엄밀히 말해 완벽하게 시스템을 모사하는 것을 목표로 하지 않는다. 다만, jacobian 을 계산하는 과정이 필요 없고, 그로 인하여 시스템의 모델링이 단순해지는 장점이 있지만, 통상적으로는 연산량은 unscented kalman filter 가 조금 더 많은 것으로 알려져 있다. (sigma rule 이나 계산 하는 방식에 대해서는 wiki 를 참고 하는게 좋다.)

3. 정리

사실 말로 주절주절 적어두어서 이걸 보고 다른 사람들도 kalman filter 를 완전히 이해할 수 있을지 애매하다. 개인적으로는 가장 중요한 직관적인 요소가 gaussian distribution 과 bayes rule 이 결합되었을 때, 어떻게 변화하는가에 대한 부분이라 그 부분에 포커스를 맞추어 정리해두었다. 물론, modelling 부분에 적어두었지만, 사실 kalman filter 류의 가장 key 는 model 이다. system 을 modelling 한 결과에 따라서 다른 종류의 filter 를 사용하게 되고, 대부분의 실세계 문제에는 extended kalman filter 가 제일 좋은 성능을 보여준다. 그러나 system modelling, 그리고 이것에 대한 미분식의 도출이 그렇게 쉽지 않기 때문에 다들 머리 싸매고 고생한다.

직관적으로 우리가 kalman filter 를 볼 땐, 상기 그림과 같이 확률분포가 계속 업데이트 되어 점점 좁고 뾰족한 형태로 변해가야 정상이다. 그렇지 않다면 설계를 잘못한 탓일 확률이 높다. 그 바탕에는 저런 직관적인 요소가 있고, 그 background 에 있는 수학적 요소와 기타 보다 자세한 내용들은 다른 reference 를 참고하면 좋을 것 같다. 여기서 이야기 하고 싶은 것은 kalman filter 는 남들 이야기하는 바와 같이 system 의 error/noise 를 핸들링 하는데, 대체 어떤 식으로 변하는 지에 대한 직관적 이해 정도이다.

hdf5 cmake in ubuntu

shhyun — Fri, 20 Apr 2018 17:33:08 +0900

쉬운건데, 이상하게 매번 걸리적거리고 피곤하게 처리하는 내용이라 정리해놓는다.

1. 아래 홈페이지에서 Preconditions에 Windows/Unix 링크 다운

https://support.hdfgroup.org/HDF5/release/cmakebuild.html

2. 어딘가에 압축 풀어놓기.. or 설치

3. HDF5-1.10.1-Linux.sh 실행

여기까진 뭐 그냥 쉽게 잘 간다.

마무리로 .bashrc 든 윈도우 환경이든

HDF5_DIR=뭔가설치된 폴더/cmake 지정

example) export HDF5_DIR=/usr/local/HDF_Group/HDF5/1.10.1/share/cmake

위에 HDF5_DIR 지정해주면, cmake 에서 hdf5 에 대한 내용들을 인식하여 처리할 수 있다.

update.

shhyun — Wed, 14 Mar 2018 23:42:54 +0900

글을 안쓰고 있는 것은 아닌데, 대부분 일하고 관계가 있는 내용들이라 비공개로 작성 중이다.

어쩌다보니 꽤 오래전에 했었던 일들을 다시 꺼내야하는 일들이 계속 생기고 있는데,

차라리 그런 내용들은 하나씩 오픈하면서 내용을 같이 업데이트 하는 것도 괜찮지 않을까 싶다.

하나씩 꺼내보자면,

1. extended kalman filter

2. reinforcement learning ( including deep- )

3. multi-objective optimization ( especially evolutionary algorithms )

왠지 예감에는 비공개로 써놓은거 하나씩 오픈해도 될 것 같다. 깊은 내용은 아니지만...