내 프로그램의 병목은 어디에?

몇 분 전에 IRC에서 나눴던 대화,

[21:04:24] <rein> 지금 느끼고있는 세월의 흐름
[21:04:28] <rein> 씨디 립핑하는데
[21:04:31] <rein> IO가 병목이야
[21:04:31] <rein> …
[21:04:43] <ㅇㄹㅋ@A_i_e> 아
[21:04:45] <ㅇㄹㅋ@A_i_e> MP3립?
[21:04:46] <ㅇㄹㅋ@A_i_e> …
[21:04:53] <ㅇㄹㅋ@A_i_e> 압축도 어느새 IO 병목이 돼버렸지.

대략 내가 음악 CD를 MP3로 처음 떠 본게 대학교 1학년 (2001년) 때의 일일 것 같은데 그 때만 해도 wave 데이터를 mp3 데이터로 바꾸는데 병목현상을 일으키는 것은 인코딩하는데 걸리는 시간 이었다.
(대충 10분 길이의 음악 하나를 바꾸는데 6분에서 15분 정도가 걸렸던 것 같다)
책장에 꽂혀있던 좀 된 음악씨디들을 꺼내서 iTunes에서 적당히 MP3로 바꾸는데 뭐랄까 IO속도를 풀로 쓰더라(….)
아마 52배속까지 지원되는 ODD일텐데 – DVD RW라 정확한 CD롬 속도를 모르겠음 – 43.x 배속까지 올라가는걸로봐선 IO를 풀로 하고 있다고 밖엔. 실제로는 저 시점에서한 트랙 립뜨는게 종료가 되니 실제 속도는 저보다 잘 나오겠지.

만약 최적성능의 씨디 리핑 프로그램을 만든다면 2001년에는 인코딩 시간을 최적화하는데 신경쓰면 될꺼고, 2007년인 지금은 신경을 쓰지 않는다거나 – 뭐 씨피유 쓰는 양으로 볼 때 적당히 짜도 될 듯 – 편하고 직관적인 UI에 집중하는게 맞을것 같다 – I/O 병목은 ODD 속도 증가없이는 힘들테니 or IOCP처럼 overlap된 I/O를 처리하기 위한 시스템 콜을 쓴다거나;

사실 프로그램을 만들 때도 저렇게 원래 병목이었다고 생각했던게 병목이 아니어서 성능이 거꾸로 나오는 일이 일어난다.

특정 연산의 결과로 나오는 데이터를 미리 계산해서 저장해두면 – 일종의 pre-computation / caching쯤 되겠다 – 전체적인 시스템 성능이 향상되는 결과가 나온다. 적절한 길이의 프로그램 루프를 풀어버리는 것(loop unrolling)도 프로그램 실행 속도가 증가하게 된다.

그런데 말이지 대용량의 데이터를 처리하는 서버 프로그램의 경우엔 정 반대의 일이 일어나기도 한다. 미리 값을 계산해두고 저장하는 것 때문에 데이터 캐쉬에서 캐쉬 미스(cache miss; CPU에서 메모리를 읽을 때 바로 읽는게 아니라 cache를 거쳐서 읽는데 cache에서 못 찾은 경우를 가리키는 용어)가 나는 경우 속도가 급속히 떨어진다. 비슷한 경우로 루프를 너무 많이 풀어서(…) 자주 실행되는 루프가 명령어 캐쉬에 다 들어가지 않는 경우에도 실행속도가 대폭 느려진다.

결국 컴퓨터 엔지니어들이 해야하는 일은 어디가 병목인지 파악하고 거기를 최적화 하는것 밖에 없겠다 – 그리고 이건 하드웨어가 바뀌고 주변 환경(특히 응용의 속성)에 따라 계속해서변화하게 될 것이다.