질문:
queue와 concurrent_queue에 각각 자료를 담고나서 그걸 꺼내는 테스트를 해봤습니다.
CreateThread로 생성한 곳에서는 queue에서 값을 꺼내고.
task_group 으로 만든곳에서는 concurrent_quque에서 값을 꺼내서
시간을 채크해봤는데.
concurrent_queue쪽이 훨씬 느리게 나오는데.. 이게 정상적인건가요...?
task의 갯수를 늘려줄수록 더욱더 느려지네요 ;;;
저의 답변 :
queue의 비교가 아니라 thread와 task의 비교군요 ^^;
코드를 봐야 원인을 알수 있겠지만 대충 예상해보면
task는 thread pool로 관리되는 객체라고 생각하시면 됩니다.
thread와는 성격이 다르고 사용용도도 다릅니다.
자주 오해하는 부분인데 Task를 생성/삭제의 비용이 Thread보다 작다고 해서 없다는게 아니죠. 생각보다 큽니다.
즉 롱텀잡은 그냥 Thread로 처리하는게 좋습니다. (위에서 처럼 쓰레드 하나 빼서 Queue의 내용을 처리하는 부분을 Task로 처리하는 부분은 매번 Thread를 생성/삭제하는 코드를 짠거나 마찬가지라고 보시면 됩니다.)
Task는 숏텀으로 쓰레드를 자주 생성하고 삭제하는 부분이 있다면 (예를들어서 핫스팟 최적화를 위해 특정 알고리즘을 병렬로 순간적으로 쓰레드를 많이 만들어서 처리하고 결과 얻고 바로 종료하는 경우 )
그부분을 Task로 나누는것이 쓰레드를 생성하고 삭제하는 것보다 빠르다는겁니다.
문제는 이런 부분이 일반적인 코드상에 거의 없다는게 문제죠.
(물론 물리나 수학쪽에는 프로그래밍에는 적용부분이 많을 수 있겠죠.)
이부분이 task기반 코딩이 많이 활성화 안되는 이유이기도 합니다.
Task는 tbb의 핵심이 아닙니다.
오히려 concurrent로 시작하는 컨테이너가 지금의 컴퓨팅 환경에서는 더 활용도가 높습니다.
Thread + TBB의 컨테이너는 상당히 강력합니다.
TBB는 Thread를 대체하는게 아니라 보완하는 라이브러리 입니다.
(TBB는 Threading Building block의 약자 입니다. ^^; task building block이 아니죠.
thread라이브러지 task라이브러리가 아닙니다.)
실제 사용해 보면 thread대신 task를 적용할데가 아직은 많지 않더군요.
대부분의 Thread가 프로그램의 시작에 생성되고 끝날때 종료하는 롱텀잡을 수행하고 있어서 인거 같습니다.
하지만 앞으로 코어수가 많아지고 CPU가 진화한다면 task라던지 여러 부분의 활용도가 높아질것으로 예상됩니다.
즉 프로그램을 전체적으로 task로 쪼개고 core 갯수 만큼의 thread pool로 관리하면 이상적으로는 core 갯수가 늘어나면 늘어날 수록 성능이 좋아지는 효과가 나옵니다. 그런 효과가 나올만큼 코어가 많아지는 시대가 오면 task기반 코딩이 대세가 될 수도 있습니다.
__
답변 후기 : 물론 core가 많아진다고 task 프로그래밍의 여러가지 난점들이 모두 해결되는건 아니라고 생각 함.
task 프로그래밍의 단점은 task로 나눌 job의 단위가 좀 애매하다는게 있습니다.
task생성/소멸 비용이 thread보다 작지만 신경을 쓰지 않아도 될 수준이 절대 아니라 너무 작은 단위로 나누게 되면
프로그램은 실행시간의 대부분을 task의 생성/소멸만 하게 됩니다.
또 그렇다고 너무 큰 단위로 나누게 되면 single thread 프로그램과 비슷해지는 결과가 나오게 되어 있는데
프로그램의 단위 job이 이렇게 task에 적합한 수준으로 자를 수 있는 경우가 물리나 수학쪽의 시뮬레이션 프로그래밍을 빼면 거의 없어서
이 부분의 불편함을 감수 하고 사용 할 수 있을 정도로 task의 생성/소멸 비용이 줄어들지 않으면 앞으로도 대중화는 힘들것으로 보임.
물론 통계, 소팅이나 검색같은 순간적으로 cpu 사용량이 커지는 부분 즉 hot spot의 최적화에는 지금도 유용함.
제가 생각하는 TBB의 현재의 유용함은 lock free 컨테이너, lock이 최소한으로 노출된 컨테이너 , Thread에 최적화된 메모리 관리자 , 편리한 lock 들 모두 기존 쓰레드 프로그래밍을 더 쉽고 빠르게 해주는 도구로서 충분한 가치를 합니다.
인터넷의 자료를 보면 parallel_for나 task등에 너무 치우쳐져 있어서 -_-;......... STL에서 알고리즘 보다 컨테이너가 더 대중적이듯이 TBB에서도 컨테이너가 더 쓸일이 많음.
최근 덧글