멀티코어 프로세서

 

1. 개요
2. 상세
2.1. 역사
2.2. 멀티코어 프로세서를 제대로 활용하려면? : 멀티스레드 프로그래밍
2.3. 어떤 식으로 구현하는가? : 멀티스레드 프로그래밍 패턴
2.3.1. 공유 메모리 모델
2.3.2. 메시지 전달 모델(생산자-소비자 패턴)
2.4. 구현하려면 무엇이 필요하는가? : 지원하는 프로그래밍 언어와 라이브러리
2.5. 멀티코어 프로세서의 종류
2.5.1. 멀티코어 CPU
2.5.2. 멀티코어 GPU
3. 매니코어 프로세서
4. 관련 문서

프로세서의 코어 수에 따른 분류
싱글코어 프로세서
'''멀티코어 프로세서'''
매니코어 프로세서
하이브리드 프로세서

1. 개요




[image]
[1][2]
CPU 형태의 하나. 넓은 의미로는 CPU 형태가 어떻든 코어 여러 개를 구성하는 CPU나 코어가 1개인 CPU지만 여러 개의 CPU들을 구성한 시스템이지만, 2000년대 이후에는 하나의 CPU, 하나의 칩에 여러 개의 코어들이 집적된 형태를 가리키는 좁은 의미로 통하고 있다.
비전공자를 위해 쉽게 쓴 멀티코어 프로세서.

2. 상세



2.1. 역사


