Hyper Threading 쓸까? 말까?

음 제가 MS 올 때 받았던 질문이기도 하고…
깊게는 이야기 하지 않고 딱 고객이 질문하면 대답할 수 있는 수준만 정리해봤습니다.
결론만 보실려면 맨 아래 영문만 보시면 됩니다.

먼저 하이퍼 스래딩을 알려면 CPU 구조 중 파이프라인과 수퍼 스칼라를 알아야 합니다.

먼저 파이프 라인을 알아 보겠습니다.

CPU의 성능을 높히기 위해서는 어떻게 해야 할까요?

1. 당연히 처리 속도를 높힌다.
2. 그리고 단위 시간당 처리할 수 있는 양을 늘린다.

음 1번과 2번이 같은 이야기로 들리시나요?
다시 CPU에서 명령어가 실행 된다 함은 “메모리에서 읽어서 > 해독하고 > Operation Code를 찾아 내어 > 해당 코드를 실행 하고 > 결과를 적제 한다.” 정도가 되겠죠?

자 이렇게 명령어가 한 사이클 동작한다고 했을때 다음과 같은 가정을 해 봅니다.

1. 5단계의 과정이 다 끝난 이후 다음 명령어가 실행 된다.

명령어 처리는 분명 5단계라는 가정을 했습니다. 즉 특정 명령어는 분명 5단계 중 하나의 단계인 상태로 남아 있을 것이고, 이는 나머지 4단계를 처리하는 모듈들은 모두 쉬고 있다라고 볼 수 있는 것이죠.

그래서 명령어는 CPU는 각 단계를 통해 실행 되고 해당 단계가 완료 됐을 때, Pipe line을 통해 다음 실행 단계로 전이됩니다. 이 기술을 파이프 라인이라고 부르며 이를 통해 단위 시간당 처리 량을 늘릴 수 있죠.

자 이제는 수퍼 스칼라 구조에 대해서 알아보겠습니다.

그런데 파이프 라인만으로는 처리률을 늘리는데 한계가 있습니다.
자 다음과 같은 코드를 생각해 보겠습니다.

1. a1 = a0 + 1
2. a2 = a1 + 5
3. b1 = b2 +b3
4. c0 = c1 +4

각각이 하나의 명령어라고 볼 때, 1번과 2번은 1번 명령어가 첫번째 “메모리에서 읽어서”가 진행 된 이후 2번이 진행되기가 어렵습니다. 왜냐? 2번은 1번 과정이 끝난 이후 즉 1번 과정에서 결과를 적재한 이후 a1 을 읽어서 진행해야 하기 때문이죠. 물론 recursive 하게 호출하는 방식으로 병렬 처리율을 높히기는 하지만 말이죠. 하지만 코드를 자세히 보니깐 음… 3번과 4번은 1번과 2번과 같은 종속성이 없군요. 자 그렇다면 3번과 4번을 먼저 실행하는건 어떨까요? 이렇게 하기위해서는? 파이프 라인이 병렬로 있으면 되겠군요! (물론 비 순차 실행을 위한 여러 도구가 필요하긴 합니다.)

그래서 현대의 Processor는 파이프라인을 병렬로 여러개 가지게 돼었습니다.

그리고 이런 명령어 수준의 병렬화 처리 다시 말해 처리 집적도를 높혀주기 위해서 비 순차 수퍼 스칼라 파이프 라인 구조를 탄생하게 됐습니다.

그!런!데! 지금까지 전 명령어 수준의 즉 Instruction 수준의 병렬화만 이야기 했죠.
다시 쓰래드 수준의 병렬화가 이루어진다면 해당 명령어들 사이의 종속성은 훨씬 줄어 들게 되고, 다시 이 병렬 파이프 라인들을 더욱 효율적으로 사용하게 될 수 있지 않을까요? 그래서 지금의 Processor 들은 쓰래드 간의 병렬화를 지원하기 위한 하이퍼 쓰래딩 기술이 적용되게 됐습니다. 단지 쓰래드들간의 문맥 교환 비용 완화를 위한 약간의 레지스터가 필요했을 뿐이니깐요. (펜티엄 4에서 하이퍼 쓰래딩 구현을 위한 레지스터로 인한 증가량은 단일 면적에 비하여 약 5% 수준이라고 합니다.)

자 다시 말하면 명령어를 처리하는 파이프 라인을 빈틈 없이 꽉 채워 쓰기 위해서 하이퍼 쓰래딩 기술이 나왔다고 할 수 있습니다. 하지만 하이퍼 쓰래딩 환경은 실제로 케시 및 비 순차 실행 (위에서 설명한 1~4까지의 코드 실행을 생각해 보면 알 수 있습니다.) 으로 인한 불균형 문제가 발생 할 수 있습니다. 먼저 비 순차 실행은 이발소 문제와 같은 스래드 간의 기아 조건을 야기 시킬 수 있고, (즉 실행하는 쓰래드만 열라 실행하게 되는….) 이를 위한 여러가지 해결 책들이 적용되고 있음에도 쉽지 않음이 사실입니다. 또한 실행하는 쓰래드들 간의 캐쉬가 충돌을 일으키는 경우에도 성능저하가 발생하게 됩니다.

하지만 그럼에도 불구하고 인텔에서는 약 30% 정도의 성능 향상 효과가 있다고 이야기 하고 있습니다. 더불어서 현재의 Windows 2008 R2의 경우 하이퍼 쓰래딩을 aware 하여 CPU 스케줄링을 하고 있습니다. (이전에는 잘 모르겠습니다… ㅡㅡ;;;)

하지만 결론은 무조건 하이퍼 쓰래딩을 Disable 시키는 것은 아니다 정도가 되지 않을까 합니다.
더 나아간다면 실제 성능 측정을 통한 방법 많이 이익인지 불이익인지를 명확하게 판가름하는 방법이 아닐까 합니다.

SQL Server에서의 적용에 대한 저희 문서는 아래와 같이 이야기 하고 있습니다.

”The performance of hyper-threaded environments varies. Conservative testing has shown 10 to 20 percent gains for SQL Server workloads, but the application patterns have a significant affect. You might find that some applications do not receive an increase in performance by taking advantage of hyper-threading. If the physical processors are already saturated, using logical processors can actually reduce the workload achieved.
For example, applications that cause high levels of contention can cause decreased performance in a hyper-threaded environment. We recommend that you test your application thoroughly to make sure that a hyper-threaded environment provides you the performance gain that you want versus the purchase of equivalent physical CPUs. Hyper-threading can be very helpful but hyper-threading cannot replace the full power of an additional physical CPU.
The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about the performance or reliability of these products.”
출처 : http://support.microsoft.com/kb/322385/en-us

Hyper-V 관점에서는 64개 까지 LP를 지원 함으로 이에 따라 Hyper Thread 사용 여부를 판별 하면 됩니다.

Exchange는 아직까지는 Disable이 권고 입니다.

SQL Server는 2000까지는 Disable 이후에는 위에 언급한것과 같이 TEST후 적용 입니다.