1차년도 진행된 과제의 결과물 Code에 대한 재구조화를 맡았다.
거창하게 재구조화라고 하지만, Refactoring 정도에 고도화 정도가 어울릴만한 겉 같다.
시간을 들일수록 고치고 싶은 것들이 많아지는 것은 당연하겠지만,
코드를 이해하고 진행할수록 개발 상황을 이해하게 된다.
한동안 pytorch로 개발을 하다가, 오랜만에 tensorflow를 보니 머리가 지끈하다.
마지막으로 봤던 것이 estimator API를 쓰자고 센터에서 주장하면서 코드 정리했던 때 같은데,
그 이후로도 많은 부분이 업데이트가 됐다.
딥러닝 framework이 사실 다 그러하다. 급격한 딥러닝의 발달에 발맞추어 framework도 격변했다.
몇달 전에 돌던 코드가 동작하지 않을 정도로 업데이트 되는 것은 다반사였고 대부분의 함수는 deprecated 예정이니 바꿔서 사용하라는 warning message가 빗발치게 사용됐다.
그렇다고 하더라도 이런 메시지를 연구하면서 신경쓰는 사람들이 몇이나 되랴..
1년전 과제라고 하지만 몇달 전까지 개발에 사용된 코드임에도 충분히 오래된 코드가 되어 있다.
개발자의 비애…라고 할 수 있으려나…
성숙한 상황에서 개발도 그 나름대로 어려움이 있겠지만,
성숙되지 않은 환경에서의 개발은 이러한 부분을 항상 감수해야 한다.
코드를 개선 하는 시간이 확보되면 참 좋겠지만, 대부분의 연구과제가 그렇듯,
feasibility만 보이고 종료되기 때문인지 이런 시간을 확보하기가 매우 어렵다.
지금 하는 것도 겨우 (?) 기업 수탁 과제 내용이다보니,
그리고 과책이 이 부분에 대해서 용인하였기 때문에 가능한 것이다.
딥러닝 framework에서 개선에 따라 가장 많이 차이가 나는 부분은 속도다.
forward/backward 에서 속도 개선도 반드시 필요하지만,
초기 framework의 문제는 data feeding 이었다.
아무리 빠른 GPU를 쓰더라도 얼마나 빠르게 data를 넣어주어 GPU가 풀로 돌게끔 하느냐…
이것이 항상 문제였다.
pytorch에서는 dataset과 dataloader로 어느정도 해결을 봤고,
tensorflow에서는 dataset과 TFRecord로 해결을 봤지만…
legacy code가 개발되던 때에는 이 내용들이 성숙되지 않았을 때라,
우선은 np로 작업하고 feed_dict으로 전달하는 형태로 되어 있었다.
문제는 이렇게 되면 preprocessing 으로 떨구던지 MP 작업을 해야하는데 이게 또 만만치 않은지라,
가장 좋기는, GPU를 풀로 돌리기에는 dataset으로 사용하는 것이 (TFRecord면 더 좋고) 좋다.
근데 그거 맞춰서 하나하나 다 고치려고 하니 data feeding 부를 다 뜯어 고쳐야 해서..고민이다.
pytorch를 쓰면서 개인적으로 바로 고민 없이 넘어갔던 이유는 디버깅의 효율성이었다.
이건 실제로 연구를 진행하면서 도움이 되었던 부분이고,
개발에 있어서 전환을 해야겠다 생각하게 된 부분은 dataloader 부분이었다.
그전에도 data feeding이 bottle-neck인 부분은 경험으로 알고 있었기 때문에
최대한 미리 작업을 해놓고 data는 최대한 불러다 쓰는 형태로 사용을 했다.
그러다보니 코드가 하나로 끝나는 것이 아니라 pipeline화 되는 등 개발에 있어서 초기 작업에 시간이 많이 소모되었다.
확실히 후발 주자의 장점은 이런 것이겠다 싶기도 하면서 어쨌든 tf를 쓰는 프로젝트도 있으니
후우… 시간이 들더라도 좀 고쳐놔야겠다.
하루 날 잡고 고치면 금방 고칠 것 같긴한데 그럴 시간이 나려나…@.@