CPU가 지원하는 쓰레드랑 프로그래밍 상의 쓰레드랑 다른건가요?

하드웨어 thread는 전통적인 의미의 thread 하고는 달라요. 다만 전통적인 의미의 thread 하나가 하나의 하드웨어 thread가 될 수는 있고요. 그런데, 전통적인 의미의 process 하나가 하나의 하드웨어 thread도 될 수 있어요.

하드웨어 thread가 푸는 문제는 한 전통적인 thread나 process 내의 instruction들 간의 의존관계 때문에 생기는 추가적인 delay예요. 설명을 쉽게 하기 위해 core 안에 functional unit이 하나 있어서 한 번에 한 instruction밖에 처리 못한다고 해보죠. 한 프로그램/프로세스/쓰레드에 속하는 두 인접한 명령어는 흔히 의존관계가 있기 쉽습니다.

A[i] = B[i] * c;

이게 어셈블리로 바뀌면, 보통 B[i] load 한 번, 곱셈 한 번, 그리고 A[i] store 한 번일 텐데, 이 셋은 순서대로 이뤄져야 하죠. 만에 하나 load가 몇 사이클 걸린다면, cpu는 그 몇 사이클 동안 놀고 있어야 하구요.

하드웨어나 컴파일러가 수행되는 인스트럭션들의 순서를 좀 바꿔서 그 빈 자리를 채우기는 하지만, 기본적으로 그것도 프로그램/쓰레드/프로세스의 논리적 의존관계가 허용하는 한계 내에서이기 때문에 한계가 있습니다.

이런 문제는 주로 의존관계 때문에 생기고, 의존관계는 인스트럭션들이 하나의 computation(프로그램/프로세스/쓰레드)에 함께 속한다는 사실에서 파생되죠.

그래서 사람들이 생각해 낸 게, 그럼 쓰레드든 프로세스든 뭐든 여러 개를 갖고 있으면서 cpu core한테 인스트럭션을 뒤섞어서 줘보자는 거죠. 예컨대 쓰레드 두 개를 들고, 한 번은 0번, 한 번은 1번에서 명령어를 갖다가 cpu core한테 주게 되면, core가 더 부지런하게 돌게 되겠죠.

거칠게 말하면 이게 질문하신 분이 말씀하시는 CPU thread에요. 그런데 이런 하드웨어 thread는 꼭 소프트웨어 세계에서 전통적으로 널리 쓰이던 thread일 필요는 없죠. 서로 다른 두 프로세스여도 되고요. 뭐든 거기서 각각 뽑아낸 인스트럭션들 사이에 서로 의존관계가 없기만 하면 괜찮습니다.