프로그램 수행시 malloc(3)만큼 많이 불리는 함수도 많지 않습니다. 아주 간단한 프로그램이 아닌 다음에야 메모리를 할당은 거의 필수죠. 대부분의 프로그램에서 쉴새없이 메모리를 할당하고 해제하는 일을 반복하다보니, 효율적으로 메모리를 관리한다는게 쉬운 일이 아닙니다. malloc이 하는 일은 겉으로는 빈 메모리 찾아서 돌려주는 단순한 작업처럼 보이지만, 실제로는 장기적으로 메모리를 쓰는데에 문제가 없도록 온갖 뒷치닥거리를 해야만 합니다. 특히나 프로세서도 여러개이고 쓰레드도 여러개가 함께 돌아가는 상황이 되다보면 malloc이 얼마나 일을 잘 하느냐가 전체 시스템의 성능에 큰 영향을 주게 됩니다. malloc이 제 몫을 못할 경우 얼마나 치명적인지 Andrew Doran씨의 벤치마크 결과를 보면 잘 알 수 있습니다. 파란 선과 분홍색 선을 비교해보세요. 둘 다 Linux 2.6.21인데, 하나는 glibc에 있는 malloc을 그대로 쓴 것이고, 다른 하나는 구글에서 만든 thread-caching malloc을 쓴 것입니다. glibc의 malloc으로는 쓰레드 수가 늘어남에 따라 처리할 수 있는 트랜잭션 수도 증가하다가, 쓰레드가 프로세서보다 많아지면 갑자기 불안한 모습을 보이면서 최고 성능의 60% 수준으로 주저앉고 맙니다. 그러나 tcmalloc을 쓰게 되면 이런 문제가 전혀 없고, 쓰레드 수가 늘어나더라고 일정한 성능을 유지합니다.
FreeBSD에서도 malloc이 병목이 되는 상황이 종종 발생하자, 작년 BSDCan에서 Jason Evans씨가 발표한 jemalloc으로 바꾸어버렸습니다. jemalloc에 대한 자세한 내용은 Evans씨의 논문에 잘 나와있습니다.
NetBSD는 그동안 다중 프로세서 지원이 워낙 미흡했기에 malloc이 병목이 될 기회조차 없었는데, 이번에 Andrew Doran씨가 다중 프로세서에서의 성능을 크게 향상시키면서 며칠 전 malloc도 jemalloc으로 교체해버렸습니다. 이제 NetBSD-current에서는 jemalloc을 기본으로 사용하며, 혹시라도 이전의 malloc을 계속 쓰려면 USE_JEMALLOC을 no로 설정해주어야 합니다. Kris Kennaway씨의 벤치마크 결과를 보면 jemalloc을 쓴 경우(보라색)가 안 쓴 경우(파란색)보다 약 30% 정도 성능이 향상된 것으로 나옵니다.
아직 4.0도 나오지 않았는데, 벌써부터 5.0이 탐이 나네요. 
댓글 남기기