삼성동에 볼 일이 있어 갔다가 시간이 좀 남아 반디&루니스에서 온라인 게임 서버 프로그래밍을 뽑아 들었다. 작년에 나오자마자 열심히 본 사람이 "특별한 건 없어요"라는 간단한 평을 남겨 안보고 있었는데, 딱히 땡기는 책이 없어 훑어봤다.
꽤나 앞쪽에 아주아주 드물게 등장하는 파이버fiber에 대한 설명이 있다. 없어도 되는게 들어있네라는 생각을 했는데 그 뒤 내용이 더 놀랍다. 정확한 표현까지는 떠오르지 않는데, CPU 시간을 더 길게 쓰기 위해서 이 파이버를 쓴단다.
결론부터 말하면 거짓이니 파이버에 헛심쓰지 말아라. CPU 시간을 더 길게 쓰는 방법따위는 존재하지 않는다. 윈도우(현대의 거의 모든 OS)는 다수의 쓰레드가 동시에 실행되는 것처럼 보이게 하려고 일정한 시간 - time slice 혹은
하던 일을 잠시 중단했다가 나중에 다시 시작하려면 기억하고 있어야하는 정보들이 있다. 다음에 어디부터 시작을 해야하는가도 알고 있어야하며 현재 작업중이던 상황도 정확히 저장을 해야 다음에 그와 똑같은 상태에서 시작을 할 수 있다. 그러니까 쓰레드간 문맥전환context switching이 일어날때마다 지금 작업하고 있던 내용을 다 저장하고 새로 일할 내용을 다 준비하는 과정이 필요하다. 이 과정이 당연히 공짜는 아니다. 그래서 쓰레드의 개수가 필요이상으로 많아지면 쓰레드간 전환 비용때문에 비효율적으로 변한다.
파이버는 파이버끼리의 전환에 필요한 데이터가 쓰레드보다 적다고 한다. 그래서 옛날 책에 보면 가벼운 쓰레드lightweigth thread라고 표현된 적이 있다. 쓰레드간 문맥 전환이 일어나는 것보다 더 적은 비용으로 문맥 전환을 할 수 있으니 거기서 절약하는 시간만큼의 CPU 시간을 연산에 쓸 수 있다고 생각한 듯하다.
그럴싸해 보이지만 여기에는 숨은 비용이 있다. 쓰레드는 스케줄러가 작업 스케줄을 정해주지만 파이버는 직접 만들어서 파이버간에 문맥 전환을 수행해야 한다. 이 비용이 저렴하지도 않을 뿐더러 잘 만들기도 어렵다. 더구나 서버라면 당연히 멀티코어일텐데(예전이라면 SMP라고 표현하겠죠) 이 환경에서 쓰레드보다 효율적인 파이버간의 작업 전환을 하는 프로그램을 만들정도의 능력이 있다면, 게임 서버 제작은 그만두고 MS에 취직하거나 리눅스 커널 제작에 힘을 보태는 것이 인류에 공헌하는 길이라고 말하고 싶다.
거의 모든 경우에 CPU 시간을 더 길게 쓸수 있다는 말은 절대로 성립할 수 없고, 파이버가 쓰레드에 비해 어떤 장점을 갖기도 어렵다. 이러한 내용은 MSDN의 Fibers 항목을 읽어봐도 알수 있다.
A fiber is a unit of execution that must be manually scheduled by the application. Fibers run in the context of the threads that schedule them. Each thread can schedule multiple fibers. In general, fibers do not provide advantages over a well-designed multithreaded application. However, using fibers can make it easier to port applications that were designed to schedule their own threads.
마지막 문장에 나타나있듯이 파이버는 자신의 쓰레드를 직접 관리하는 일부 프로그램들의 포팅을 돕기 위해서 만들어진 것이지 절대로 더 나은 쓰레드가 목표가 아니다. In general이라는 단어에 집중해 난 뭔가 특별한 경우를 만들어 낼거야라는 생각을 가지고 파이버에 힘쓰고 있다면 말리고 싶다.
