Author: byun1114

여러 객체 각의 chamfer distance를 구하는 중이다. CPU로 구하는 방법도 있고, GPU로 구하는 방법도 있다.

적어도 내가 사용하는 범위 내에서는 CPU로 하는 것이 좋다.

• GPU로 할 경우 계산 속도가 일정하지 않다. 상당히 편차가 크다. 빠른 것은 CPU보다 훨씬 빠르고 느린 것은 훨씬 느리다. 5500을 사용하는 입장에서 6배 정도의 속도 향상을 기대해야 한다. 정말 이건 애매하다.
• GPU 여러 개를 가지고 있지 않은 이상 동시에 여러 계산을 진행할 수 없다. 속도 향상 여지가 적은 편이다.
• 3070으로는 간혹 메모리 부족 오류가 생겨 계산 자체가 진행이 안된다. 수 만 번 진행해야 하는데 프로그램이 종료되는 오류는 피해야 한다. 메모리가 큰 3090 같은 것을 이용한다면 큰 문제가 없을 것 같다.
• CPU를 사용해야 하는 작업을 동시에 진행하는 경우라면 GPU로 진행해도 괜찮다.

위에 내용은 지난 번에 남긴 것이다. 다시 시도해보니 GPU다 더 빨랐다. 그것도 충분히 말이다. 그래서 다시 정리했다.

• GPU로 계산할 때 계산 시간이 다르게 보였던 것은 GPU 계산 전에 있는 preprocessing 과정에 걸리는 시간이 모두 달랐기 때문이다. 사전에 preprocessing을 한 파일을 만들어 둔 상태에서 다시 계산하니 상당히 빨랐다. CPU로만 chamfer를 구현하면 3일 정도 걸렸다. GPU로 Hausdorff와 같이 계산해도 7-8시간 걸린 것 같다. 이것도 CPU로 일부 계산한 증례를 포함한 것이다.
• 3070의 8GB VRAM의 한계가 아쉽다. 우선 float32를 사용하면 OOM를 쉽게 접한다. float16으로 계산하면 OOM 빈도가 줄어든다. 이럴 경우만 CPU를 이용하도록 했다. 몇몇 OOM 인 경우를 봤더니 상당히 체격이 길쭉했다. 즉, vertices가 많으면 OOM이 생길 가능성이 높다. 상당히 말이다.

ray를 이용해서 처리 속도를 높이고 있다. 그런데 왠지 모르게 몇몇 부분에서 OOM 오류가 발생했다. Graphite를 이용한 정보 수집으로는 그런 낌새를 도무지 알아차릴 수 없었다. 그래서 의심가는 부분들을 하나씩 확인해 보았다. 7초당 한 번 정도 graphite 정보를 수집했다. top 으로 1초 마다 확인을 해보니 실제로 free 메모리가 매우 줄어드는 경우가 짧게나마 있는 것을 확인할 수 있었다.

obj 파일을 만들 때에만 메모리 부족이 발생하고 있었다. 그래서 사용하는 cpu를 3개 줄여서 하니 속도는 느리지만 무사히 해당 과정을 종료할 수 있었다.

오늘의 교훈. OOM이 발생할 경우 좀 더 세밀하게 살펴 봐야한다.