멀티-코어 프로세서
* 관련 문서 : 플린 분류
[목차]
개요
||<rowbgcolor=#FFFFFF>width=100% || width=100% || || --데카코어-- --이론과 현실-- --개판-- || --흔한_듀얼코어.jpg[* 참고로, 아이큐 300점이면 시그마 15 기준 상위 7.4×10^^-39^^%이다. 이 확률을 쉽게 설명하면, 한 변이 50 km인 탄소로 이루어진 정육면체에서 원자 하나를 고른 때에 특정한 한 원자를 고를 확률과 같다.]-- ||
파일:1520512018.gif[* 짤방의 게임인 월드 오브 탱크는 2018년 3월 자 대규모 패치로 멀티코어 지원 능력이 향상되었기 때문에 과거에는 저랬다는 걸로 이해하면 된다.]
CPU 형태의 하나. 쉽게 말해, 동일한 성능으로 작동하는 CPU 여러 개를 1개의 칩 속에 집적해 놓은 것이다.
설명
코어의 개수를 늘리는 쪽으로 CPU가 발전하게 된 것은 폴락의 법칙에 따라 면적(트랜지스터 수) 증가로만 성능 향상을 꾀하기에는 어려움이 있기 때문이었다.
CPU의 성능이 매년마다 기하급수적으로 증가한다고 해도 CPU 하나만이 처리할 수 있는 작업 속도에는 한계가 있다. 이 한계를 극복하기 위한 발상이 바로 "CPU 하나로 모자라면 많이 때려박으면 되지!"다. 이런 발상은 슈퍼컴퓨터 분야에서 사실 1970년대 이후로 보편화된 사고 방식이고, PC 분야에서도 서버나 워크스테이션 등 고성능이 필요한 곳에서는 이미 한참 전부터 CPU를 여러개 설치하는 방식으로 고성능을 내 왔으나, 기술적인 문제로 하나의 CPU 모듈에 코어 여러개를 붙이는 현재와 같은 멀티코어가 본격적으로 보급된 것은 그리 오래되지 않았다. 2005년에 AMD에서 첫번째 데스크탑용 듀얼 코어 CPU인 애슬론 64 X2를 내놓으면서[* 사실 출시는 인텔에서 먼저했다. 프레스캇 두개 붙인 스미스필드 펜티엄D가 그 주인공. 나중에 관련 기술 책임자가 '9개월만에 급조한 CPU치곤 잘 만들어졌다'는 인터뷰를 하기도 했다. 그러나 안 그래도 '여보 아버님댁에 프레스캇 놔 드려야 겠어요' 드립을 듣던 녀석을 두 개 붙인 바람에 클럭을 못 올려서(성능이 안 나와서) 망했다. 펜티엄D는 그 이후 개량형인 프레슬러까지도 애슬론64 X2를 못 이겨서 빌빌댔으나, 넘사벽의 후배가 공개된 뒤에야 안심하고 가격후려치기를 해서 비로소 역전했다.] 본격적으로 데스크탑 컴퓨터에 보급이 되기 시작하였으며, 현재는 모바일 기기, 나아가 인터넷 공유기도 멀티코어를 쓴다.
하지만 멀티코어 프로세서는 단순히 프로세서를 두 개를 꽂는다고 두 배의 성능을 내는 게 아니다. 프로그램이 처리해야 하는 계산 작업 사이에서 여러개의 프로세서가 맡아서 처리할 수 없어서 하나의 프로세서만 써야 하는 작업이 생기면 나머지 프로세서는 그 작업이 처리되는 동안 놀고먹는 영 좋지 않은 모양새가 된다.[[1]] 이렇게 프로그램 내부에서 역할 분담(병렬화, Parallelization)이 되지 않는 부분이 많아지면 프로세서를 아무리 많이 때려박아도 성능 향상에 한계가 생긴다. 이를 전문 용어로 ~~조별과제~~ 암달의 법칙(Amdahl's Law)[* 다만 암달의 법칙 자체는 일반적으로는 훨씬 폭넓은 용어이다. 정확하게는 "시스템 부하의 a%를 차지하는 부분이 n배 개선된다면 결과적으로 a*n%의 성능 향상만을 기대할 수 있다"는 아주 상식적인 소리에 불과하다. 이게 "암달의 법칙"으로 불릴 정도로 유명해진 이유는 (특히 병렬 컴퓨팅 분야에서) 이거 안 지키다가 폭망한 사례가 아주 많아서 그렇다.]이라 한다.[* 듀얼코어 시절에는 배부른 소리처럼 들렸겠지만, 지금은 쿼드 코어를 넘어서 헥사/옥타 코어도 시중에 유통되어 있고, 병렬 처리가 생명인 GPU는 프로세서를 수백~수천개 단위로 투입하니 위 법칙이 더욱 체감으로 다가오는 때다.]
이를 피하기 위한 기능으로 인텔 터보 부스트, ~~유사품~~ AMD의 터보 코어[* 터보 부스트가 먼저 나왔다.]처럼 놀고 있는 프로세서는 파워게이팅이라고 전력공급을 차단해 버리고 남는 여유분[* 전력 공급 및 발열냉각설계는 멀티코어 모두 풀로 쓰는 기준으로 만들어 놨기 때문.]만큼 일하고 있는 코어를 자동으로 추가 클럭을 넣어주는 식[* 단, 오버클럭은 부스트 때문에 성능이 향상되는 이유에 대한 간단한 이해를 돕기 위한 비유일 뿐, 실제 부스트로 들어가는 클럭은 제조과정에서 기본적으로 세팅한 것이므로 오버클럭이 아니다.]으로 싱글코어만 써도 어느정도 성능향상이 있도록 하였으나 그래봤자 기본 설정 클럭에서 10~20%정도 밖에 안올라가는지라 근본적인 해결과는 거리가 멀다.[* 물론 없는 것보단 10~20%라도 챙기는게 확실히 낫기 때문에 세대가 올라갈수록 이 기술도 발전해서, [[2]] 4번째 댓글에서 설명하는 것처럼, 모든 코어를 다 쓰는 상황에서도 여유가 되면 부스트 클럭이 들어가거나 내장 GPU를 쓰지 않는 경우 거기서 나오는 전력/발열 여유를 CPU 부스트 클럭 유지에 돌리는 등등 조금이나마 추가적인 성능 향상을 계속 가져온다. 특히 노트북이나 저전력판의 경우 전력 제한에 맞추기 위해 기본클럭이 매우 낮고 성능도 그만큼 낮은데, 부스트 클럭은 상대적으로 그렇게 낮지 않은 경우가 많아서 부스트 클럭을 통해 쾌적한 환경에서 작업이 가능한 경우가 많다. 모바일용 i3와 i5의 가장 두드러지는 차이가 이것으로, i3는 터보부스트가 없으나 i5는 있다. 하지만 저 정도 차이는 어디까지나 노트북용 CPU 사이에서 뒤에 보통 U가 붙는 저전력 모델 한정. 일반적인 노트북 CPU만 해도 기본 클럭이 높은 쪽이 터보부스트를 씹어먹을 정도의 차이가 날 수 있는 경우가 많기 때문에 클럭 높은 놈이 깡패다.]
게임용 3D 그래픽 API의 대표격인 다이렉트X도 비슷한 문제를 겪고 있다. 다이렉트X 12 발표 자료를 보면, DX11은 쿼드코어에서 돌릴 경우 첫번째 쓰레드(쓰레드 0)가 다른 쓰레드보다 오래 걸리는 바람에 그만큼 나머지 3개 쓰레드들이 놀게 된다. 반면 DX12는 해당 부분도 4개의 쓰레드에서 나눠 처리하게 하거나, 아예 해당되는 처리 자체를 줄여서 멀티코어 사용률과 속도를 높였다.[*출처 : [DirectX Blog 에 올라온 DX12 정보]] 관련 문서를 보면 알겠지만 OpenGL도 마찬가지라서 Vulkan을 만들었다. 파일:attachment/멀티코어 프로세서/Example.jpg
따라서 CPU에 박힌 코어 여러개의 성능을 제대로 끌어내려면 여러개의 코어에게 일거리를 효율적으로 배분하도록 프로그램을 짜줘야 한다. 멀티프로세싱에 최적화가 되어있지 않은 프로그램은 CPU 처리량이 더 필요해도 다른 코어의 도움을 받지 못하고 1번 코어에서만 비비적대며 돌아가거나, 심지어는 일감을 달라고 저희들끼리 싸우는 동안 실행 속도는 오히려 더 떨어져버리는 참사가 벌어질 수 있다.[* 파이썬 언어가 한 때 이 문제 때문에 까인 때가 있다.] 따라서 실행 성능이 중요시되는 프로그램, 특히 게임은 처음 프로그램을 짤 때부터 멀티코어 지원을 생각해야되는 시대가 되었다.
하지만 병렬 프로그래밍(멀티쓰레딩) 자체의 어려움과 직렬화에 가까운 게임 프로그래밍의 특성 상 게임은 멀티코어 프로세서가 대중화된 시대임에도 많은 수의 게임들이 동서양을 가리지 않고 멀티코어를 제대로 활용하는 모습을 보기 어렵다. 이는 딱히 기술력이나 돈의 문제 이전에 병렬화로 성능향상을 꾀할 수 있는 부분이 게임에서 극히 적을 뿐더러, 적용한다고 해도 성능향상이 없거나 오히려 더 성능이 내려가기 때문이다. 게임은 실시간으로 모든 요소들이 정확히 동시에 플레이어에게 보여져야 하는 프로그램이다. 코어별로 따로 나눠 작업 돌려서 작업에 차이가 발생하면 플레이어 캐릭터는 등장하지만 NPC 1은 아직 연산이 안되었다고 안 나오고 화면은 나오는데 소리는 안 나오는 이런 상황 만들 수는 없어서 병렬처리가 어렵다. 지금도 극히 제한된 AAA 타이틀만이 4코어 이상의 다중 프로세서를 지원하는 형편이며 대다수 게임들은 멀티코어를 지원한다 해도 별 의미 없는 경우가 대부분이다. 물론 요소별로 나누는 것은 가능해서, 가령 물리연산만 따로 빼서 돌린다던가 하면 싱글코어만 지원하는 게임보다는 낫겠지만 그런 경우도 물리연산 자체는 한 코어만 갈구게 되어 한계가 생긴다.
싱글코어의 한계를 극복하기 위해 돌리는 시간이 짧은 시뮬레이션은 그냥 싱글코어용으로 짠 다음에 스크립트를 써서 여러개를 동시에 돌리는 식의 기법도 사용되고 있으나 효율은 좋지 않다.
그러나 실제로는 멀티코어를 지원하지 않는 프로그램이라도 멀티코어에서 충분히 성능 향상을 얻을 수 있다. OS에선 자신이 프로그램을 실행하지 않아도 기본적으로 수많은 시스템 프로그램이 실행되고 있고[* 윈도 기준으로 작업 관리자의 프로세스 탭에 몇 개의 프로세스가 있는지 세어보자.] 그것들을 OS에서 알아서 관리하는데, 멀티코어를 지원하지 않는 프로그램과 기본적으로 실행되고 있는 프로그램을 다른 코어로 나눠서 처리하면 성능상의 이득을 얻을 수 있는 것이다. 코어 한 개 범위 내에서 빨라지는 거긴 하지만 그게 어딘가.[* 단 그게 최근 게임에서 일어나는 일이라면 확실히 문제일 수도 있다(...). Python으로 개발된 EVE 온라인 같은 경우인데, Python의 특성상 단일 동작은 반드시 싱글코어에서 수행되어야 하기 때문에 위와 같은 방식으로 멀티코어에 최적화되어 있고, 과부하가 걸리면 이것도 한계가 오게 된다.]
어쨌든 각 코어의 연산능력도 뛰어나야 하며, 이 코어들간의 데이터 연계 능력이 뛰어나야 좋은 멀티코어 프로세서가 된다.
멀티코어 프로세서를 산다면, 코어 개수가 자신이 쓰려는 목적에 맞는지 보고 구매할 것을 권고한다. 예를들어 코어 i3-6100(3.7GHz)은 i5-6600(3.3GHz)보다 10만원 정도 가격이 저렴하지만 단일 코어 클럭은 400MHz 정도 더 높다.[* 그러나 이것은 명목상 스펙이고, 실제로는 i5-6600이 터보부스트로 3.9GHz까지 올라가지만 i3-6100은 그런거 없기 때문에 실제 성능 차이는 더 줄어든다.] 일반적으로 쿼드코어 쪽이 더 좋은 성능을 발휘하지만, 단일 스레드로만 구동이 되는 프로그램을 사용할 경우엔 오히려 클럭이 높은 듀얼코어쪽이 더 성능이 좋게 느껴질 수 있다는 것. 그러니 여러모로 고려해보고 구매하자. 당연하겠지만 그래픽 툴이나 컴파일러를 쓰는 앱 개발 툴 등 뭔가를 생산해야 하는 환경에서는 대부분 멀티코어 지원이 잘 되어 있어서 코어 수가 깡패다. 물론 예외의 경우도 있기때문에 자신이 쓰는 프로그램과 게임을 보고 판단해야한다.
대표적인 예중 하나인 스타2는 모든 물량을 죄다 CPU로 처리하는 데 고작 듀얼코어까지만 지원한다. 일반전에서는 문제가 없지만 물량이 쏟아져나오는 협동전에선 고클럭CPU가 아닌 이상 렉걸린다. 처음부터 듀얼코어로 설계한 것이 큰 잘못이다. 다른 예론 어도비 소프트웨어들. 산업표준이라는 말이 나올정도로 여러분야에서 압도적으로 많이 쓰이는 프로그램이지만 정작 최적화가 정말로 좋지 않고 전문가용 소프트웨어답지않게 고클럭CPU에 의지하고 있다. 아무리 코어갯수가 높아봤자 8코어가 최대며 그 이상은 의미가 없을정도. 물론 멀티코어에 제대로 최적화된 기능은 제대로 성능을 내준다. 에프터 이펙트의 4D 시네마 렌더링 테스트에 의하면 코어갯수가 높을수록 저 좋다는 결과가 나왔다.[* 애초 렌더링같은 건 코어가 많을수록 훨씬 좋다. 다른 기능들이 멀티코어를 제대로 못쓸 뿐이다.]
"클럭 = 성능"인 싱글코어와 달리 캐시나 아키텍처의 기여도가 더 높아져서 클럭이 성능 그대로는 나타내진 못하는 바람에 더 높은 클럭임에도 성능이 오히려 낮은[* AMD 페넘, 셀러론시리즈][* 옛날 인텔의 펜티엄 흑역사 시절에 3.0GHz를 --강제로-- 찍었으나 이보다 클럭이 더 낮은 AMD의 CPU(약 2.2~2.4GHz)는 인텔의 CPU보다 더 좋은 성능을 보여준다.] 경우가 있어서 과거와 달리 클럭이 높다고 무조건 좋은 제품이 아니며, 일반유저가 좋은 제품을 고르는게 다소 애매해졌다. 그 대신 전체적으로 어떤 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에서 코어2쿼드의 런칭에 맞춰 [측정] 웹페이지를 제공하기도 했다. 일종의 멀티 스레드 연산 테스트로 기본 클럭 Q6600의 성능을 100으로 치고 유저의 CPU 성능이 어디까지 나오는지를 측정해준다. 당시에는 꽤 정직한 결과를 보여줘서 대략적인 CPU 성능을 가늠해볼 수 있는 휼륭한 지표였지만 시간이 지나 크롬 등의 다른 웹브라우저가 득세하고 인터넷 익스플로러도 9 버전까지 업그레이드 되자 코어 i5 쿼드코어 제품군을 4Ghz 정도까지만 오버해도 600이나 700 같은 정신나간 수치가 나오게 되어 그 신빙성을 많이 잃었다.[* 만든 당시에 고려한 수치를 넘겨 버린 탓으로, TOP 10 그래프가 와장창 깨져있다.] 물론 구버전 인터넷 익스플로러에서 측정하면 멀쩡한 수치가 나오며, 알려진바로는 인터넷 익스플로러 9에서 쿼드지수 측정시 노오버 Q6600이 300점 가량 나온다고 하니 대략 1/3 정도로 계산해주면 될 듯 하다.
현재 x86 호환 CPU로 개인용으로 옥타코어까지[* 일반적으로 개인이 살 수 있는 범위까지 포함하면 AMD RYZEN 시리즈의 2990WX(32코어 64스레드). --220만원의 아름다운 가격의 CPU를 개인이 과연 살지는 일단 넘어가고-- --뭐 어때 겨우 18코어 36쓰레드인 인텔은 230만인데 18코어가 필요하면 32코어를 사면 되는 이 무슨 해괴한 현상--] (AMD FX 시리즈~~하지만 첫인상이 망했어요.~~[* 네이티브 8코어인가? 하는 부분에서 이견이 갈린다. 2코어 1모듈이라 실질적으로는 4코어라고 해야 한다며 소송을 당하기도 했다. 인텔이 하이퍼스레딩으로 2코어 4스레드를 4코어라고 파는것과 비슷한 맥락이라 보면 된다. 물론 완전히 같지는 않다. AMD쪽은 네이티브냐 아니냐의 문제지 어쨌든 8코어는 맞으니까. 다이 구조를 보면 오히려 코어 2 쿼드와 비슷하다.] 및 AMD RYZEN 시리즈, 모바일쪽으로는 퀄컴 스냅드래곤과 엑시노스가 있다(이쪽은 ARM계열이므로 당연히 x86호환이 안 된다.), 서버용으로는 인텔 제온에서는 22코어 44스레드(2.1GHz~3.7GHz)를, AMD EPYC에서는 32코어 64쓰레드(2.2GHz-2.7GHz~3.2GHz)까지 출시되어있다. --이걸 두 개 끼운다고 생각해보자.--
멀티프로세서 프로그래밍 패턴
프로그래밍에서도 멀티코어로 인한 성능을 온전히 활용하기 위해 몇 가지의 코드 패턴이 연구되었다. 이해를 돕기 위한 예시를 들어보겠다. ||이미 완성된 프로그램이 하나 있다. 해당 프로그램은 이미지를 입력받으면 전체의 픽셀을 반복문으로 순회하며 해당 픽셀의 RGB값을 각각 5씩 낮추는 프로그램이다. 그러나 이 프로그램은 스레드를 하나만 쓰는 싱글 스레드 프로그램이다. 이 프로그램을 멀티코어를 사용하도록 바꾸려면 어떻게 해야 할까?||
공유 메모리 모델
모든 코어/스레드가 하나의 메모리 공간을 공유하는 모델이다. 하나의 코어가 메모리에 쓰기 작업을 하려고 하면 먼저 해당 메모리 공간이 쓰기 가능한지(다른 스레드가 이미 작업 중인지)를 알아보고, 만약 사용 가능하다면 해당 메모리 영역에 잠금(lock)을 걸고 쓰기를 한다. 쓰기 작업이 완료되면 잠금을 해제하여 다른 스레드가 사용 가능하게 한다.
위의 예시로 들자면 잠금을 이미지에 걸고, 픽셀의 값을 읽고 쓰기 전까지 다른 스레드가 픽셀을 건드리지 못 하도록 막는 방법이다. 이미 싱글스레드로 구현된 코드를 멀티스레드로 변환하기 쉽다(단순히 잠금장치만 추가하고 해당 일을 하는 스레드를 많이 추가하면 된다.)는 장점이 있으나, 잠금 매커니즘이 관리가 까다롭고 성능 병목이 발생한다는 단점이 있다. 예를 들어 어떤 스레드가 잠금을 획득한 상태로 죽어버리거나(데드락), 두 개의 스레드가 경쟁적으로 잠금을 획득하려고 한다거나(레이스 컨디션), 서로 상대방의 스레드가 '잠가 놓은' 리소스를 획득하기 위해 무한히 대기하는 경우(스타베이션)가 발생할 수 있다. 또한 잠금을 확인하는 시점에서 모든 스레드가 동기화되어야 하기 때문에 가장 느린 스레드의 속도에 다른 모든 스레드의 속도가 맞춰져 버리는 단점이 있다.
만약에 스레드간 공유되는 자원이 아예 없다면 락 없이 빠른 병렬성을 보장한다. 거대한 배열에 관한 작업들은 CPU 캐싱이 잘 되게 짤 수 있어서 더욱 그렇다. 위의 이미지 예시를 들어보자면 이미지 자체를 하나의 리소스로 보지 말고, 행 하나하나를 리소스로 보고 스레드 개수로 분할할수도 있을 것이다.[* 물론 사양표나 테스트를 통해 해당 작업이 Thread-safe인지 반드시 확인해야 한다.] 만약 800x600인 이미지를 4개의 스레드로 쪼갠다면 각 스레드가 800x150의 영역을 담당하여 스레드 0이 0~150번째 행, 스레드 1이 150~300을 담당하는 식으로 서로간의 간섭 없이 메모리의 독립적인 부분에 대한 처리를 하게 된다. 이렇게 분할해서 가져가면 스레드가 가져간 이미지 조각들도 결국 연속된 배열이기 때문에 CPU 캐시 미스 거의 없이 빠르게 처리된다.
이러한 연산에 메시지 전달 작업 모델을 이용하면 꽤 느려질 위험성을 내포한다. 첫번째 이유는 메시지 큐(통신 채널)를 사용하는 오버헤드이다. 현용 메시지 큐는 락 없이 최대한 빠르게 동작하도록 설계되긴 하지만 어쨌든 큐에 일감을 넣고 빼는 작업 자체도 CPU 클락이 소모된다. 실제 작업 자체가 간단한 수식 작업일 수록 큐 작업의 오버헤드의 비율이 커져서 비효율적이게 된다. 두번째 이유는 각 스레드는 메시지 큐에서 일감을 메모리 영역에 대한 일관성이 없이 가져가기 때문에 CPU의 캐시 미스가 더 많이 일어나서 느릴 수 있다는 것. 따라서 벡터곱, 행렬곱, 텐서곱과 같은 균일한 배열에 대한 연산의 병렬화 모델은 메모리 공유 모델을 사용한다.
GPU는 공유 메모리 모델을 사용한다. 위에서 언급한 잠금 관리의 '까다로운' 부분은 하드웨어와 드라이버(런타임 라이브러리)에서 어느 정도 관리해주기 때문에 CPU보다는 편하게 병렬 프로그램을 작성할 수 있다.
메시지 전달 모델(생산자-소비자 패턴)
위의 공유 메모리 모델과 달리 모든 작업 스레드(워커 스레드)가 완전히 격리된 메모리 공간을 할당받는다. 스레드간 데이터 교환은 통신 채널을 통해 서로 메시지를 교환함으로써 이루어진다.
통신 채널은 비동기로 동작하며 워커 스레드는 자신이 메시지를 받을 준비가 되었을 때에 자신의 메일박스(또는 메시지 큐라고 하기도 한다)에 들어온 메시지를 순서대로 읽어 처리한다. 공유하는 메모리가 없기 때문에 잠금 매커니즘을 사용하지 않으며 비동기이기 때문에 빠른 스레드는 느린 스레드의 작업 완료를 기다릴 필요가 없다.[* 수신자의 메일박스가 가득차 더 이상의 메시지 수신이 불가능할 경우는 예외. 이 경우에는 수신자의 메일박스에 빈 자리가 생길 때까지 송신자 스레드가 대기하거나 또는 메시지를 폐기한다.]
위의 예시로 들자면 입력 스레드가 이미지에서 값을 읽어서 5를 빼는 워커 스레드(이 때는 '워커 스레드'가 소비자)에 던져주고, 워커 스레드는 자신의 결과값을 출력 스레드로 던진다(이 때는 '워커 스레드'가 생산자). 이 때 전달하는 메시지에는 픽셀의 x, y 좌표와 픽셀의 현재 값 c 세 개의 숫자값이 포함돼 있어야 한다. 공유 메모리 모델에서는 좌표값이 필요없으나(메모리 주소 자체가 좌표값 역할을 한다) 메시지 전달 모델에서는 어떤 스레드가 작업을 먼저 끝낼지 모르기 때문에 위치와 색상값이 모두 필요하다. 출력 스레드는 워커 스레드가 던진 x, y, c 메시지(여기서 c는 처리가 끝난 즉 5를 뺀 값)를 읽어서 자신의 메모리에 최종 결과를 쓴다.
위에서 보는 바와 같이 메시지 전달 모델에서는 입력, 워커, 출력 스레드가 각자 격리된 메모리 공간을 소유하므로 메모리의 공간적 부담이 늘어나는 단점이 있다. 워커 스레드의 '메모리'는 보통 CPU의 내부 캐시 메모리에서 처리되기에 충분할 정도로 작기 때문에 메모리 통신 대역폭 계산시 보통 무시되는 편이다.
공유하는 메모리가 없으므로 메시지는 CPU 내부 코어간은 물론이고 인접 소켓의 CPU나 네트워크를 통해 다른 컴퓨터의 CPU에까지 무리 없이 전달할 수 있어서 규모 확장이 쉽다.
특성상 각자 스레드가 자신이 낼 수 있는 최고 속도로 동작할 수 있고(생산자 스레드는 값을 읽어서 던져주기만 하면 끝, 소비자 스레드는 변환해서 다시 던져주기만 하면 끝) 프로세서가 동등한 관계가 아닐 경우에도 유용하게 쓰일 수 있으나(CPU-저장장치간 통신인 파일 저장 코드, CPU-네트워크간 통신인 네트워크 연결 코드 등등) 기존에 구현된 코드를 변환하기에 손이 많이 가고, 위에서 언급했다시피 메모리를 일관성 없이 참조해 CPU 캐시 히트율이 수직 하락하는 단점이 있다.
특성상 함수형 언어가 잘 지원하는 방식이기도 하다.
각 언어에서의 멀티코어 프로그래밍
멀티 코어를 이용하는 가장 기초적인 방법은 운영체제가 지원하는 스레드 생성 API를 이용해서 스레드를 생성하고, 일감 분배, 데이터 분산, 처리 및 결과값 도출을 직접 짜는 것이다. 스레드를 각 코어에 올려서 실행시켜주는 것은 운영체제의 몫이며 프로그래머의 역할은 데이터를 각 스레드별로 적절하게 분배해서 싣는 것이다. Unix환경에서는 Pthread라는 멀티스레드 API중 {{{ pthread_create }}}를 이용하여 스레드를 만들 수 있고, Windows 환경에서는 {{{ CreateThread }}}를 이용한다.
스레드 생성과 관리와 동기화 구현을 컴파일러가 생성하도록 하고 병렬 처리만 집중하고 싶다면 OpenMP를 사용할 수 있다. 기존 C/C++ 문법에 간단한 directive 추가해서 어떤 루프를 병렬화 할지를 알려주기만 해도 쉽게 병렬화를 할 수 있다. 물론 동기화를 어느곳에서 해야하는지 알려줘야한다.
더 고레벨 언어의 추상화된 모델을 사용한다면 각 언어가 지원하는 멀티스레딩, 멀티프로세싱 라이브러리를 사용해야 한다. 가령 Python같은 경우 multiprocessing 모듈의 Process와 Queue를 사용해서 메시지 전달 패러다임을 구현할 수 있다. 만약 배열에 대한 map 연산을 각 코어에 싣고 싶다면 multiprocessing 모듈의 Pool 객체의 map 메서드를 사용하면 잔 코딩 없이도 쉽게 작업을 분배할 수 있다.
멀티코어 종류 및 제품군
- 싱글코어는 멀티코어가 아닙니다. 자꾸 써넣지 마세요.
참고로 데카코어를 넘어가면서부터는 영미권에서도 거의 사용하지 않는 단어[* 라틴어 어근이다.]이기 때문에 그냥 숫자로 부르는 사람이 더 많다. 예를 들어 16코어는 '헥사데카코어'보다는 '식스틴 코어'라고 부른다. -- 한국어로 쳤을 때 열, 스물, 서른, ... 일흔, 여든, 아흔 다음에 '백'이라 읽지 '온'이라고 읽지 않는 것과 같다 -- 멀티코어 프로세서 등장 이전의 CPU는 이들과 구별하기 위해 '싱글코어'로 칭한다.
* 듀얼코어 - 두개의 연산회로가 한 다이 위에 존재. 대표적으로 펜티엄 D, 코어2 듀오, 애슬론 64 X2, 인텔 코어 i 시리즈 i3[* 하이퍼스레딩 기술이 들어가 스레드는 4개. AMD 라이젠이 가격과 성능을 모두 잡자, 인텔도 8세대부터 i3를 네이티브 4코어로 판매하고있다.], i5/i7 모바일 일부[* 카비레이크 이전의 인텔의 모바일용 i 시리즈 프로세서는 모델명 끝에 Q가 붙지 않는 이상 2코어 4스레드였다.], 펜티엄[* 카비레이크 이후부터는 하이퍼스레딩이 탑재되었다], 셀러론, 아톰 등이 있다. 2010년대에는 사실상 마지노 선으로서, 일반 판매용으로는 아무리 저가형으로라도 듀얼코어로 만들지 절대로 싱글코어로 생산되지 않는다.
* 트리플코어 - 3개의 연산회로를 탑재. 대표적으로 페넘 X3, 페넘 II X3, 애슬론II X3. 사실 네이티브 쿼드코어나 듀얼코어 두개 붙이기의 변종에 불과하지만… 여담으로 XBOX 360[* 스레드 개수를 뻥튀기하는 기술이 있어서 실제 스레드는 6개.]과 Wii U의 CPU도 트리플코어이고 아이패드 에어 2[* A8X 사용]도 트리플 코어이다. 여담으로, 쿼드코어의 오버클럭에 실패해서 코어 하나가 죽어버리거나, AMD CPU 중 코어 비활성화가 적용되어서 듀얼코어로 출시된 모델로, 쿼드코어를 부활시키려다가 1개만 부활하는 바람에 본의 아니게 트리플코어가 되는 웃지 못할 사례도 존재한다.
* 쿼드코어 - 4개. 대표적으로 코어2 쿼드, 페넘 II X4, 인텔 코어 i 시리즈 i3[* 커피레이크 이후부터 i3가 네이티브 쿼드코어로 생산된다.], i5, i7[* 하이퍼스레딩 기술이 들어가 스레드는 8개. 노트북용은 모델명 끝에 Q가 붙지 않는 이상 2코어 4스레드. 데스크탑의 경우도 클락데일인 경우 영락없이 2코어 4스레드 구성을 가진다.], Xeon E3 시리즈가 있다. 2017년에 나온 AMD의 데스크탑 쿼드코어는 AMD RYZEN 시리즈에서 Ryzen 5 1400, 1500X와 Ryzen 3 시리즈로 등장했다.
* 펜타코어 - 5개. 테그라 3는 공식적으로 쿼드코어 이지만, 800Mhz로 작동하는 섀도우 코어가 1개 존재해 사실상 펜타코어로 봐도 무방하다. big.LITTLE과 비슷한 기술이다. 투반에서는 오버클럭에 여유를 주기 위해 일부러 코어를 한개 끄거나, 조스마에서 코어가 한개만 부활되었을 때 쓰는 오반(5 + 투반)도 있다.
* 헥사코어 - 6개. 대표적으로 더닝턴의 Xeon 제온 7400, 코어 i7 980X 걸프타운, 인텔 하이엔드 데스크탑, AMD 페넘II X6 투반, AMD 옵테론 시리즈의 이스탄불, AMD FX 시리즈 6000 시리즈 등이 있다. 2017년에 나온 AMD의 데스크탑 헥사코어는 AMD RYZEN 시리즈에서 Ryzen 5 1600 시리즈로 등장했다. 인텔 코어 i 시리즈는 커피레이크부터 i5, i7[* 하이퍼스레딩 적용]이 헥사코어로 생산된다.
* 옥타코어 - 8개. 서버용으로는 인텔의 2010년 1분기 Xeon E7 네할렘-EX가, [* 녀석을 4Way로 박아서 32코어에 64개의 논리스레드 연산을 2009년 4월초에 시연하였다.]AMD의 2009년 3월 출시한 마그니쿠르의 옥타코어 버전이 있다. 2011년 10월에 출시한 AMD FX 시리즈는 첫번째 데스크탑용 옥타코어다. --하지만 이녀석은 듀얼코어인 i3랑 경쟁하고있다.[* 윈도우10으로 넘어오면서 FX시리즈의 성능이 상당부분 개선되었다. 멀티태스킹 성능이나 렌더링같이 코어빨로 잡아먹는 작업은 i5와 유사한 성능을 보여준다.]-- 실질적으로 제대로 된 성능이 나오는 AMD의 데스크탑 옥타코어는 2017년에 나온 AMD RYZEN 시리즈에서 Ryzen 7 시리즈로 등장했다. 인텔의 데스크탑용 옥타코어는 i7-5960X,코어 i7[* 인텔의 커피레이크 리프레시부터 i3는 4코어 4스레드 i5는 6코어 6스레드 i7은 8코어 8스레드 i9은 8코어 16스레드이다.]이 있다. 엑스박스 원과 플레이스테이션 4에 들어간 APU도 AMD 8코어이다.[* 다만 이건 TDP 때문에 재규어 코어 기반이라 싱글스레드 성능은 불도저보다도 훨씬 더 떨어진다. 그래도 같은 세대 기기인 Wii U는 성능이 이것보다 한참 아래 성능이라는 게 위안이지만..][* 다행인거는 엑스박스 원과 플레이스테이션 4에 들어간 APU는 램을 그래픽코어와 함께 공유하기 때문에 코어 성능 대비 좋은 그래픽을 뽑아낸다는 것이다.] 한편, 모바일 프로세서 쪽으로는 엑시노스와 스냅드래곤의 최상위 기종이 여기에 속하는데, 좀 더 효율적인 전력 관리를 위해서 클럭이 다른 두 쿼드코어를 연결하여 작업의 중요도에 따라 비중을 조절하는 ARM big.LITTLE 솔루션을 사용한다.
* 데카코어 - 10개. 인텔의 "웨스트미어-EX" Xeon 시리즈, 아이비브릿지-EP 기반의 E5 시리즈가 대표적이다. 미디어텍의 모바일 AP 중 하나인 미디어텍 Helio가 데카코어다(이도 역시 ARM big.LITTLE 솔루션 사용). i7-6950X가 최초의 데스크탑용 데카코어다.
* 도데카코어 - 12개. 대표적으로 샌디브릿지-EP, 아이비브릿지-EP, 하스웰-EP, 브로드웰-EP와 AMD 옵테론 시리즈의 매그니쿠어가 있다. 2010년 3월 출시한 제품으로, 6코어의 칩을 2개 붙여놓은 구조의 물건. 더불어 인텔의 i9 7920x 시리즈 역시 일반소비자(피식)를 겨냥한 데스크탑용 12코어 프로세서이다. AMD RYZEN 시리즈에서 쓰레드리퍼 1920X로 인텔을 씹어먹으려고 등장했다. --그리고 CPU게이트가 일어났다--
* 테트라데카코어 - 14개. 인텔의 하스웰-EP Xeon E5-2697 v3, 브로드웰-EP Xeon E5-2690 v4, i9 7940X 가 있다.
* 헥사데카코어(헥사데시멀코어) - 16개(...) AMD 계열에는 인터라고스라는 CPU가 있다. 이걸 쿼드 CPU 지원하는 G34 메인보드에 4개 다 때려박으면 무려 64코어가 완성된다.(...) 이후 RYZEN의 출시와 함께 AMD가 도전하는 HEDT라인인 쓰레드리퍼에서 1950X가 등장했다. 세계 최초의 데스크탑용 16코어 CPU. 2세대는 2950X로 등장하였다.인텔 계열은 브로드웰-EP Xeon E5-2697A v4, i9 7960x가 있다.
* 옥타데카코어 - 18개. 대표적으로 하스웰-EP Xeon E5-2699 v3, 브로드웰-EP Xeon E5-2697 v4 가 있다. 또 인텔은 2017년 6월 경 AMD의 쓰레드리퍼가 최대 16코어로 출시된다는 소식을 듣자 허겁지겁 Xeon 프로세서를 개량한 일반 소비자 데스크탑용 18코어 CPU인 i9 7980XE를 공개했다. i9 7980XE는 세계 최초의 일반 소비자 및 데스크탑용 18코어 36쓰레드 CPU이다.
* 도코사코어 - 22개 쓰레드 44개. 브로드웰-EP Xeon E5-2699 v4 가 있다. 캐시메모리가 이전 2697은 45MB였는데 55MB로 팍 올라갔다. 현존 가장 높은 성능 cpu인데 앞으로도 계속 외계인 고문으로 더욱더 괴물 cpu는 나올 것이다. 현재 아마존에 팔리고 있으며 4,317.07 $ 달러 환화로 510만 원가량 이다. * 도트리아콘타코어 32코어 64쓰레드라는 엄청난 숫자로 에픽 1세대 cpu가 출시 되었다! 그리고 AMD는 이걸 2세대 쓰레드리퍼에서 출시예정... 실제로 2990WX라는 모델명으로 출시 되었다
* 헥사콘타코어 - 60코어라는 그야말로 인텔의 외계인 고문 총집편. 제온 파이라는 이름으로 실제 출시된 1세대는 펜티엄, 2세대는 아톰 프로세서를 엄청나게 때려박은 CPU이다. 코프로세서이지만[* 단 이것은 어디까지나 홍보 문구로 실제 제온 파이의 구현은 좀 다르다. 실제 제온 파이는 코프로세서가 아니라 PCI-E 를 InterConnect 로 사용하는 별도의 리눅스 서버에 가깝다], x86 명령이 실행가능하므로 GPU와는 다르다. 각 코어가 4스레드의 SMT(하이퍼스레딩)에 대응해 실제 칩은 240개 스레드가 구동된다. 이건 뭐 대략 정신이 멍해진다. [* i7 4790K : 4GHz*32SP FLOPS*4코어 = 512GFLOPS / Xeon Phi 1세대 : 1.058Ghz*32SP FLOPS*60코어 = 2031.36FLOPS ][* 실제로 GPGPU 시장을 먹어치우며 급성장 중이다. 1세대인 라라비 시절만 하더라도 GPU에 밀리는 연산수치 비교만 당하다(내년~내후년쯤에 1테라플롭스로 나올예정이라는 발표를 하자, NVIDIA와 AMD가 1테라플롭스 GPU들을 판매개시했다(...)) 출시도 못하는 등의 굴욕을 겪었으나, 2세대 나이트 페리가 제온 파이로 출시된 이후로는 탄탄대로. 아무래도 CPU계열 출신이라 GPGPU보다는 프로그래밍하기 덜 어려운 데다가 인텔의 빵빵한 개발자 지원덕택인 듯]
* 64코어 "64코어 128쓰레드"라는 무식한 숫자의 코어와 쓰레드 갯수를 자랑하는 2세대 에픽 제품이 발표 되었다.[* 코어 갯수가 1년만에 2배가 되었는데 암드가 통짜 64코어 짜리 cpu를 만든게 아닌 8코어 짜리 cpu를 8개 합쳐서 만든 구조다.]자세한 건 출시하면 추가 바람
* 72코어 제온 파이
관련 문서
* CPU * 암달의 법칙 * 폴락의 법칙 * 4GHz의 벽 * 하이퍼스레딩 * ARM big.LITTLE 솔루션