프로그래밍 언어가 제공하는 기본 라이브러리에는 단순히 자주 쓰이는 자료 구조나 알고리즘 외에도, 운영체제에다 요청을 해야 지원받을 수 있는 기능이 일부 있다. 메모리를 할당하거나 파일을 읽고 쓰는 작업이 대표적인 예이다. C/C++ 라이브러리라 해도 그런 기능은 궁극적으로 Windows API 같은 저수준 API를 호출함으로써 제공하는 셈이다.
그러니 프로그래머로서는 굳이 이식성을 염두에 두고 작성하는 코드가 아니라면, 언어가 제공하는 API보다 운영체제가 제공하는 API를 직통으로 쓰는 게 성능면에서 낫지 않나 하는 생각을 하게 된다.
이게 완전히 잘못된 생각은 아니다. 그러나 그렇지 않은 경우도 있으므로 주의해야 한다.
예를 들어, 윈도우 API에 있는 ReadFile/WriteFile과, C 라이브러리에 있는 fread와 fwrite를 생각해 보자.
C 라이브러리의 소스를 보신 분은 있겠지만, 일례로 fwrite는 내부적으로 _write 함수를 호출하는 형태이고, 두 함수만 해도 소스 코드가 수백 줄에 달한다. 뭔가 추상화 계층을 거치는 게 있고 복잡하다. 그러면서 _write 함수의 한쪽 구석에 결국은 WriteFile 함수를 호출하는 부분이 있다. fwrie가 WriteFile 직통보다 빠를래야 빠를 수가 없어 보인다.
그런데 윈도우 환경에서 프로그래밍을 오래 해 본 분은 경험적으로 아시겠지만, 몇 바이트짜리 소량의 I/O를 수백, 수천 번씩 반복해서 시켜 보면 fread/fwrite가 ReadFile/WriteFile보다 훨씬 더 빠르게 수행된다.
그렇다. C 함수는 내부적으로 버퍼링? 캐싱?을 해서 소량의 I/O는 뭉쳤다가 몰아서 한꺼번에 하는 반면, 운영체제 API는 곧이곧대로 매번 오버헤드를 감수하면서 I/O를 직통으로 하기 때문이다.
물론, 요즘은 운영체제가 자체적으로 디스크 캐싱을 다 하는 게 대세이지만, C 함수는 더 상위 계층에서도 캐싱을 하는 걸로 보인다. 이게 성능 차이가 굉장히 많이 난다.
<날개셋> 한글 입력기에서 1년 전쯤에 공개된 지난 6.2 버전의 README를 보면, 편집기의 파일 저장 및 변환기의 변환 속도가 훨씬 더 빨라졌다고 적혀 있다. 이것의 비결이 바로 저 특성을 이용해서 파일 I/O 속도를 향상시킨 것이었다.
메모리 할당도 마찬가지이다.
운영체제는 프로세스마다 heap이라는 가상 메모리를 둬서 프로그램이 다수의 작은 메모리 덩어리를 동적으로 요청할 때 빨리 빨리 반응할 수 있게 하고 있다. 연결 리스트나 트리 같은 자료구조는 메모리 할당이 잽싸게 안 되면 성능이 크게 떨어질 테니 말이다.
(이때 heap은 자료 구조 heap하고는 전혀 관계 없는 개념이므로 혼동하지 말 것.) 그래서 윈도우 운영체제에서 C 라이브러리의 malloc 계열 함수는 HeapAlloc이라는 API 함수를 호출하는 상위 계층이다.
내 경험상으로는 요즘의 NT 커널 윈도우는 HeapAlloc와 malloc, 그리고 HeapFree와 free가 성능 차이가 거의 느껴지지 않는다. 그러나 과거의 윈도우 9x 시절에는 그렇지 않았다.
“윈도우 9x에서는 이 함수는 진짜로 작은 메모리 블록에만 최적화되어 있기 때문에, 이걸로 수 MB에 달하는 메모리를 한꺼번에 여러 번 할당하면 성능이 크게 떨어지고 프로그램이 느려짐. 그 경우엔 다른 메모리 할당 함수를 쓰기 바람.”이라는 경고문이 MSDN에 명시되어 있었다.
내부적으로 그 함수가 어떻게 구현되어 있는지는 잘 모르겠지만, 내가 테스트 해 보니 진짜 그랬다. 9x에서는 프로그램이 뻗은 게 아닌가 싶을 정도로 도저히 견딜 수 없이 느려졌다.
이때에도 윈도우 API가 아닌 C 라이브러리의 malloc 함수는 랙 없이 잘 동작했다. 대용량 메모리 할당 요청이 왔을 때 가상 메모리 주소를 다시 잡는 등 대비가 되어 있어서 그런 것 같다.
원론적으로야 추상화 계층이 있는 언어 API보다는 운영체제 API 직통이 더 빠를 수밖에 없는 게 맞다. 사실, Windows API로도 모자라서 NTDLL처럼 아예 문서화되어 있지도 않은 곳에 있는 native API를 사용하는 프로그램이 있기도 하고 말이다.
그러나 프로그램의 이식성까지 희생하면서 굳이 직통 API를 쓰고자 한다면, 위에서 예를 들었듯이, 그 API의 특성을 잘 알고 쓰는 게 무엇보다도 중요하다고 하겠다. C++ 라이브러리야 객체지향 구현을 위해서 bloat되는 게 불가피하다고 쳐도, 그보다는 더 단순한 C 라이브러리의 추상화 계층은 그저 불필요한 잉여밖에 없는 건 아닐 것이기 때문이다.
Posted by 사무엘
