Windows 7의 효율적인 하이퍼스레딩 관리

몇 달 전 아래와 같은 기사를 볼 수 있었다 (파코즈 또는 관련 해외 기사):

마이크로소프트 윈도우즈 사업부 수석 부사장인 Bill Veghte씨는 윈도우즈 7에서는 하이퍼스레딩 지원이 강화 된다고 밝혔다. 마이크로소프트는 하이퍼스레딩 지원 강화를 위해 인텔과 긴밀한 협조 체제를 유지해오고 있으며, 윈도우즈 7의 스케쥴러 부분을 손봐 멀티코어 프로세서의 이점을 최대한 끌어낼 수 있을 것이라 한다.

하이퍼스레딩은 하나의 CPU가 마치 두 개처럼 보이게 하지만, 대부분의 실행 자원과 캐시는 공유된 채 스레드 문맥 교환 비용만 없어지도록 한다. 그래서 운영체제가 똑같은 CPU로 간주하고 스케쥴링을 하면 별로 좋지 않은 성능이 나올 수 있을 것이다. 예를 들어, 바쁘게 돌아가는 두 스레드를 하이퍼스레딩 관계의 두 논리 CPU에 할당하면 얘들 끼리 한정된 캐시나 실행 자원을 가지고 서로 경쟁하기 때문에 오히려 성능 하락이 있을지도 모른다. 따라서 운영체제가 하이퍼스레딩을 인지하여 더 똑똑하게 스케쥴링 로직을 짜는 것은 합당한 일이다.

윈도우 7을 이제 본격적으로 쓰기 시작했는데, 비스타와는 다른 스케쥴링을 목격할 수 있었다.

좌로부터 각각 한 쌍의 CPU 중 한 녀석에게 주로 일감이 있음을 볼 수 있다.

Core i7은 쿼드 코어지만 하이퍼스레딩으로 총 8개의 논리 CPU가 보인다. 좌로부터 0, 1, …, 7로 번호를 붙이면, 0번과 1번 CPU가 서로 하이퍼스레딩 관계다. 마찬가지로 2와 3, 4와 5, 6과 7도 그러하다.

위 그림을 보면 최대한 하이퍼스레딩으로 만들어진 두 코어에 동시에 작업을 주지 않고, 물리적으로 다른 코어에 작업을 배치함을 알 수 있다. 0-1을 보면 0번이 주로 사용되고 있다. 비슷하게 1-2, 3-4, 5-6에서도 각각 한 녀석만 주로 스케쥴링 되고 있다. 어차피 전체 CPU 사용률이 20%도 안되기에 여유가 많다. 이럴 때는 하이퍼스레딩의 부작용을 막고자 최대한 물리적으로 다른 코어에 우선 순위를 주어 스케쥴링 함을 쉽게 유추할 수 있다.

물론 정확한 스케쥴링 알고리즘은 알 수 없다. 그런데 전체 사용율을 대략 40%까지 올려보며 테스트 해보았는데 충분히 이러한 사실을 확인할 만큼 CPU 사용율이 잘 분배되었다. 비스타에서는 이러하지 않았다. 같은 상황이라면 8개 CPU가 고르게 분배되곤 했다.

이 예에서 보듯, 윈도우 7은 이제는 기본이 된 멀티 코어를 더 효율적으로 이용한다. 몇 가지 예는 더 찾아 볼 수 있다. 윈도우 7은 멀티 코어를 적극 활용해 하드웨어 초기화 시간을 줄여 부팅 시간을 단축했다고 한다. 또, 비스타부터 도입된 새로운 데스크탑 그래픽 엔진(DWM)도 병행성을 늘리도록 프로그램을 개선하여, 여러 프로그램을 돌렸을 때 더 나은 확장성을 얻을 수 있었다.

GDI Concurrency -- Scalability

윈도우 7의 구현은 더욱 똑똑해졌습니다(라고 쓰고 비스타의 구현은 참 멍청했구나라고 이해합니다)

이렇게 하드웨어가 멀티 코어화 되니 운영체제도 여기에 대응을 하고 있다.

