ETC

I/O는 더 이상 Bottleneck이 아니다

Jaime.Lee 2022. 12. 7. 10:30
흥미로운 글이 있어 공유합니다.
원글은 여기서 확인할 수 있습니다.

 

프로그래머를 인터뷰할 때 텍스트 파일에서 단어 빈도를 세는 간단한 프로그램을 코딩하도록 요청합니다. 많은 기술을 테스트하고 몇 가지 후속 질문을 통해 놀라울 정도로 깊이 들어갈 수 있는 좋은 문제입니다.

 

후속 질문 중 하나는 "귀하의 프로그램에서 성능 병목 현상이 무엇입니까?"입니다. 대부분의 사람들은 "입력 파일에서 읽기"와 같은 말을 합니다. 실제로 성능을 측정해보기 전까지는 모두 같은 생각일 것입니다. 우리 모두 I/O는 느리다고 배웠기 때문입니다.

 

하지만 더 이상 I/O는 10년전, 20년전만큼 느리지 않습니다. 디스크에서 파일을 순차적으로 읽는 것은 매우 빠르기 때문입니다.

 

어떤 기기로, 방법으로 테스트했는지는 이 글에서 크게 중요하지 않아 결과를 먼저 확인해보겠습니다.

입출력 유형 속도(GB/초)
읽기(캐시되지 않음) 1.7
읽기(캐시됨) 10.8
쓰기(동기화 시간 포함) 1.2
쓰기(동기화 제외) 1.6

 

시스템 호출이나 네트워크를 통한 I/O가 아닌 순수한 I/O 동작에 대해서만 테스트한 것이므로 모든 환경에서 이런 결과가 나오진 않습니다.

 

어쨌든 결과를 통해 알 수 있는 것은 "단어 빈도를 세는 프로그램의 병목 현상은 무엇입니까?"에 대한 답변은 바로 입력을 처리하거나 파싱하고 메모리에 할당하는 과정이라고 할 수 있습니다. 한글은 해당하지 않는 사항들도 있긴하지만, 단어를 쪼개고, 소문자로 변환하고, 해시테이블에 빈도수를 저장하는 과정이 이에 해당합니다.

 

파이썬과 고랭을 이용해 프로세스의 단계별 수행시간을 다시 테스트 해보았습니다. 파일의 용량은 413MB로 성경책의 100권에 해당하는 분량입니다.

단계 파이썬 Go (simple) Go (optimized)
읽기 0.384 0.499 0.154
처리 7.980 3.492 2.249
정렬 0.005 0.002 0.002
출력 0.010 0.009 0.010
8.384 4.000 2.414

 

여기서 정렬과 출력은 무시할 수 있을 정도의 수치입니다.

 

파이썬과 고랭을 이용해 어떻게 처리하였고 최적화 시켰는지는 원본 글을 확인하시면 됩니다.

 

결론은 빅 데이터를 처리하는 경우 디스크 I/O는 병목 현상이 아니라 단어를 파싱하고 메모리에 할당하는 작업에서 발생할 수 있습니다.

 

혹시 실무 인터뷰에서 관련 내용을 질문했을 경우엔 "일반적으로 I/O에서 병목현상이 발생한다고 알고있지만 이는 10년 전 이야기이고, 디스크에서 데이터를 순차적으로 읽는 경우 속도가 매우 빠르고, 오히려 단어를 파싱하여 정제한 뒤 메모리에 적재하는데 시간이 더 많이 걸립니다."라고 답변하면 되겠네요.