앞으로 Multi Thread의 성능이 많이 좋아질까요?
글쓴이: winner / 작성시간: 일, 2008/05/11 - 4:36오전
최근 간단한 multi thread를 하는 program을 제작할 일이 있었습니다.
그런데 성능이 오히려 떨어지더군요.
최근의 2Ghz 이상의 CPU들은 단일 thread에서도 엄청나게 빠르게 동작합니다.
그에 비해 multi thread를 위한 추가비용은 너무 크죠.
뭔가 동기화가 필요하거나 하면 성능향상은 아예 포기해야 할 것 같습니다.
하지만 계속해서 multi core는 확실한 CPU의 발전방향으로 보입니다.
그렇다면 CPU와 OS에서 thread의 생성비용이나 문맥전환비용, 그리고
동기화 비용에 대한 획기적인 진보가 있어야 할 것 같은데 이런 것이 가능할지 의문입니다.
관련논문이라던가 뉴스같은 것이 있다면 설명부탁드립니다.
Forums:
multi threading은 성능을
multi threading은 성능을 위해서 하는게 아닙니다.
멀티를 써야만 쉽게 구현할 수 있는 기능과 이점이 있습니다.
하지만 그게 성능을 향상시키는건 대부분 아닙니다.
싱글쓰레드의 단점은 한 task를 CPU 한개만 동시적으로 실행 시킬 수 있기 때문에 CPU갯수가 여러개인 경우 CPU가 아깝다는 생각이 들 수도 있습니다만, 병목지점의 대부분은 CPU 자원이 모자르기보다, 메모리나 disk I/O, graphic card I/O (요놈은 대부분 GUI나 게임)이
많기 때문에 꼭 싱글쓰레드일 때 CPU 활용문제가 단점이 되긴 힘듭니다. ( 사실 그 안쓰이는 CPU는 커널이나 다른놈들을 위해 일해도 충분하고요 )
어쨋든 문맥교환이나 동기화에서의 지연발생은 multi core가 나와서의 문제가 아니라 원래
multi thread가 가지고 있었던 이슈이니, 새삼스럽게 진보가 필요하다 아니다 라고 말할것 까지는 없을것 같습니다.
옳은말씀입니다. 하
옳은말씀입니다.
하지만 성능을위해 멀티로 작성하라는 지시가 내려오는경우를 종종봅니다.. 참어이없죠..
만들기힘들고 기껏만들었더니... 다른쪽에서 자원없다고 아우성이죠..ㅡ,.ㅡ;;
그러니 다음달엔 그쪽도 성능개선으로 멀티로 작성하라고 ㅋㅋ
몇달뒤에 전체적인시스템이 거의 동작불능에 다다를지경입니다.
안타깝게도 현재 제가있는 바로 이곳이 그렇습니다...
1. 앞으로 cpu 의
1. 앞으로 cpu 의 각각의 코어의 속도가 빨라지는 일은 매우 드물게 4Ghz CPU를 예전 같은 발전속도로 기대하면 이미 나와있어야할텐데 아직도 못 보고 있고 18개월안에 볼 일도 없습니다. (이건 발열 문제, 파워 문제 등이 걸립니다)
2. 코어 수는 앞으로 한동안 늘어날겁니다 - 적어도 3년 이상은. 그래서 프로그램의 속도를 계속 올리기 위해선 싱글 코어 쓰면서 코어 속도가 올라가기를 기대하는걸론 어림없고 여러 코어를 써서 그만큼의 속도를 뽑아내야하는거고요.
멀티 코어를 써서 성능이 올라가는 것은 스레드 생성 비용이나 문맥전환 같은데 들어가는 비용보다 스레드를 추가로 투입해서 얻는 이익이 크기 때문이고, 아주 간단한 이미지 처리부터 시작해서 여러개의 작업이 얽혀있는 디비 서버나 게임 서버같은 류까지 코어를 추가로 투입해서 얻는이익은 많습니다.
이런 류의 논리를 펴는 글로는 C++ 표준위원회와 microsoft에서 일하고 있는 Hurb Sutter의 일련의 글들이 있습니다.
* 2005년 DDJ의 공짜 점심의 끝 : http://www.ddj.com/web-development/184405990 - 한글요약(http://rein.upnl.org/wordpress/archives/540)
* 2007년 DDJ의 "얼마나 확장가능한가, 혹은 확장할 필요가 있는가?" : http://www.ddj.com/hpc-high-performance-computing/201202924
* 2007년 DDJ의 "동시성 프로그램의 분류(Pillars of Concurrency)" : http://www.ddj.com/hpc-high-performance-computing/200001985
* 2008년 DDJ의 "암달의 법칙 깨기 (Breaking the Amdahl's Law)" : http://www.ddj.com/architect/205900309 - 한글요약(http://rein.upnl.org/wordpress/archives/541)
제 생각이지만 단인 프로세스 프로그램의 경우 앞으로 18개월이 지나도 2배는 커녕 20%나 성능이 올라가면 잘 올라간거라 생각합니다. 반대로 코어를 scalable하게 쓴다면 18개월 정도마다 코어 수가 2에서 4배 올라가니 동기화 부하를 뺴고 생각하면 약 240%에서 480% 정도 빨라지겠죠. 동기화 부화를 엄청나게 잡고 생각해도 대충 2에서 4배 빨리질테니...
제가 알기로
제가 알기로 multithread에서 문제가 되는 건 쓰레드 생성이나 context switch 비용이 아닙니다. 이들은 지금도 충분히 작습니다. 그리고 더더욱 multicore라면 어차피 각 쓰레드가 별도의 코어에서 도니까 context switch 비용은 별 의미가 없어지죠.
문제가 되는 건 multithread에서 어떻게 과도한 locking overhead가 생기지 않도록 일을 잘 나눌 것인가 하는 거죠. 그러니까 간단히 말해서 single thread로 짜는 것보다 프로그램이 백만배쯤 골치아파집니다. 이걸 어떻게 하면 버그도 없고 과도한 lock overhead도 없게 잘 짤 것인가 하는 방법론이 아직 제대로 나와 있지 않아서 말하자면 그냥 프로그래머의 천재성에 -.- 의존하는 상태죠.
시스템 쓰레드는
시스템 쓰레드는 대부분의 경우 너무 무겁습니다. 그래서 유저 레벨 쓰레드를 쓰는데, 프로그래밍 언어 시스템이 이를 제대로 지원해야 합니다.
에릭슨에서 스위치 소프트웨어를 만들기 위해 개발된 Erlang 이라는 언어가 바로 가벼운 스레드를 수천개 수만개씩 만들고도 부하가 적게 걸리도록 구현해 놓은 언어입니다. 다음 논문을 참조하세요. 간단한 성능 비교가 있습니다.
J. Armstrong. Concurrency oriented programming in Erlang
Erlang 에 대한 더 자세한 내용은 다음 책을 참조하시면 될겁니다. (저도 사 놓고 아직 많이 못읽었네요 ^^)
Programming Erlang: Software for a Concurrent World, by Joe Armstrong
Erlang 은 현재 오픈 소스로 제공되고 있고 많은 리눅스 배포판에서 패키지로 제공합니다. 이미 산업에서 그 효용성을 검증받은 병렬 지향 언어이자 함수 중심 언어인 Erlang 을 프로젝트에 도입해 보는 것은 어떠신지요?
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
흠.. 최근 번역서가 나왔군요.
Programming Erlang
http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200805290006
그런데 책 소개를 봐서는 제가 생각하는 user level thread가 아닌 것 같은데...
도서관에 구매신청해야 할 듯.
그런데 목차보니가 atom을 애텀이라고 번역한 듯... 0_0..
최근 다중 thread에서 memory 관리가 많이 발전한 것 같습니다만...
처음 의문이 들었던 이유는 memory pool을 조사하던 중이었습니다.
그런데 OS kernel들의 memory 관리 능력이 상당히 많이 발전한 것 같더군요.
물론 단일 thread memory pool에는 아직 미치지 못합니다만
다중 thread memory pool은 그다지 쓸 필요가 없어진 것 같았습니다.
최근의 library나 kernel의 변화를 보면 확실히 다중처리를 위한 변화가 많이 보입니다.
옛날의 복잡한 Copy On Write 기법같은 것이 사라지고, 단순화된 문자열이라던지
Kernel의 memory관리 능력에 대한 측정이 다중처리 상황에서 집중되고 있습니다.
하지만 거꾸로 다중처리에 좀더 초점을 맞춘 방식으로 CPU 구조나, OS kernel이 바뀐다는
이야기는 별반 듣지 못했습니다.
만일 single에서 10% 느려져도 병렬처리에 대한 병목이 발생하는 부분을 30% 정도만 줄여도
크게 성능이 향상될 것 같다는 생각이 들더군요.
Hyper-thread가 조금 비슷한 style이었던 것 같군요.
imyejin님은 사용자 thread에 대해 이야기 하셨지만 이것은 다중처리가 아닌 동시성을 위한
기법에 지나지 않지 않나요? 제가 알기로 사용자 thread는 다중처리가 안될텐데요...
생각하시는 쪽에
생각하시는 쪽에 가장 가까운건 솔라리스 일듯 합니다. CMT를 위시해서 64개의 쓰레드가 돌아가야 제성능을 발휘하는 CPU를 맹글어내는 회사니까요. 오픈 솔라리스를 참고해보심이...
모든 답변 감사합니다.
그런데 현재의 SMP 구조에서는 제가 생각하는 만큼 나아질 것이 없는 것 같군요.
Open Solaris 는 한번 봐야할 것 같습니다.
overhead...
멀티쓰레드의 오버헤드에 대해서는 좋은 말씀 많이 해주셨고 대가들도 많으시고...
한가지 덧붙이자면 멀티쓰레드에 대한 적절한 설계 기법이나 도구가 없다는 점이
보통 생각하는 것보다 큰 문제인 것 같습니다.
비즈니스 프로세스로부터 데이터/호출 흐름으로 설계해가는 절차에 있어서는 도구를 이용한 검증이
그런대로 어느 정도의 효과는 거두고 있는데,
멀티쓰레드에 대해서는 표준화된 표기 심볼조차 없으니 자동화된 검증은 둘째치고
설계 단계에서 검증이란 것 자체를 하기가 매우 힘들더군요.
????
이글에서 Multi Thread 와 Multi Process 가 햇갈린것처럼 들리는건 나뿐?
---------------------------------------------------------------------------------------------------------------
루비 온 레일즈로 만들고 있는 홈페이지 입니다.
http://jihwankim.co.nr
여러 프로그램 소스들이 있습니다.
필요하신분은 받아가세요.
multi-threading, multi-processing의 발전은
사실 CPU 나 OS 레벨에서 얻을 수 있는 게 크지 않을 겁니다.
사실 지금에 와서는 multi-threading 을 위한 context switching 이나
(유닉스에서) multi-processing 을 위한 process 생성 오버헤드가 그렇게 크지는 않습니다.
사실 병목 현상의 원인은 논리적인 데 있습니다. (잘못 디자인하지 않았음에도) 많은
프로세스나 쓰레드들이 mutex 를 이리저리 걸어야 할 상황이라면 그건 이미 그 작업은
병렬 처리에 적당하지 않다는 걸 의미합니다. 서로 race condition 에 기다리고 기다리면서
성능 향상 없이 오버헤드만 느끼게 되죠. 즉 각각의 작업이 거의
독립적으로 돌아가고 input/output 만 서로 주고받는 경우가 병렬 처리에 적당한
경우이죠. 예를 들면 많은 이미지 프로세싱 algorithm 처럼 각기 독립적인 부분을 따로
처리해서 결과를 합치는 식이라던가, 하니면 많은 수치계산 문제에서처럼 문제를
부분부분 나눠서 그 부분을 풀고 다시 합쳐 나가는 재귀적 algorithm 들과 같은 경우죠.
다른 경우에는 그렇게 얻는게 많지는 않습니다. 오히려 논리적으로 생각하기 복잡해지고
디버깅하기가 상당히 어려워져서 잃는게 많은 경우가 많습니다.
사실 주로 쓰이는 imperative programming language 들이 concurrent programming 을
어렵게 하는 요인 중 하나이긴 합니다. 순차적이든 객체지향적이든간에 순차적인 문제
해결 패러다임을 강요하는 셈이니까요. 다른 패러다임의 언어들은 좀 더 상황이 낫습니다.
예로, 위에서 말씀하신 functional language 에 해당하는 Erlang 이 프로세스 자체를
다루는 것을 쉽게 제공해줌으로써 threading 을 쉽게 만들죠. Logical programming language
들이, (최소한 이론적으로는) 가장 최상이라고 봅니다. Concurrent programming 을 위해
학문적으로 만들어진 것 중 제가 기억하는 건 Prolog 의 변형판 Parlog 이나 Tempo 등이
있군요.
그리고 multi-threading/processing 을 위한 표기 체계가 있긴 한데...
temporal logic (http://en.wikipedia.org/wiki/Temporal_logic) 이 그것인데,
인간의 머리가 이에 적당하지 않아서 오래전부터 논리학/CS/operation research등에서
항상 연구해오던 것임에도 상당히 부담스럽긴 합니다. :-)