맥 OS X의 최신 버전 Snow LeopardOpenCL(솔직히 거의 CUDA를 그냥 베낀 것 같은데)이라는 GPU를 보다 활용할 수 있는 녀석을 제공한다. 솔직히 일반 사용자에게 큰 영향을 주는 것은 아니다. 비유하자면, 그냥 nVidia CUDA 같은 녀석이나 DirectX가 그냥 깔려 배포된다고 보면 된다. 그러나 어쨌든 OS X 개발자들이 OpenCL에 더 쉽게 다가갈 수 있게 되었다.

여러분의 소프트웨어는 어떻게 좀 멀티 코어를 고려하고 있습니까?

by object | 2009/08/30 13:43 | 컴퓨터 | 트랙백 | 핑백(1) | 덧글(16)
트랙백 주소 : http://minjang.egloos.com/tb/2412965
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Linked at 시험さま : SMT, 하이퍼스레딩 at 2009/12/14 17:21

... sp; http://minjang.egloos.com/2179862Windows 7의 효율적인 하이퍼스레딩 관리 http://minjang.egloos.com/2412965SMT를 써서 만들어낸 논리적 코어는 물리적으로 따로 존재하는 코어와는 다르다. 한 줄로 적자면, CPU 내의 모든 자원들이 이중화되어 있는 것이 아 ... more

Commented by summerligh at 2009/08/30 15:22
지금은 싱글 쓰레드라도 좀 버그 없이 구현이 되었으면 OTL
Commented by imc84 at 2009/08/30 19:31
비스타는 별로 안 땡겼는데 윈도7은 써 보고 싶군요. 뭐 전 하드코어 유저도 아니지만.
Commented by object at 2009/08/31 05:49
아무 생각없이 윈도7로 넘어 오셔도 됩니다. 정말로 XP에서 돌려야 하는 프로그램이 있다 하더라도 XP Mode가있습니다. 단, DirectX를 쓰거나 그런 건 곤란하고..
Commented by rein at 2009/08/30 19:55
오 이건 정말 괜찮네요. 이런게 Windows Server 2008 R2에도 들어갔으면 좋겠네요. 내일 회사가면 확인해봐야겠네요 ~_~
Commented by object at 2009/08/31 06:36
커널 버전이 동일하니 지원될 것 같군요..
Commented by dhunter at 2009/08/30 23:09
비스타에 역으로 패치되길 바랍니다.

...안 되면 이번기회에 테크넷이라도 정기구독할까요;
Commented by object at 2009/08/31 05:48
비스타에 이게 들어갈 가능성은 별로 없어 보입니다.
Commented by dhunter at 2009/08/31 09:23
없어보이니 바랄뿐이지요...;

물론 7도 초기에 기대했던 몇가지가 없어서 아쉽긴 하지만요. 비스타부터의 WinFS라던가 드라이버의 페러랠 로딩이라던가요...
Commented by 궁금 at 2009/09/01 12:42
잘 읽었습니다. 지금까지 하이퍼쓰레딩 관련 글들을 읽고 한가지 의문이 있습니다. 이렇게 스케줄링되면 무거운 프로그램이 4개 이하이면 하이퍼쓰레딩을 켰을때와 껐을때 체감이나 벤치가 비슷한 성능일지 궁금합니다. 하이퍼쓰레딩은 코어당 무거운 프로그램이 1개 이상일때 효과를 발휘하고 1개 이하일때는 하이퍼쓰레딩이 없을때와 성능이 같아지는 것인지요. 그렇다며 4코어 이상을 full로 heavy하게 사용하는 경우가 많은 사람이 아니면 하이퍼쓰레딩은 효과를 보기 어려운지요.
Commented by object at 2009/09/01 13:28
네, 말씀하신 것 모두 그렇다고 볼 수 있습니다.