코어의 개수를 늘리는 쪽으로 CPU가 발전하게 된 것은 폴락의 법칙에 따라 면적(트랜지스터 수) 증가로만 성능 향상을 꾀하기에는 어려움이 있기 때문이었다.
CPU의 성능이 매년마다 기하급수적으로 증가한다고 해도 CPU 하나만이 처리할 수 있는 작업 속도에는 한계가 있다. 이 한계를 극복하기 위한 발상이 바로 "CPU 하나로 모자라면 '''많이 때려박으면 되지!'''"다. 이런 발상은 슈퍼컴퓨터 분야에서 사실 1970년대 이후로 보편화된 사고 방식이다.
PC 분야에서도 서버나 워크스테이션 등 고성능이 필요한 곳에서는 이미 한참 전부터 메인보드 하나에 CPU 소켓도 하나인 조합 자체를 여러 개 설치하거나, 메인보드 하나에 CPU(소켓) 자체를 여러 개 설치하는 방식인 '''멀티 프로세서(멀티 CPU)''' 형태로 고성능을 내 왔으나, 기술적인 문제로 하나의 CPU 다이 안에 코어 여러 개를 붙이는 '''멀티코어 프로세서(멀티코어 CPU)'''가 본격적으로 보급된 것은 2000년대 이후로 그리 오래되지 않았다.
지금과 같은 하나의 CPU에 코어 여러 개가 탑재된 형태의 멀티코어 프로세서는 2001년 IBMPOWER4 프로세서, 2004년 썬 마이크로시스템즈의 UltraSPARC IV가 먼저 출시되었다. 그러나 그 당시에는 메인프레임 이상의 규모에서만 공급되었기 때문에, 일반 가정용으로는 출시되지 않아서 잘 알려지지 않았다.
일반 가정용으로는 2005년 5월에 출시된 인텔 펜티엄D 시리즈AMD 애슬론 64 X2 시리즈를 필두로 본격적으로 보급되기 시작했다. 출시일 자체는 인텔의 프레스캇 두 개 붙인 스미스필드 펜티엄D가 6일 빨랐다. 나중에 관련 기술 책임자가 '9개월만에 급조한 CPU 치곤 잘 만들어졌다'는 인터뷰를 하기도 했다. 그러나 안 그래도 '여보 아버님댁에 프레스캇 놔 드려야 겠어요' 드립을 듣던 녀석을 두 개 붙인 바람에 클럭을 못 올려서(성능이 안 나와서) 망했다. 펜티엄 D는 그 이후 65nm 공정 개선판인 프레슬러까지도 애슬론 64 X2를 못 이겨서 빌빌댔으나, 2006년 7월에 넘사벽의 후배가 출시된 뒤에야 안심하고 가격 후려치기를 해서 비로소 역전했다. 그 넘사벽의 후배도 근간은 2003년 3월 모바일 전용으로 나온 펜티엄M에 사용된 P6라는 구형 마이크로아키텍처였다는 점을 생각하면...
인텔과 AMD 뿐만 아니라 IBM도 2005년 7월 7일에 POWER4 마이크로아키텍처 기반의 일반 가정용 타겟 프로세서인 PowerPC 970MP를 뒤늦게 발표했고, 애플은 PowerPC 970MP를 채택하여 2005년 10월에 Power Mac G5 Late 2005를 내놓았다. 콘솔 게임기도 2005년 11월에 출시된 Xbox 360부터, 2011년 이후에는 스마트폰, 나아가 인터넷 공유기도 멀티코어 프로세서를 쓴다. 심지어 피처폰도 !
하지만 멀티코어 프로세서는 단순히 프로세서를 두 개를 꽂는다고 두 배의 성능을 내는 게 아니다. 프로그램이 처리해야 하는 계산 작업 사이에서 여러 개의 프로세서가 맡아서 처리할 수 없어서 하나의 프로세서만 써야 하는 작업이 생기면 나머지 프로세서는 그 작업이 처리되는 동안 놀고먹는 모양새가 된다.이렇게 프로그램 내부에서 역할 분담(병렬화, Parallelization)이 되지 않는 부분이 많아지면 프로세서를 아무리 많이 때려박아도 성능 향상에 한계가 생긴다. 이를 전문 용어로 암달의 법칙(Amdahl's Law)이라 한다. 듀얼코어 시절에는 배부른 소리처럼 들렸겠지만, 지금은 쿼드 코어를 넘어서 헥사/옥타 코어도 시중에 유통되어 있고, 병렬 처리가 생명인 GPU는 프로세서를 수백~수천개 단위로 투입하니 위 법칙이 더욱 체감으로 다가오는 때다. 다만 암달의 법칙 자체는 일반적으로는 훨씬 폭넓은 용어이다. 정확하게는 "시스템 부하의 a%를 차지하는 부분이 n배 개선된다면 결과적으로 a*n%의 성능 향상만을 기대할 수 있다"는 아주 상식적인 소리에 불과하다. 이게 "암달의 법칙"으로 불릴 정도로 유명해진 이유는 (특히 병렬 컴퓨팅 분야에서) 이거 안 지키다가 폭망한 사례가 아주 많아서 그렇다.
이를 피하기 위한 기능으로 인텔 터보 부스트, AMD의 터보 코어[3]처럼 놀고 있는 프로세서는 파워게이팅이라고 전력공급을 차단해 버리고 남는 여유분만큼 일하고 있는 코어를 자동으로 추가 클럭을 넣어주는 식으로 싱글코어만 써도 어느 정도 성능 향상이 있도록 했다. 전력 공급 및 발열냉각설계는 멀티코어 모두 풀로 쓰는 기준으로 만들어 놨기 때문에 노는 코어가 있으면 다른 코어가 전력을 더 써도 된다. 단, 오버클럭은 부스트 때문에 성능이 향상되는 이유에 대한 간단한 이해를 돕기 위한 비유일 뿐, 실제 부스트로 들어가는 클럭은 제조과정에서 기본적으로 세팅한 것이므로 오버클럭이 아니다. 그래봤자 기본 설정 클럭에서 10~20%정도 밖에 안 올라가는지라 근본적인 해결과는 거리가 멀다. 물론 없는 것보단 10~20%라도 챙기는 게 확실히 낫기 때문에 세대가 올라갈수록 이 기술도 발전해 왔다. 여기 4번째 댓글에서 설명하는 것처럼, 모든 코어를 다 쓰는 상황에서도 여유가 되면 부스트 클럭이 들어가거나 내장 GPU를 쓰지 않는 경우 거기서 나오는 전력/발열 여유를 CPU 부스트 클럭 유지에 돌리는 등등 조금이나마 추가적인 성능 향상을 계속 가져온다. 특히 노트북이나 저전력판의 경우 전력 제한에 맞추기 위해 기본 클럭이 매우 낮고 성능도 그만큼 낮은데, 부스트 클럭은 상대적으로 그렇게 낮지 않은 경우가 많아서 부스트 클럭을 통해 쾌적한 환경에서 작업이 가능한 경우가 많다. 모바일용 i3와 i5의 가장 두드러지는 차이가 이것으로, i3는 터보부스트가 없으나 i5는 있다. 하지만 저 정도 차이는 어디까지나 노트북용 CPU 사이에서 뒤에 보통 U가 붙는 저전력 모델 한정. 일반적인 노트북 CPU만 해도 기본 클럭이 높은 쪽이 터보부스트를 씹어먹을 정도의 차이가 날 수 있는 경우가 많기 때문에 클럭 높은 놈이 깡패다.

2.2. 멀티코어 프로세서를 제대로 활용하려면? : 멀티스레드 프로그래밍


멀티코어와 멀티스레드 용어를 설명하기에 앞서 '''멀티코어는 "하드웨어 관점"에서의 물리적 구성 단위, 멀티스레드/멀티스레딩은 "소프트웨어 관점"에서의 논리적 작업 처리 단위'''라는 차이점이 있다. 당장 멀리 갈 것도 없이 Windows 기준으로 작업 관리자를 열어 보면 실행 중인 프로그램(프로세스)들이 코어 단위가 아닌 스레드 단위로 취급하고 있다. 과거에 코어와 스레드를 같은 개념처럼 취급했던 것은 '코어 개수 = 스레드 개수'인 CPU들만 존재하던 시대였기 때문이다. 그리고 SMT를 경험하려면 멀티 CPU 시스템인 슈퍼컴퓨터나 메인프레임이 사용된 서버, 데이터 센터, 그나마 스케일이 가장 작은 고성능 워크스테이션 말고는 기회가 없었다.
2002년에 인텔이 구현한 하나의 코어에 양방향 SMT 구현체인 하이퍼스레딩부터 일반 소비자들에게도 SMT가 본격적으로 알려지기 시작했지만 적극적으로 활용한 소프트웨어가 전무에 가까웠고, 코어2 시리즈에서는 하이퍼스레딩이 일시적으로 빠진 모습으로 지속되어서 소비자들이 잊고 지내다가, 2008년 1세대 코어 i 시리즈부터 하이퍼스레딩이 다시 도입되면서 '코어 개수 = 스레드 개수'가 항상 성립되는 것이 아님을 일반 소비자들에게 확실히 각인 시켜주었다.
참고로 하나의 코어에 양방향 SMT는 인텔이 먼저 상용화한 것은 맞지만, 하드웨어가 어떤 형태이든 상관없이 SMT 개념 자체는 인텔이 처음 만든 것이 아니고 1960년대에 진행했던 IBM의 ACS 프로젝트를 통해 등장한 오래된 개념이다. 단지, 하이퍼스레딩 덕분에 싱글코어 싱글스레드 CPU만 존재했던 일반 가정용에서도 SMT를 경험할 수 있게 되었을 뿐이다. 그리고 2000년대 초중반에 특수 분야에서 이미 등장한 지금같은 CPU 하나에 코어 여러 개 탑재된 멀티코어 CPU 시스템이 2005년부터 일반 가정용에도 대중화되면서 하이퍼스레딩같은 기능을 굳이 지원하지 않아도 SMT를 경험할 수 있게 되었다. 따라서, 소프트웨어를 만드는 과정인 프로그래밍 관점에서는 코어 단위가 아닌 스레드 단위를 기준으로 취급한다.
게임용 3D 그래픽 API의 대표격인 DirectX의 Direct3D도 비슷한 문제를 겪고 있다. Direct3D 10 세대까지는 멀티스레드와는 인연이 없는 라이브러리였기 때문에 구현하려면 Win32 API, POSIX Threads의 약자인 Pthreads같은 다른 라이브러리를 이용해서 구현해야 했다. Direct3D 11부터 Direct3D에도 멀티스레드 기능이 정식으로 도입되었으나 일부 레벨만 구현된 형태라서 전체적인 효율이 아쉬웠는데, Direct3D 12부터 유저 드라이버 모드에도 멀티스레딩을 지원하면서 하드웨어 직접 접근을 지원하면서 전체적인 효율이 개선되었다. Direct3D 12의 발표 자료를 보면, Direct3D 11은 쿼드코어에서 돌릴 경우 첫 번째 스레드(스레드 0)가 다른 스레드보다 오래 걸리는 바람에 그만큼 나머지 3개 스레드들이 놀게 된다. 반면 Direct3D 12는 해당 부분도 4개의 스레드에서 나눠 처리하게 하거나, 아예 해당되는 처리 자체를 줄여서 멀티스레딩의 효율과 속도를 높였다. 관련 문서를 보면 알겠지만 OpenGL도 마찬가지라서 Vulkan을 만들었다.
Microsoft DirectX Blog 에 올라온 DirectX 12 정보[4]
[image]
실제로 Direct3D 12를 이용해서 구현하면 스레드들이 항상 위의 그래프대로 뽑을 수 있는 것은 아니다. 동작 원리가 저런 식이라는 정도로만 참고할 것.
따라서 CPU에 박힌 코어 여러 개의 성능을 제대로 끌어내려면 여러 개의 코어에게 일거리를 효율적으로 배분하도록 프로그램을 멀티스레딩 구조로 짜 줘야 한다. 멀티스레딩에 최적화가 되어있지 않은 프로그램은 CPU 처리량이 더 필요해도 다른 코어의 도움을 받지 못하고 1번 코어에서만 비비적대며 돌아가거나, 심지어는 '''일감을 달라고 저희들끼리 싸우는 동안 실행 속도는 오히려 더 떨어져 버리는''' 참사가 벌어질 수 있다. 파이썬 인터프리터가 한 때 이 문제 때문에 까인 적이 있다. 따라서 실행 성능이 중요시되는 프로그램, 특히 게임은 처음 프로그램을 짤 때부터 멀티코어 프로세서를 생각해야 되는 시대가 되었다.
하지만 멀티스레딩을 이용한 병렬 프로그래밍 자체의 어려움과 직렬화에 가까운 게임 프로그래밍의 특성 상 게임은 멀티코어 프로세서가 대중화된 시대임에도 많은 수의 게임들이 동서양을 가리지 않고 멀티코어를 제대로 활용하는 모습을 보기 어렵다. 이는 딱히 기술력이나 돈의 문제 이전에 병렬화로 성능 향상을 꾀할 수 있는 부분이 게임에서 극히 적을 뿐더러, 적용한다고 해도 성능 향상이 없거나 오히려 더 성능이 내려가기 때문이다. 게임은 실시간으로 모든 요소들이 정확히 동시에, 개발자가 의도한 순서대로 플레이어에게 보여져야 하는 프로그램이다. 코어별로 따로 나눠 작업 돌려서 작업에 차이가 발생하면 플레이어 캐릭터는 등장하지만 NPC 1은 아직 연산이 안되었다고 안 나오고 화면은 나오는데 소리는 안 나오는 이런 상황 만들 수는 없어서 병렬화가 어렵다. 지금도 일부 AAA 게임들만이 4스레드 이상을 지원하는 형편이며, 대다수 게임들은 멀티스레딩을 지원한다 해도 별 의미 없는 경우가 대부분이다.
물론 요소별로 나누는 것은 가능해서 가령 물리연산만 따로 빼서 돌린다던가 하면 싱글스레드만 지원하는 게임보다는 낫겠지만 그런 경우도 물리연산 자체는 스레드 1개만 갈구게 되어 한계가 생기며, 게임 루프 자체의 기본적인 순서는 유지되어야 하므로(해당 프레임의 업데이트가 먼저 이루어져야 해당 프레임에 대응되는 렌더링을 수행할 수 있으니까) 무작정 요소별로 스레드를 뽑아서 돌리면 렌더링은 다 되었는데 업데이트가 아직 안 되어서 버벅거리는 현상이 발생할 수 있다. 이것이 2000년대 중반부터 2010년대 초반까지의 멀티스레딩 지원 게임들로부터 드러난 문제점이었다.
게다가 이 각 요소들이 서로 관계를 맺으면 더욱 더 골치아파진다. 플레이어 캐릭터와 NPC와 아이템이 각각 다른 스레드에서 돌아가고 있다고 가정할 때, 플레이어가 NPC에게 아이템을 주는 장면은 어느 스레드가 맡아야 하는가? 하는 식의 문제이다. 다른 셋이서 협동해서 진행하면 이상적이겠지만 이들간에 약간의 시간차만 나도 플레이어는 아이템을 줬는데 NPC는 못 받았고 아이템은 엉뚱한 데 가버리는 심각한 문제가 발생하게 된다. 이는 매우 골치아픈 디버깅 문제를 소환하기도 한다. http://m.dcinside.com/board/rlike/321084#$ 이런 상황을 프로그래머가 전부 예측하는 것은 불가능에 가깝다. 다른 것 보다도 이거 때문에 지원이 어려우며, 특히 이는 싱글스레드 프로그램을 멀티스레드 기반으로 옮기기 아주 힘들게 하는 장벽으로 작용한다. 차라리 새로 짜는게 낫다는 평가가 나올 정도.
싱글스레딩의 한계를 극복하기 위해 돌리는 시간이 짧은 시뮬레이션은 그냥 싱글스레드용으로 짠 다음에 시간이 긴 구간은 스크립트를 써서 스레드 여러 개를 동시에 돌리는 식의 기법도 사용되고 있으나 효율은 생각보다 좋지 않다.
그러나 실제로는 멀티스레딩을 지원하지 않는 프로그램이라도 멀티코어 프로세서 환경에서 충분히 성능 향상을 얻을 수 있다. OS에선 자신이 프로그램을 실행하지 않아도 기본적으로 OS에서 알아서 관리하는 수많은 시스템 프로그램이 실행되고 있다. Windows 기준으로 작업 관리자의 프로세스 탭에 몇 개의 프로세스가 있는지 세어 보자. 멀티스레딩을 지원하지 않는 프로그램과 기본적으로 실행되고 있는 프로그램을 다른 스레드로 나눠서 처리하면 성능 상의 이득을 얻을 수 있는 것이다. 코어 한 개 범위 내에서 빨라지는 거긴 하지만 그게 어딘가. 단 그게 최근 게임에서 일어나는 일이라면 확실히 문제일 수도 있다. Python으로 개발된 EVE 온라인 같은 경우인데, Python의 특성 상 단일 동작은 반드시 싱글스레드에서 수행되어야 하기 때문에 위와 같은 방식으로 멀티스레딩에 최적화되어 있고, 과부하가 걸리면 이것도 한계가 오게 된다.
어쨌든 각 코어의 연산 능력도 뛰어나야 하며, 이 코어들간의, 스레드간의 데이터 연계 능력이 뛰어나야 좋은 멀티스레딩이 된다.
멀티코어 프로세서를 산다면 코어 개수가 자신이 쓰려는 목적에 맞는지 보고 구매할 것을 권고한다. 예를 들어 코어 i3-6100(3.7GHz)은 i5-6600(3.3GHz)보다 10만원 정도 가격이 저렴하지만 단일 코어 클럭은 400MHz 정도 더 높다. 그러나 이것은 명목상 스펙이고, 실제로는 i5-6600이 터보부스트로 3.9GHz까지 올라가지만 i3-6100은 그런 거 없기 때문에 실제 성능 차이는 더 줄어든다. 일반적으로 쿼드코어 쪽이 더 좋은 성능을 발휘하지만, 단일 스레드로만 구동이 되는 프로그램을 사용할 경우엔 오히려 클럭이 높은 듀얼코어 쪽이 더 성능이 좋게 느껴질 수 있다는 것. 그러니 여러모로 고려해보고 구매하자. 당연하겠지만 그래픽 툴이나 컴파일러를 쓰는 앱 개발 툴 등 뭔가를 '''생산해야 하는''' 환경에서는 대부분 멀티스레딩 잘 지원되어 있어서 코어 수가 깡패다. 물론 '''예외의 경우'''도 있기 때문에 자신이 쓰는 프로그램과 게임을 보고 판단해야 한다. 사실 어도비도 어지간하면 8스레드까지는 지원해 주지만, 역시 전문가용 소프트웨어를 찍어내는 것 치고는 빈약한 것이 사실이다.
대표적인 예 중 하나인 스타크래프트 2는 모든 물량을 죄다 CPU로 처리하는 데 고작 스레드 2개까지만 지원한다. 일반전에서는 문제가 없지만 물량이 쏟아져 나오는 협동전에선 고클럭 CPU가 아닌 이상 렉걸린다. 처음부터 2스레드 기반으로 설계한 것이 큰 잘못이다. 다른 예론 어도비 계열 소프트웨어들. 산업 표준이라는 말이 나올 정도로 여러 분야에서 압도적으로 많이 쓰이는 프로그램에 멀티스레딩을 아예 지원하지 않는 것은 아니지만 최적화가 정말로 좋지 않고 전문가용 소프트웨어답지 않게 싱글스레드(고클럭 및 높은 IPC) 성능에 의지하고 있다. 이 때문에 싱글스레드 성능이 우수한 일반 데스크탑용 CPU가 현존 8코어가 최다 코어라서 그 이상으로 아무리 코어 개수가 많아봤자 일반 데스크탑용보다 많은 코어 수의 구성을 위해 레이턴시가 늘어져 싱글스레드 성능이 떨어질 수밖에 없는 HEDT/워크스테이션/서버용 CPU는 의미가 없을 정도. 물론 멀티스레딩에 제대로 최적화된 기능은 싱글스레드 성능이 낮더라도 코어 개수만큼 제대로 성능을 내 준다.
"클럭 × IPC = 성능"인 싱글코어와 달리 캐시나 아키텍처의 기여도가 더 높아져서 클럭 × IPC가 스펙만큼 나타내진 못하는 바람에 더 높은 클럭임에도 성능이 오히려 낮은[5] 경우가 있어서 과거와 달리 클럭이 높다고 무조건 좋은 제품이 아니며, 일반유저가 좋은 제품을 고르는게 다소 애매해졌다. 그 대신 전체적으로 어떤 CPU를 선택해도 큰 불편 없이 사용할 수 있는 수준이 되었다.
결국 '코어 하나당 성능 * 코어 개수 * 멀티스레드 활용률'의 세가지 지수를 모두 보아야 CPU 성능을 어느정도 정확하게 가늠할 수 있다('코어 하나당 성능'은 다시 '클럭당 성능(IPC) * 클럭'으로 세분화 할 수 있다.). 펜티엄 20주년 에디션(G3258 AE)을 오버클럭해서 '코어 하나당 성능'을 높이면 i3-4150을 제치고 상당수 게임 성능에서 AMD FX 시리즈는 물론이고 인텔 코어 i7(블룸필드)까지 제치는 모습이 대표적. 하지만 '멀티스레딩 활용률'이 더 높은 게임(배틀필드 4 등)에서는 듀얼코어의 한계를 보이면서 뒤쳐진다. 물론 다른 게임들에서도 위 CPU들도 오버클럭을 하면 다시 상황이 역전되기도 하지만, 배틀필드 4에서는 '멀티스레딩 활용률' 때문에 그럴 필요조차 없이 뒤쳐진다는 것이 포인트.
네이티브 듀얼코어와 쿼드코어의 경우엔 이 방식이 아니고 그냥 다이 하나에 여러 코어를 올린 것보단 전력을 적게 먹으며, L2 캐시 공유 등의 기술을 탑재하고 나오기 때문에 성능이 좀 더 좋아지는 경향이 있으나, AMD 페넘 시리즈의 경우 코어 개개의 성능이 매우 떨어지는 관계로 듀얼코어 두개를 붙여 쿼드코어를 만든 인텔 코어2 쿼드에 처절하게 패배했다. 반면, 코어 개개의 성능이 좋은 편인 인텔 코어 i7(블룸필드)의 경우, 하이퍼스레딩까지 탑재하면서 AMD에게 넘사벽을 선물했다.
대표적인 성공작은 "AMD 애슬론64x2 시리즈", "AMD 옵테론 시리즈", "인텔 코어2 시리즈", "AMD RYZEN 시리즈"이다.
온라인 IT 매거진 PCBee에서 2007년 1월 코어2 쿼드의 런칭에 맞춰 쿼드지수 측정 웹페이지를 제공하기도 했다. 일종의 멀티 스레드 연산 테스트로 기본 클럭 Q6600의 성능을 100으로 치고 유저의 CPU 성능이 어디까지 나오는지를 측정해 준다. 당시에는 꽤 정직한 결과를 보여줘서 대략적인 CPU 성능을 가늠해볼 수 있는 휼륭한 지표였지만, 시간이 지나 웹 브라우저에서 자바스크립트 엔진 성능에 신경쓰게 되면서 같은 스크립트라고 해도 IE 6 시절보다 몇 배는 빠르게 실행시킬 수 있게 되어 멀쩡한 수치가 나오지 않게 되었다. 같은 노오버 Q6600이라고 해도 IE 9에서 쿼드지수를 측정하면 300점 가량 나온다고 하므로 당시 기준의 점수로 환산하려면 대략 1/3 정도로 계산해주면 될 듯 하다. 물론 IE 역시 11 버전까지 업그레이드되고 크롬 등의 다른 웹 브라우저라면 같은 환경에서 더 높은 점수가 나올 수도 있다. 코어 i5 쿼드코어 제품군을 4GHz 정도까지만 오버해도 600이나 700 같은 정신나간 수치가 나오게 되었고, 2700X+크롬 조합으로 1700점은 그냥 나온다. 덕분에 성능이 아득히 올라가 버린 시스템들의 점수로 인해 TOP 10 그래프는 와장창 깨져 있다. 게다가 AMD RYZEN 시리즈의 득세로 주력 CPU가 헥사코어~옥타코어로 올라가 버려서 해당 사이트의 "쿼드코어를 넘는 것은 쿼드코어 뿐이다" 문구가 무색해진 지 오래.
x86 호환 CPU의 경우 AMD RYZEN 시리즈의 '''64코어 128스레드'''인 스레드리퍼 3990X는 $3,990, 인텔의 18코어 36스레드인 코어-X 시리즈의 i9-10980XE는 $1,000이다. AMD FX 시리즈의 8000 시리즈와 9000시리즈는 8코어 8스레드이며 AMD RYZEN 시리즈의 라이젠 7은 8코어 16스레드이다. FX-8xxx의 경우 네이티브 여부가 이견이 갈린다. 2코어 1모듈이라 실질적으로는 4코어라고 해야 한다며 소송을 당하기도 했다. 서버용으로는 인텔 제온 스케일러블 시리즈 중 최상위 플래티넘 시리즈랑 제온 W-시리즈 중 최상위 라인은 28코어 56스레드를, AMD EPYC에서는 '''64코어 128스레드'''까지 출시되어 있다.
그 외에 모바일 ARM 계열로는 퀄컴 스냅드래곤엑시노스 등 여러 종류가 있다. 아키텍처가 달라서 당연히 x86 호환이 안 된다.
2017년 하반기 이후 AMD의 라이젠이 늘어난 코어 수와 함께 대성공하면서 위기의식을 느낀 인텔도 그에 따라 코어 수를 올리기 시작하여 멀티코어의 기준이 4코어에서 6~8코어로 많이 올랐다. 라이젠 이전에는 예전부터 i7마저도 4코어로 유지되었지만 라이젠 이후에는 i5도 6코어로 늘어났으며, 2018년 10월부터는 코어 i9가 일반 데스크탑용 라인에도 나오면서 8코어로 증가되었다. 최고사양을 요구하는 AAA 게임쪽도 이젠 8코어 기준으로 제작하거니와 테스트에 의하면 8코어를 다 쓰면서 CPU 사용률이 4코어에 비해 많이 낮다는 점이다. 당장 엑스박스 원플레이스테이션 4 둘 다 저전력, 저클럭이지만 엄연히 8코어 8스레드 CPU다. 이것 역시 AMD의 작품. 전문 소프트웨어는 이미 오래전부터 멀티스레드에 큰 영향을 받으므로 별 상관없지만 소프트웨어 시장이 큰 변화가 오고 있다는 것. 덕분에 어도비처럼 멀티코어 프로세서를 위한 멀티스레딩 지원 및 패치를 게을리하거나 안 하는 회사들이 점점 욕 얻어먹기 시작하고 있다. 다행히도 어도비 라이트룸처럼 스레드 12개까진 제대로 지원해주는 업데이트가 나온 상태지만 여전히 한계가 존재하고 있다. 이건 소프트웨어를 다시 만들지 않는 이상 힘들 수 밖에 없다.
2019년 기준으로 테스트한 결과, 최신 게임들은 멀티스레딩을 제대로 지원하고 있다. 이미 2017년부터 스레드 4개는 이젠 더 이상 쓰기 힘들정도로 요구 스펙이 높아졌으며 게임에 따라 스레드 8개에서 최대 16개까지 지원하는 상태다. 평균 프레임만 봐도 6코어 6스레드와 8코어 8스레드간 20 FPS씩이나 차이는 게임도 있으므로 확실히 최신 게임들은 8코어 8스레드 혹은 그 이상을 기준으로 개발되고 있는 셈이다. 물론 최적화나 기타등등까지 따져봐야하므로 성능차가 생길 수 있다. 게임+방송까지 해야한다면 스레드 16개인 CPU나 아예 방송용 컴퓨터를 조립해야할 정도로 요구스펙이 굉장히 높으므로 게임이라도 코어 개수가 많으면 좋을 수 밖에 없는 상황인데 이게 무려 FHD 기준이다. 4K는 말그대로 포기하는 게 좋을정도. 다행히 실시간 인코딩만큼은 CPU가 아닌 그래픽카드에게 전담할 수 있는 있기 때문에 최신 그래픽카드가 있다면 CPU의 요구 사양을 어느 정도 낮춰 실시간 4K 인코딩이 가능해졌다.

2.3. 어떤 식으로 구현하는가? : 멀티스레드 프로그래밍 패턴


프로그래밍에서도 멀티 프로세서나 멀티코어로 인한 성능을 온전히 활용하기 위해 몇 가지의 코드 패턴이 연구되었다. 이해를 돕기 위한 예시를 들어보겠다.
이미 완성된 프로그램이 하나 있다. 해당 프로그램은 이미지를 입력받으면 전체의 픽셀을 반복문으로 순회하며 해당 픽셀의 RGB값을 각각 5씩 낮추는 프로그램이다. 그러나 이 프로그램은 스레드를 하나만 쓰는 싱글 스레드 프로그램이다. 이 프로그램을 멀티코어를 사용하도록 바꾸려면 어떻게 해야 할까?

2.3.1. 공유 메모리 모델


모든 코어/스레드가 하나의 메모리 공간을 공유하는 모델이다. 하나의 코어가 메모리에 쓰기 작업을 하려고 하면 먼저 해당 메모리 공간이 쓰기 가능한지(다른 스레드가 이미 작업 중인지)를 알아보고, 만약 사용 가능하다면 해당 메모리 영역에 잠금(lock)을 걸고 쓰기를 한다. 쓰기 작업이 완료되면 잠금을 해제하여 다른 스레드가 사용 가능하게 한다.
위의 예시로 들자면 잠금을 이미지에 걸고, 픽셀의 값을 읽고 쓰기 전까지 다른 스레드가 픽셀을 건드리지 못 하도록 막는 방법이다. 단순히 잠금장치만 추가하고 해당 일을 하는 스레드를 많이 추가하면 되기에 이미 싱글스레드로 구현된 코드를 멀티스레드로 변환하기 쉽다는 장점이 있으나, 잠금 매커니즘이 관리가 까다롭고 성능 병목이 발생한다는 단점이 있다. 예를 들어 어떤 스레드가 잠금을 획득한 상태로 죽어버리거나(데드락), 두 개의 스레드가 경쟁적으로 잠금을 획득하려고 한다거나(레이스 컨디션), 서로 상대방의 스레드가 '잠가 놓은' 리소스를 획득하기 위해 무한히 대기하는 경우(스타베이션)가 발생할 수 있다. 또한 잠금을 확인하는 시점에서 모든 스레드가 동기화되어야 하기 때문에 가장 느린 스레드의 속도에 다른 모든 스레드의 속도가 맞춰져 버리는 단점이 있다.
만약에 스레드간 공유되는 자원이 아예 없다면 락 없이 빠른 병렬성을 보장한다. 거대한 배열에 관한 작업들은 CPU 캐싱이 잘 되게 짤 수 있어서 더욱 그렇다. 위의 이미지 예시를 들어보자면 이미지 자체를 하나의 리소스로 보지 말고, 행 하나하나를 리소스로 보고 스레드 개수로 분할할 수도 있을 것이다. 물론 사양표나 테스트를 통해 해당 작업이 Thread-safe인지 반드시 확인해야 한다. 만약 800x600인 이미지를 4개의 스레드로 쪼갠다면 각 스레드가 800x150의 영역을 담당하여 스레드 0이 0~150번째 행, 스레드 1이 150~300을 담당하는 식으로 서로간의 간섭(혹은 메시지 통신) 없이 메모리의 독립적인 부분에 대한 처리를 하게 된다. 이렇게 분할해서 가져가면 스레드가 가져간 이미지 조각들도 결국 연속된 배열이기 때문에 CPU 캐시 미스 거의 없이 빠르게 처리된다.
이러한 연산에 메시지 전달 작업 모델을 이용하면 꽤 느려질 위험성을 내포한다. 첫 번째 이유는 메시지 큐(통신 채널)를 사용하는 오버헤드이다. 현용 메시지 큐는 락 없이 최대한 빠르게 동작하도록 설계되긴 하지만 어쨌든 큐에 일감을 넣고 빼는 작업 자체도 CPU 클락이 소모된다. 실제 작업 자체가 간단한 수식 작업일 수록 큐 작업의 오버헤드의 비율이 커져서 비효율적이게 된다. 두 번째 이유는 각 스레드는 메시지 큐에서 일감을 메모리 영역에 대한 일관성이 없이 가져가기 때문에 CPU의 캐시 미스가 더 많이 일어나서 느릴 수 있다는 것. 따라서 벡터곱, 행렬곱, 텐서곱과 같은 균일한 배열에 대한 연산의 병렬화 모델은 메모리 공유 모델을 사용한다.
GPU는 공유 메모리 모델을 사용한다. 위에서 언급한 잠금 관리의 '까다로운' 부분은 하드웨어와 드라이버(런타임 라이브러리)에서 어느 정도 관리해주기 때문에 CPU보다는 편하게 병렬 프로그램을 작성할 수 있다.

2.3.2. 메시지 전달 모델(생산자-소비자 패턴)


위의 공유 메모리 모델과 달리 모든 작업 스레드(워커 스레드)가 완전히 격리된 메모리 공간을 할당받는다. 스레드간 데이터 교환은 통신 채널을 통해 서로 메시지를 교환함으로써 이루어진다.
통신 채널은 비동기로 동작하며 워커 스레드는 자신이 메시지를 받을 준비가 되었을 때에 자신의 메일박스(또는 메시지 큐라고 하기도 한다)에 들어온 메시지를 순서대로 읽어 처리한다. 공유하는 메모리가 없기 때문에 잠금 매커니즘을 사용하지 않으며 비동기이기 때문에 빠른 스레드는 느린 스레드의 작업 완료를 기다릴 필요가 없다. 수신자의 메일박스가 가득차 더 이상의 메시지 수신이 불가능할 경우는 예외. 이 경우에는 수신자의 메일박스에 빈 자리가 생길 때까지 송신자 스레드가 대기하거나 또는 메시지를 폐기한다.
위의 예시로 들자면 입력 스레드가 이미지에서 값을 읽어서 5를 빼는 워커 스레드(이 때는 '워커 스레드'가 소비자)에 던져주고, 워커 스레드는 자신의 결과값을 출력 스레드로 던진다(이 때는 '워커 스레드'가 생산자). 이 때 전달하는 메시지에는 픽셀의 x, y 좌표와 픽셀의 현재 값 c 세 개의 숫자값이 포함돼 있어야 한다. 공유 메모리 모델에서는 좌표값이 필요없으나(메모리 주소 자체가 좌표값 역할을 한다) 메시지 전달 모델에서는 어떤 스레드가 작업을 먼저 끝낼지 모르기 때문에 위치와 색상값이 모두 필요하다. 출력 스레드는 워커 스레드가 던진 x, y, c 메시지(여기서 c는 처리가 끝난 즉 5를 뺀 값)를 읽어서 자신의 메모리에 최종 결과를 쓴다.
위에서 보는 바와 같이 메시지 전달 모델에서는 입력, 워커, 출력 스레드가 각자 격리된 메모리 공간을 소유하므로 메모리의 공간적 부담이 늘어나는 단점이 있다. 워커 스레드의 '메모리'는 보통 CPU의 내부 캐시 메모리에서 처리되기에 충분할 정도로 작기 때문에 메모리 통신 대역폭 계산시 보통 무시되는 편이다.
공유하는 메모리가 없으므로 메시지는 CPU 내부 코어간은 물론이고 인접 소켓의 CPU나 네트워크를 통해 다른 컴퓨터의 CPU에까지 무리 없이 전달할 수 있어서 규모 확장이 쉽다.
특성 상 각자 스레드가 자신이 낼 수 있는 최고 속도로 동작할 수 있고(생산자 스레드는 값을 읽어서 던져주기만 하면 끝, 소비자 스레드는 변환해서 다시 던져주기만 하면 끝) 프로세서가 동등한 관계가 아닐 경우에도 유용하게 쓰일 수 있으나(CPU-저장장치간 통신인 파일 저장 코드, CPU-네트워크간 통신인 네트워크 연결 코드 등등) 기존에 구현된 코드를 변환하기에 손이 많이 가고, 위에서 언급했다시피 메모리를 일관성 없이 참조해 CPU 캐시 적중률이 수직 하락하는 단점이 있다.
실행 주체 하나하나가 독자적으로 동작하는 함수형 언어가 병렬 프로그래밍을 잘 지원하는 방식이기도 하다.

2.4. 구현하려면 무엇이 필요하는가? : 지원하는 프로그래밍 언어와 라이브러리


멀티 코어를 이용하는 가장 기초적인 방법은 운영체제가 지원하는 스레드 생성 API를 이용해서 스레드를 생성하고, 일감 분배, 데이터 분산, 처리 및 결과값 도출을 직접 짜는 것이다. 스레드를 각 코어에 올려서 실행시켜주는 것은 운영체제의 몫이며 프로그래머의 역할은 데이터를 각 스레드별로 적절하게 분배해서 싣는 것이다. Unix 환경에서는 POSIX 스레드에서 따온 Pthread라는 멀티스레드 API 중
pthread_create
를 이용하여 스레드를 만들 수 있고, Windows 환경에서는
CreateThread
또는
_beginthread
를 이용한다.
스레드 생성과 관리와 동기화 구현을 컴파일러가 생성하도록 하고 병렬 처리에만 집중하고 싶다면, 다시 말해서 좀 더 쉽게 구현하고 싶다면 OpenMP ARB의 OpenMP나 인텔의 스레드 빌딩 블록(TBB: Thread Building Block), MS의 병렬 패턴 라이브러리(PPL: Parallel Pattern Library) 등을 사용할 수 있다. 기존 C/C++ 문법에 directive 같은 간단한 코드를 추가해서 어떤 루프를 병렬화 할지를 알려주기만 해도 쉽게 병렬화를 할 수 있다. 물론 동기화를 어느 곳에서 해야 하는지 알려 줘야 하며, 사용할 수 있는 범위가 제한되는 제약 조건을 유의해야 한다.
Java, Python, C\# 같은 더 고레벨 언어의 추상화된 모델을 사용한다면 각 언어가 지원하는 멀티스레딩, 멀티프로세싱 라이브러리를 사용해야 한다. 가령 파이썬 같은 경우 multiprocessing 모듈의 Process와 Queue를 사용해서 메시지 전달 패러다임을 구현할 수 있다. 만약 배열에 대한 map 연산을 각 코어에 싣고 싶다면 multiprocessing 모듈의 Pool 객체의 map 메서드를 사용하면 잔 코딩 없이도 쉽게 작업을 분배할 수 있다. 자바에서는 병렬 스트림을 구현하는 메소드인 parallel()이나 parallelStream() 등이 있으며, C#에서는 Parallel 클래스를 통해 구현할 수 있다.
C, C++도 C11, C++11 표준부터 굳이 외부 라이브러리를 이용하지 않고도 표준 라이브러리를 통해 멀티스레딩을 구현할 수 있게 되었다. 단, 프로그래머가 병렬 프로그래밍 모델을 직접 수동으로 짜야 하는 단점이 있었으나 C++17 표준부터 일부 표준 템플릿 라이브러리(STL) 함수에 병렬화를 지원하면서 C++에서도 병렬 처리를 어느 정도 간편하게 구현할 수 있게 되었다.
다만 C11, C++11에 포함된 스레드는 생성, 종료와 같은 아주 기본적인 기능만 제공하고 있으므로 Thread Affinity 와 같은 더 세밀한 컨트롤을 위해서는 Win32Thread나 POSIX Threads를 사용하여야 한다.

2.5. 멀티코어 프로세서의 종류



2.5.1. 멀티코어 CPU


'''각각 코어 개수/스레드 개수이다.'''
인텔
CPU
6세대[6]
이전
7세대[7]
8세대[8]
9세대[9]
10세대[10]
코어 i9

8/16
10/20
코어 i7
4/8
6/12
8/8
8/16
코어 i5
4/4
6/6
6/12
코어 i3
2/4
4/4
4/8
펜티엄
2/2
2/4
셀러론
2/2
AMD CPU
1세대[11]
2세대[12]
3세대[13]
RYZEN 9[14]

16/32
RYZEN 9[15]

12/24
RYZEN 7
8/16
RYZEN 5[16]
6/12
RYZEN 5[17]
4/8
6/6
RYZEN 3[18]
4/8
RYZEN 3
4/4
Athlon

2/4
데카코어까지는 라틴어/그리스어 듀얼코어, 쿼드코어, 옥타코어 식으로 잘 부르지만, 10을 넘어가는 라틴어/그리스어 어근은 영미권에서도 거의 사용하지 않기 때문에 그냥 숫자로 부르는 사람이 더 많다. 예를 들어 16코어는 '헥사데카코어'보다는 '식스틴 코어'라고 부른다.
  • 듀얼코어 - 2코어. 2개의 연산 회로가 한 다이 위에 존재하며, 대표적으로 인텔 펜티엄 D를 기점으로 대중화되었으며, 현재는 사실상 최하위 CPU의 마지노선으로서, 일반 판매용으로는 아무리 저가형으로라도 듀얼코어로 만들지 절대로 싱글코어로 생산되지 않는다. 대표적으로 인텔 셀러론펜티엄 시리즈, AMD 애슬론 시리즈가 있다.
  • 트리플코어 - 3코어. 대표적으로 AMD 페넘 X3, 페넘 II X3, 애슬론II X3. 사실 네이티브 쿼드코어나 듀얼코어 두개 붙이기의 변종에 불과하지만… 여담으로 Xbox 360[19]Wii U의 CPU도 트리플코어이고 아이패드 에어 2의 A8X도 트리플 코어이다. 현재는 거의 사장된 방식.
  • 쿼드코어 - 4코어. 일반 데스크탑용으로는 코어2 쿼드, AMD 페넘 X4를 시작으로 오랜 시간 동안 일반 사용자용 프로세서에서 얻을 수 있는 가장 큰 코어 수였으나, 2017년 AMD RYZEN 시리즈의 출시를 기점으로 6코어가 메인스트림을 차지하며 저가형 라인업이 되었다. 인텔 코어 i3, AMD RYZEN 3 시리즈가 대표적 4코어 CPU.
  • 펜타코어 - 5코어. 테그라 3는 공식적으로 쿼드코어이지만, 800MHz로 작동하는 섀도 코어가 1개 존재해 사실상 펜타코어로 봐도 무방하다. big.LITTLE과 비슷한 기술이다. 투반에서는 오버클럭에 여유를 주기 위해 일부러 코어를 한 개 끄거나, 조스마에서 코어가 한개만 부활되었을 때 쓰는 오반(5 + 투반)도 있다. 노트북에서는 삼성 갤럭시 북 S가 인텔 레이크필드(4+1코어 빅리틀 구조)를 탑재하였다. 데스크탑 프로세서에서 채택한 사례는 없다.
  • 헥사코어 - 6코어. 2008년 경 서버용 프로세서[20]와 인텔 1세대 HEDT 프로세서[21]인 i7 익스트림 걸프타운부터 사용되기 시작하였다.
    일반 데스크탑 용으로는 페넘 II X6 투반이 어떻게든 i7을 상대 하기 위해 내놓은 것이 시작.[22] 투반 출시 당시까지만 해도 6코어를 다 이용하는 게임은 많지 않아 주류가 되지는 못했다. [23] 그리고 2017년 AMD RYZEN 시리즈의 성공으로 2~30만원대 메인스트림 CPU의 적정 코어 수가 되었으며. 현재 인텔 코어 i5, AMD RYZEN 5 시리즈가 6코어를 채택하고 있다.
  • 헵타코어 - 7코어. 일반적인 형태의 멀티코어 CPU는 아니지만 PS3CELL-Broadband Engine 프로세서 중 SPE(Synergistic Processing Elements)가 이에 해당된다. SPE는 본래 8코어가 풀칩이었으나, 수율 문제로 코어 1개가 비활성화된 채 생산되었기 때문에 사실상 7코어라고 볼 수 있다. 자세한 내용은 문서 참조. 이 역시 데스크탑 프로세서에서 사용된 사례가 없다.
  • 옥타코어 - 8코어. 2010년경 서버용 프로세서[24]에서부터 사용되기 시작했다.
    일반 데스크탑 프로세서에서 사용된 것은 6코어와 같이 2011년 AMD FX 시리즈였지만, 본격적으로 대중화된 것은 마찬가지로 2017년 출시한 AMD RYZEN 시리즈.
    현재 중고급형 CPU가 8코어를 채택하고 있다. (인텔 코어 i7, AMD RYZEN 7 시리즈)
    또한 엑스박스 원플레이스테이션 4에 들어간 APU도 AMD 8코어이다.
  • 데카코어 - 10코어. 인텔의 Xeon 라인업에서 찾아볼 수 있었다.[25]. HEDT용으로는 브로드웰-E의 i7-6950X가 최초의 HEDT용 10코어다. 일반 데스크탑 프로세서에서는 사용되지 않았으나, 인텔 10세대 코어 i 시리즈의 i9-10900K가 10코어 20스레드를 채택하였다.
    또한 미디어텍의 모바일 AP 중 하나인 미디어텍 Helio가 데카코어다[26]
  • 12코어 - 서버용 프로세서에서 주로 사용되었으며,[27] HEDT용으로는 인텔 스카이레이크-X의 i9-7920X, AMD RYZEN 시리즈의 쓰레드리퍼 1920X, 2920X가 있다.
    일반 데스크탑 프로세서로는 라이젠 9 3900X가 있다.
  • 14코어 - 서버용으로는 인텔의 하스웰-EP Xeon E5-2697 v3, 브로드웰-EP Xeon E5-2690 v4, HEDT용으로는 스카이레이크-X i9-7940X.
  • 15코어 - 대표적으로 인텔 아이비브릿지-EX의 Xeon E7-8890 v2가 있다.
  • 16코어- AMD 계열에는 인터라고스라는 CPU가 있다. 이후 RYZEN의 출시와 함께 AMD가 도전하는 HEDT 라인인 쓰레드리퍼에서 1950X가 등장했다. 세계 최초의 HEDT용 16코어 32스레드 CPU. 2세대는 2950X로 등장하였다. 인텔 계열은 브로드웰-EP Xeon E5-2697A v4, 스카이레이크-X i9-7960X가 있다.
    3세대 RYZEN에서는 무려 일반 소비자용인 라이젠 9 3950X가 출시되었다.
  • 18코어 - 대표적으로 하스웰-EP Xeon E5-2699 v3, 하스웰-EX Xeon E7-8890 v3가 있다. 또 인텔은 2017년 6월 경 AMD의 스레드리퍼가 최대 16코어로 출시된다는 소식을 듣자 허겁지겁 HEDT용 18코어 CPU인 i9-7980XE를 공개했다. i9-7980XE는 세계 최초의 HEDT용 18코어 36쓰레드 CPU이다.
  • 20코어 - 대표적으로 브로드웰-EP Xeon E5-2698 v4, 브로드웰-EX Xeon E7-8870 v4가 있다.
  • 22코어 - 브로드웰-EP Xeon E5-2699 v4가 있다. 6개월 먼저 나온 18코어인 E5-2697 v4의 L3 캐시 용량이 45MB였는데 이쪽은 코어 개수가 증가된 만큼 55MB로 팍 올라갔다. 출시 당시 가장 높은 성능의 CPU였는데 앞으로도 계속 외계인 고문으로 더욱더 괴물 CPU는 나올 것이다. 현재 아마존에 팔리고 있으며 4,317.07 $ 달러 환화로 510만 원가량 이다.
  • 24코어 - 대표적으로 브로드웰-EX Xeon E7-8890 v4, 스레드리퍼 3960X가 있다. 브로드웰-EX Xeon E7-8890 v4는 L3 캐시 용량이 무려 60MB다.
  • 26코어 - 대표적으로 스카이레이크-SP Xeon Scalable 프로세서 중 Xeon Platinum 8170이 있다.
  • 28코어 - 대표적으로 스카이레이크-SP Xeon Scalable 프로세서 중 Xeon Platinum 8180이 있다. 하지만 L3 캐시 구조가 변경되어 캐시 용량은 이전 세대인 E7-8890 v4보다 훨씬 적은 38.5MB로 감소되었다.
  • 32코어 - 엄청난 코어 개수로 AMD의 서버용 CPU인 EPYC 7601이 출시되었다! 그리고 이걸 HEDT용으로 내놓은 RYZEN 스레드리퍼 2990WX, 3970X도 있다. 인텔에서는 캐스케이드 레이크-AP Xeon Scalable 프로세서 중 Xeon Platinum 9222, 9221이 있다.
  • 48코어 - 인텔 캐스케이드 레이크-AP Xeon Scalable 프로세서 중 Xeon Platinum 9242가 있다.
  • 56코어 - 인텔 캐스케이드 레이크-AP Xeon Scalable 프로세서 중 Xeon Platinum 9282가 있다.
  • 64코어 - 무식한 숫자의 코어와 스레드 개수를 자랑하는 2세대 에픽 제품이 발표되었다. 코어 개수가 1년만에 2배가 되었는데, AMD가 통짜 64코어짜리 CPU를 만든 게 아닌 8코어짜리 CPU를 8개 합쳐서 만든 구조다. 그리고 이걸 HEDT용인 라이젠 스레드리퍼 3990X로 내버렸다.

2.5.2. 멀티코어 GPU


GPU라는 용어가 등장하기 이전부터 RGBA 4가지 채널을 병렬로 대응할 수 있는 SISD 연산 구조의 픽셀 파이프라인이 정립된 상태였고, 1998년 NVIDIARIVA TNT, ATi의 RAGE 128부터 픽셀 파이프라인 자체가 2개가 되어 일종의 멀티코어 형태로 존재했다.
1999년 10월에 출시된 지포스 256부터 조명과 좌표 변환 처리(하드웨어 T&L), 2000년 4월에 출시된 라데온 DDR부터 절단(Clipping) 기능까지 추가된 하드웨어 TCL을 수행하기 위해 폴리곤을 생성할 수 있는 벡터(4-way SIMD) 연산 구조의 버텍스 파이프라인이 추가되면서 그래픽 카드의 프로세서를 GPU라고 부르기 시작했다. 하지만 프로그래머가 제어할 수 없는 영역이라 응용력을 발휘하는데 한계가 있었다.
2001년 지포스 3, 라데온 8500부터 셰이더 프로그래밍이 가능해지고, 2002년 7월에 출시된 라데온 9700부터 표준화된 셰이딩 프로그래밍 언어, 더 높은 정밀도의 부동소수점 실수 연산 지원, 하나의 명령어에 4D 벡터가 아닌 3D 벡터 + 1D 스칼라, 2D 벡터 + 2D 스칼라같은 하이브리드 방식이 도입된 부분적인 MIMD 연산을 지원하면서 연산 효율을 개선해왔지만 이 역시 한계에 봉착했다.
여기까지는 연산 유닛들이 일정한 개수만큼 뭉쳐진 파이프라인 단위로 사용되었다. 구조적으로 보면 CPU 내부 코어도 여러 개의 정수 연산 유닛들과 부동소수점 실수 연산 유닛들이 뭉쳐있으므로, GPU 내부 파이프라인이 CPU 내부 코어에 가까운 구조라고 볼 수 있다.
결국 2006년 11월에 NVIDIA가 지포스 8800 GTX에 사용된 G80을 통해 정수 ALU(Arithmetic Logic Unit) 1개와 FP32 유닛(32-bit Floating Point Unit) 1개씩으로 단순하게 구성된 CUDA 유닛과 특수 연산을 수행하는 SFU(Special Function Unit), 데이터를 저장하고 불러올 수 있는 로드/스토어 유닛(Load/Store Unit), 덧셈과 곱셈을 동시에 지원하는 FMA(Fused Multiply-Add) 기능으로 병렬 연산 능력을 키우고, 종래의 하이브리드 연산을 넘어 범용(GPGPU) 연산에 대응할 수 있는 유연성과 효율성을 키우기 위해 CUDA 유닛별로 고효율의 SIMD 연산과 MIMD 연산까지 가능해졌다. NVIDIA에서는 이를 SIMT라고 부르기도 했다. 이들이 그룹핑된 스트림 멀티프로세서(Stream Multiprocessor)를, 그 SM이 하나가 아닌 복수로 구성하고 SM들을 제어하는 TPC(GPGPU 관점에서는 Thread Processing Cluster, 그래픽 연산 관점에서는 Texture Processing Cluster)를,[28] 그 클러스터들을 제어하는 스레드 프로세서 또는 스케쥴러[29]라는 상위 집합 단위들이 등장하여 이전과는 차원이 다른 거대한 스케일의 GPU를 구현했다. 그야말로 백지 상태의 처음부터 다시 만든 새로운 패러다임의 GPU인 셈. 그 외에도 프론트엔드 단계에 탑재되어 있던 각종 유닛들이 훗날에는 래스터 엔진(Raster Engine)과 폴리모프 엔진(Polymorph Engine)으로 재배치 및 통합되어 현재까지 존속되고 있다.
2007년 상반기에 AMD도 라데온 HD 2900 XT에 사용된 R600을 통해 전통적인 SIMD 구조를 따르는 대신 4개의 ALU와 1개의 SFU씩 묶어서 FMA와 코-이슈(Co-Issue) 기능으로 병렬 연산 능력을 살리고 1D/2D/3D/4D/5D 등 임의의 조합으로 보다 더 다양한 명령어들을 다룰 수 있는 5-Way 슈퍼스칼라 셰이더 프로세싱 유닛(Superscalar Shader Processing Unit)을 발표했다. SSPU들이 모여 하나의 SIMD 어레이(Array)가 제어하고 SIMD 어레이들이 모여 하나의 울트라 스레드 디스페치 프로세서(Ultra Thread Dispatch Processor)가 제어하는 계층 구조는 기존 벡터+스칼라 SIMD 구조의 강화판이자 확장판으로, NVIDIA와 대조적인 발전 방향이지만 댜앙한 명령어들을 한꺼번에 대응할 수 있는 하이브리드 연산 기능은 물론이고, 거대한 스케일로 구현할 수 있다는 점에서 어느 정도 유사한 공통적인 특성을 지닌다고 볼 수 있다. 궁극적인 목적은 동일하지만 구현 방법에 따른 설계 사상이 서로 다르다는 것.
이렇듯 GPU도 일찌감치 멀티코어 시대로 돌입한 후 수 백개의 코어 단위를 넘은 '''매니코어 프로세서''' 형태로 발전되었고, 보다 다양한 명령어들을 효율적으로 대응하고 처리할 수 있게 되었다. 또한, 두 칩셋 제조사 모두 픽셀 셰이딩 연산과 버텍스 셰이딩 연산을 따로 두지 않고 하나의 연산기에 픽셀과 버텍스 둘 다 처리할 수 있는 통합 셰이딩 연산기로 발전되었기 때문에 셰이딩 연산 능력을 가늠하는 기준이 달라졌다. 이렇게 하나의 연산기에서 처리할 수 있는 명령어의 종류가 다양해지다 보니 GPU를 더이상 특정 연산 장치라고 부르지 않고 범용(GPGPU) 연산 장치로 취급하기에 이르렀다.
현재는 연산 관련 스펙을 파이프라인 단위로 사용하지 않으며, 연산 유닛 단위로 취급한다. 다만, 연산 유닛들이 일정한 개수만큼 뭉쳐진 단위라는 개념 자체는 존속하고 있는데 NVIDIA의 스트림 멀티프로세서(SM)와 AMD의 컴퓨트 유닛(Compute Unit)이 그것이다. 구성만 따지면 SM과 CU가 파이프라인 단위에 대응된다고 볼 수 있지만, 동작 원리는 다르기 때문에 모든 면에서 파이프라인 단위와 같다고 볼 수는 없다. 특히 CUDA 유닛 자체가 한 가지의 연산 기능이 아닌 정수 연산 기능과 부동소수점 실수 연산 기능이 하나씩 뭉쳐진 구성이기도 하고... 물론 기능적으로는 동작시 양자택일로만 동작할 수 있었다가, 2017년 볼타 마이크로아키텍처부터 정수 연산 유닛과 부동소수점 실수 연산 유닛이 동시에 동작할 수 있게 되면서 기능적인 면에서도 SM이 파이프라인 단위에 부합되지 않는다고 보면 된다.
칩셋 제조사마다 설계 사상이 다르므로 게이밍 성능을 판단하려면 해당 게임의 실측 자료를 통해 판단하는 것이 좋다. 여기서는 '세대를 거듭하면서 단일 GPU 내부의 코어 개수가 대체로 증가한다'는 정도로만 참고할 것. 과거에는 1개의 파이프라인(현재는 코어)에 4-Way SIMD로 갖춘 4D 구조였으나 현세대에는 1개의 코어에 1D 구조로 대응해서 코어 카운팅하고 있기 때문에 명시된 파이프라인 개수와 코어 개수만 놓고 직접적으로 비교하기 곤란하므로, 개수를 비교할거면 연산기의 개수로 환산해서 비교하는 것이 타당하다.
  • 하드웨어 T&L을 지원하지 않고 프로그래밍 할 수 없는 고정된 그래픽 파이프라인 세대 (픽셀 유닛 개수)
    • NVIDIA
      • 1998년
      • 1999년
    • ATI
      • 1998년
        • 2파이프라인(8유닛): Rage 128 시리즈
      • 1999년
        • 2파이프라인(8유닛): Rage Fury
  • 하드웨어 T&L을 지원하지만 프로그래밍 할 수 없는 고정된 그래픽 파이프라인 세대 (버텍스 유닛 개수 + 픽셀 유닛 개수)
    • NVIDIA
      • 1999년
      • 2000년
        • 1+2파이프라인(4+8유닛): GeForce 2 MX
        • 1+4파이프라인(4+16유닛): GeForce 2 Ultra
      • 2001년
        • 1+2파이프라인(4+8유닛): GeForce 2 MX 400
        • 1+4파이프라인(4+16유닛): GeForce 2 Ti
      • 2002년
        • 1+2파이프라인(4+8유닛): GeForce 4 MX 460
    • ATI
      • 2000년
        • 1+2파이프라인(4+8유닛): Radeon DDR
      • 2001년
        • 1+2파이프라인(4+8유닛): Radeon 7500
  • 프로그래밍 할 수 있는 분리된 그래픽 파이프라인 세대 (버텍스 셰이더 유닛 개수 + 픽셀 셰이더 유닛 개수)
    • NVIDIA
      • 2001년
        • 1+4파이프라인(4+16유닛): GeForce 3
        • 2+4파이프라인(8+16유닛): XGPU (Xbox GPU)
      • 2002년
        • 2+4파이프라인(8+16유닛): GeForce 4 Ti 4600
      • 2003년
        • 3+4파이프라인( 12+16유닛): GeForce FX 5800 Ultra
        • 3+4파이프라인( 12+16유닛): GeForce FX 5900 Ultra
      • 2004년
        • 6+16파이프라인(24+64유닛): GeForce 6800 Ultra
      • 2005년
        • 8+24파이프라인(32+96유닛): GeForce 7800 GTX
      • 2006년
        • 8+24파이프라인(32+96유닛): GeForce 7900 GTX
        • 8+24파이프라인(32+96유닛): RSX (PS3 GPU)
    • ATI
      • 2001년
        • 2+4파이프라인(8+16유닛): Radeon 8500
      • 2002년
        • 4+8파이프라인(16+32유닛): Radeon 9700 시리즈
      • 2003년
        • 4+8파이프라인(16+32유닛): Radeon 9800 시리즈
      • 2004년
        • 6+16파이프라인(24+64유닛): Radeon X800 시리즈
      • 2005년
        • 8+16파이프라인(32+64유닛): Radeon X1800 시리즈
      • 2006년
        • 8+48파이프라인(32+192유닛): Radeon X1900 시리즈
  • 프로그래밍 할 수 있는 통합 셰이딩 그래픽 파이프라인 세대
    • NVIDIA
      • 2006년
      • 2007년
        • 128코어: GeForce 8800 Ultra
        • 128코어: GeForce 8800 GTS 512MB
      • 2008년
      • 2009년
        • 128코어: GeForce 9800 GTX+
      • 2010년
      • 2012년
      • 2013년
      • 2014년
      • 2015년
      • 2016년
      • 2017년
        • 3584코어: GeForce GTX 1080 Ti
        • 3840코어: TITAN Xp
        • 5120코어: TITAN V
      • 2018년
      • 2019년
        • 3072코어: GeForce RTX 2080 SUPER
      • 2020년
        • 7680코어: [30] A100
    • ATI
      • 2005년
        • 48파이프라인(240 스트림 프로세서): Xenos (Xbox 360 GPU)
    • AMD
      • 2007년
        • 320 스트림 프로세서: Radeon HD 2900 XT
        • 320 스트림 프로세서: Radeon HD 3870
      • 2008년
        • 800 스트림 프로세서: Radeon HD 4870
      • 2009년
        • 1600 스트림 프로세서: Radeon HD 5870
      • 2010년
        • 1536 스트림 프로세서: Radeon HD 6970
      • 2012년
        • 2048 스트림 프로세서: Radeon HD 7970
      • 2013년
        • 768 스트림 프로세서: Durango (Xbox One GPU)
        • 1152 스트림 프로세서: Liverpool (PS4 GPU)
        • 2816 스트림 프로세서: Radeon R9 290X
      • 2015년
        • 2816 스트림 프로세서: Radeon R9 390X
        • 4096 스트림 프로세서: Radeon R9 FURY X
      • 2016년
        • 2304 스트림 프로세서: Radeon RX 480
        • 2304 스트림 프로세서: Neo (PS4 Pro GPU)
      • 2017년
        • 2304 스트림 프로세서: Radeon RX 580
        • 2560 스트림 프로세서: Scorpio (Xbox One X GPU)
        • 4096 스트림 프로세서: Radeon RX VEGA 64
      • 2018년
        • 2304 스트림 프로세서: Radeon RX 590
      • 2019년
        • 2560 스트림 프로세서: Radeon RX 5700 XT
        • 3840 스트림 프로세서: Radeon VII
        • 4096 스트림 프로세서: Radeon PRO VEGA II 단일칩 (Mac Pro GPU)[31]
      • 2020년
        • 3840 스트림 프로세서: Radeon Pro VII

3. 매니코어 프로세서


근본적으로 매니코어 프로세서는 멀티코어 프로세서와 비슷한 성격들을 공유하지만 일반적인 멀티코어 프로세서들이 고성능의 싱글코어 프로세서의 코어가 적게는 두개 이상, 64코어 이하와 같이 상대적으로 한 프로세서 패키지에 적은 코어 갯수를 가지고 있기에 특별히 멀티스레드 프로그램이 아니라 싱글 스레드의 프로그램이여도 무난한 성능으로 동작하는 것에 비해 매니코어 프로세서는 상대적으로 낮은 성능의 코어가 최소 수십개 이상 달려 있는 특성상 극한의 병렬화 된 프로그램을 실행하는 것을 목적으로 한 프로세서이다.
이 때문에 매니코어 프로세서에서 병렬화가 부족한 프로그램을 실행하는 경우 프로세서의 성능을 크게 이끌어 낼 수 없게 된다.
대표적인 매니코어 프로세서는 GPU를 꼽을 수 있고, 그 외의 매니코어 프로세서가 적용되는 곳은 TILE64 프로세서와 같이 하드웨어 네트워크 장비에서 주로 사용된다.
그 특징상 멀티코어 프로세서가 64코어를 달성한 시기는 2018년 이후에서 AMD가 첫 선을 보였지만 매니코어 시장에서는 64코어는 이미 2007년에 달성한지 오래였다.
'''하드웨어'''
'''소프트웨어'''
  • OpenMP

4. 관련 문서



[1] 짤방의 의미는 멀티코어 미지원 게임, 혹은 무늬만 멀티코어일 뿐 싱글코어에 가까운 게임들이 코어 하나만 갈구고 나머지 코어들은 노는 걸 비꼬는 것이다. 다만 이 짤방에 나온 게임인 월드 오브 탱크는 2018년 3월 자 대규모 패치로 멀티코어 지원 능력이 향상되었기 때문에 '''과거'''에는 저랬다는 걸로 이해하면 된다.[2] 여담으로 제작자의 닉네임이 iPad(...)[3] 터보 부스트가 먼저 나왔다.[4] 전체 슬라이트 직링크, 직링크 출처 및 전체 발표 내용[5] 불도저 기반 AMD FX 시리즈, 셀러론 시리즈 등등.[6] 스카이레이크[7] 카비레이크[8] 커피레이크[9] 커피레이크 리프레쉬[10] 코멧레이크[11] 서밋 릿지[12] 피나클 릿지, 레이븐 릿지[13] 마티스, 피카소[14] n950[15] n900[16] n600[17] n500[18] n300[19] 코어당 2-way SMT 기능이 있어서 실제 스레드는 6개.[20] 인텔 제온 시리즈, AMD 옵테론 시리즈[21] 현재 인텔 코어 X 시리즈의 전신[22] 하지만 실제로는 i7은 고사하고 i5도 코어빨로 겨우 이기는 수준에 불과하였다.[23] 최고성능이랍시고 내놓은 8150이 전 세대인 투반보다도 순수 연산 능력에서 떨어짐[24] 인텔 제온 X7560 (네할렘-EX)[25] 웨스트미어-EX 기반 EX-8870, 이후 샌디브릿지-EP 기반 Xeon 시리즈[26] 이도 역시 ARM big.LITTLE 솔루션 사용[27] 아이비브릿지-EP, 하스웰-EP, 브로드웰-EP와 AMD 옵테론 시리즈의 매그니쿠어가 있다. 2010년 3월 출시한 제품으로, 6코어의 칩을 2개 붙여놓은 구조의 물건.[28] 훗날에는 그래픽 프로세싱 클러스터(Graphics Processing Cluster)로 계승되었다.[29] 훗날에는 기가 스레드 엔진(Giga Thread Engine)으로 계승되었다.[30] 이때부터 연산 특화 제품군 명칭인 TESLA가 빠졌다.[31] 이 GPU는 본래 한 PCB에 2개의 다이가 인피니티 패브릭으로 연결되어 있으므로, 1개의 다이의 코어 수만 서술