하이퍼스레딩은 싱글 스레드의 성능(=레이턴시/응답속도)을 향상시키는 기술이 아닙니다. 노는 자원을 활용해서 하나의 스레드를 더 돌려서 전체적인 스루풋을 개선시키는 기술이죠. 따라서 말씀대로 바삐 돌아가는 프로그램이 4개 이하라면, 가장 이상적인 하이퍼스레딩에서는 하이퍼스레딩을 껐을 때와 성능 차이가 없도록 해야죠. 그러나 그러하지는 않습니다. 하이퍼스레딩을 켜는 순간 어떤 CPU 자원은 statically partitioned되어서 약간 손해보는 것이 있을 수 밖에 없습니다. 마지막으로, 말씀대로 4개 초과의 일감이 많지 않은 경우라면 하이퍼스레딩은 큰 효과는 없다고 봐야죠. 이건 하이퍼스레딩 뿐만 아니라 일반적인 멀티코어에서도 적용되는 이야기입니다. 일을 하나만 늘 돌리면 듀얼 코어도 별 필요 없겠죠.
Commented by 궁금 at 2009/09/01 15:13
답변 감사합니다. 덕분에 하이퍼쓰레딩이 더 잘 이해되었습니다.
Commented by 모루 at 2009/09/02 11:02
실제로 대부분의 사용에 있어서 HT를 끄는 것이 더 성능이 좋더라구요. Pentium4 시리즈의 HT는 더더욱 그랬고요. 효율이 좋았던 것은 VoIP 처럼 실시간으로 돌아가는 서비스가 있는 경우에는 성능 발휘가 되었습니다. 전체 throughput 보다는 반응성에 치중해야 할 것 같습니다. 결국은 마케팅 상으로 코어 개수가 많아보이는 착각을 하게 한다는 것이 가장 큰 것 같습니다.
Core i5에서 HT가 없어도 실제 성능 비교에서 동일 클럭의 core i7과 비슷한 성능을 내는 것이 예가 되겠지요. 물론 다른 부분이 좋아진 것도 있지만 HT가 도움이 되는 사용 예는 찾기 어렸습니다.
Commented by object at 2009/09/02 13:16
네 지적해주신대로 HT는 그러한 점이 다분히 있습니다.

그런데 스루풋과 레이턴시/응답속도는 전혀 다른 성능의 척도입니다. 이 둘은 명확히 구분되어 사용되어야 합니다. Core i5가 HT가 없어도 실제 '성능'에서 별반 차이가 없다고 말할 때는 응답속도를 기반으로 한 자료일 것입니다. 병렬성이 풍부한 일감을 다룰 때는 분명 HT가좋은 결과를 낼 수밖에 없습니다. 컴퓨팅은 레이턴시가 중요한 곳도 많지만 (대부분의 데스크탑 환경) 스루풋이중요한 곳도 매우 많습니다. 대용량 디비 서버에서는 단위 시간당 처리율이 개개 트랜잭션 완료시간보다 보통 훨씬 중요하죠. HT는 다시말씀드리지만 응답속도를 개선시키는 기술이 전혀 아닙니다. 말씀대로 마케팅적인 측면도 강하고, 모든 경우에 있어 HT가 항상 좋은 성능을 내는 것은 당연히 아닙니다. 언제나 트레이드 오프가 있겠죠. 그래서 최대한 싱글스레드 성능이 나빠지지 않도록 튜닝하는 것이 또 아키텍처 설계자들의 임무가 되겠고요.
Commented by 모루 at 2009/09/02 14:41
항상 관심있게 이 블로그를 보고 있습니다.
수치계산 용이나 그래픽 렌더링, 메모리 DB 등에서 스루풋이 요구가 되는 경우도 CPU 성능이 가장 중요한 문제로 보이지만 가장 문제가 되는 부분은 캐시와 메모리 사이,메모리와 HDD 사이의 병목입니다. 이런 응용에서 대부분은 캐시가 금방 플러시되어 버리고 HDD는 너무 느리죠. 그래서 실제로 풀 로드가 걸려도 CPU가 100%의 로드로 일을 하는 경우는 극히 드뭅니다. (버그로 무한 루프에 빠진 경우 말고요)
HT는 철저하게 CPU 파이프라인의 스루풋만 강조한다는 것이죠. 사실은 메모리에 지연을 감추기 위해 캐시를 이용해서 스루풋을 높여보자는 것으로 이해되는데 캐시의 hit rate이 나쁘면 무용지물입니다. 오히려 캐시 플러시를 높여서 문제가 됩니다.
그래서 실제 서비스에서 HT을 켜고 하면 오히려 성능이 문제가 되는 경우도 많습니다. 병렬성을 높이기 위해 코어 갯수 만큼 쓰레드를 만들어서 데이터를 복제하여 병렬성을 높인 프로그램은 현재 Core가 HT인지 아닌지 판단해서 실제의 Core 갯수 만큼만 쓰레드를 만들어야 합니다.
그런 까닭에 HT는 메모리는 최소로 쓰면서 CPU 연산을 많이 하는 특별한 영역에서만 의미가 있다고 봅니다.
그래서 core i7이 나오기 전까지 인텔이 더 높은 성능을 가진 CPU가 있음에도 AMD가 고성능 서버에 선택되었었습니다.
Commented by object at 2009/09/02 15:10
HT, 좀 더 일반적으로 SMT(동시 멀티스레딩)는 에너지 효율이라는 측면에서 매우 큰 의미가 있습니다. 인텔 뿐만 아니라 AMD도 SMT 채용을 계획하고 있다는 소리가 계속 들리고요. 아시다시피 인텔의 Atom역시 HT를 이용합니다. 에너지 효율에 그대로 부합하기 때문이죠.

뿐만 아니라 아이태니엄 역시, HT/SMT와는 완벽히 같지는 않지만 Multithreading 기술을 사용하여, 메모리 지연 시간 동안 다른 스레드가 일할 수 있는 기회를 줍니다. Larrabee 역시 각 코어는 4-way MT 기술을 채용했습니다. 인텔 뿐만 아니라 Sun의 Niagra가 대표적인 경우인데 코어 당 4혹은 8-way SMT를 구현하였습니다. SMT가 인기있는 이유는 최소한의 자원 복제로 시스템 사용율을 더 높일 수 있기 때문입니다.

아직 SMT가 풀지 못한 문제점은 너무 많습니다. 지적해주신 문제는 대부분이 자원 공유의 fairness 문제인데요. 만약, SMT가 아주 똑똑해 한 스레드만 바삐 움직일 때 모든 자원을 이쪽으로 몰아 줄 수 있다면 부작용을 최소화 할 수 있을 겁니다. 그런데 이게 구현이 힘들어서 TLB 같은 자원은 정적으로 파티션해버립니다. 파이프라인과 캐시 자체도 SMT가 그냥 경쟁적으로 쓰기 때문에 우선순위 등에 문제가 있죠. 하이퍼스레딩 스레드끼리 열심히 돌면서 캐시를 놓고 싸우면 오히려 해악이 될 수도 있습니다.

하이퍼스레딩 같은 기술은 늘 트레이드 오프가 있습니다. 비슷하게 hardware prefetcher도 좋은 성능을 내기도 하지만 부작용을 만들기도 합니다. 그래서 BIOS에서 하이퍼스레딩처럼 끄고 켤 수 있죠. 그러니까 문제가 있으면 끄는 것이 일단 정답이 되겠습니다.. ㅎㅎ
Commented by 고어핀드 at 2009/09/04 12:29
여러분의 소프트웨어는 어떻게 좀 멀티 코어를 고려하고 있습니까?

>> 클래스 설계가 거지같아서 렌더링 부분하고 모델 처리 부분도 분리 못하고 있습니다. ㅠㅜ 3년째 이 코드를 만지다보니 이젠 그러려니 하고 넘어가는... OTL

:         :

:

비공개 덧글

<< 이전 페이지 다음 페이지 >>





by 김민장 2008 이글루스 TOP 100
최근 등록된 덧글
개발자 입장에서의 수많은 ..
by Jiyoon at 02/04
저도 아들 돌잔치때 돌잡이 ..
by 박상욱 at 01/18
미국 대학원 원서 작성중에 p..
by 태클사이야 at 01/13
TO: 박PD 로그인 하지 않아..
by 박응용 at 01/10
http://gigglehd.com/zbx..
by dhunter at 12/28
우와.. 좋네요. 태반이 ..
by 윤광배 at 12/17
항상 좋은 글 잘 보고 있습니..
by y2k at 11/23
글이 좋아서 제 블로그에 담..
by 쏭섭 at 11/23
최근 등록된 트랙백
조엘 스폴스키의 강연 (Sta..
by 인덕원칸타타
[Redis] sds.c를 분..
by 조급하지말고 천천히
메뉴릿
이글루 파인더

website counter

Add to Google

rss

skin by 이글루스