지난 몇 년 동안 많은 사람들이 CPU 성능 향상률에 대해 화가 났으며, 어떤 사람들은 2600K가 5년 동안 문제없을 것이라 말하는데,
이것은 거의 9년 전입니다. 단일 코어 성능을 업그레이드하는 것이 왜 그렇게 어려운가?
네티즌 MediocreLeader는 오늘 Reddit에 대한 기사를 매우 뜨겁게 논의했습니다. 왜 트랜지스터 밀도가 단일 코어 성능에 거의 영향을 미치지 않습니까?
AMD의 Ryzen 3000은 TSMC의 7nm 공정을 사용했으며 트랜지스터 밀도는 96.5MTr / mm2에 이르렀으며 평방 밀리미터 당 거의 1억 개의 트랜지스터입니다.
인텔 14nm 공정 트랜지스터 밀도는 37.5MTr / mm2이며 이는 전자의 약 1/3에 불과합니다.
밀도의 3배라는 이점에도 불구하고 7nm Ryzen의 단일 코어 성능이 14nm 코어의 성능과 비슷한 이유는 무엇입니까?
기사전문 https://quasarzone.co.kr/bbs/board.php?bo_table=qn_hardware&wr_id=372342
(IP보기클릭)39.7.***.***
1. 코어성능 제 1요소는 명령어 처리속도 2. CISC 프로세서는 모든상황에 대응가능한 범용 명령어세트로 구성됨 3. 그래서 1개 명령어를 처리하는데 필요한 클럭이 길어짐 4. 그래서 클럭을 빠르게 할수록 성능향상되는데, 클럭향상은 한계에 가까운 상태 5. 결국 명령처리 클럭을 짧게 하는 설계가 필요함. 이게 IPC 6. IPC향상 설계 중 킹왕짱은 클럭주기가 길거나 사용빈도가 높은 명령어를 처리하는 물리적 전용회로를 별도로 추가하는거임 7. 근데 RISC프로세서 (대표적으로 GPU가 비슷한 개념) 들은 명령처리 회로의 종류가 적어서 이 방법으로 성능향상이 쉽게 체감됨 8. CISC는 모든경우의수에 대응하기위한 수백가지의 명령세트가 있는데, 범용처리회로만으로는 클럭을 많이 쓰기 때문에 범용회로 + 각종 전용회로들로 되어있는데 IPC향상은 곧 전용회로의 가지수, 트랜지스터수를 늘리는 거라는거 알지만 단순히 숫자만 늘리기는 어려운 이유는, 이 회로들이 연계적으로 작용해서 결과를 내려면 서로 긴밀히 연결되어야 함 9. 때문에 트랜지스터 수를 늘려서 이득을 얻고는 싶은데, 연결구조가 복잡해지거나 레지스터, 캐시의 과부하가 초래 될 수 있음 다중코어는 이러한 한계를 일찍 대비하고자 한 AMD에서 상용으로 처음 제안됨
(IP보기클릭)121.168.***.***
(IP보기클릭)112.164.***.***
물량이 2배가 된다고 해서 성능이 2배 오르고 물량이 3배가 된다고 해서 성능이 3배 오르지 못하는게 전자공학 아닌가??
(IP보기클릭)39.7.***.***
이런 실질 IPC향상설계가 굉장히 어렵기 때문에 지금까지 하이퍼쓰레딩 같은 연속명령처리기술이나 명령이나 분기예측 같은걸로 긴 클럭을 쓰는 명령이 처리되는 동안의 낭비를 효율적으로 활용토록 함으로써 IPC를 올려온 것으로 생각됨
(IP보기클릭)14.39.***.***
그래서 이유가 뭐지... 들어가서 읽어봐도 마땅한 답이 없군요
(IP보기클릭)14.39.***.***
그래서 이유가 뭐지... 들어가서 읽어봐도 마땅한 답이 없군요
(IP보기클릭)112.164.***.***
물량이 2배가 된다고 해서 성능이 2배 오르고 물량이 3배가 된다고 해서 성능이 3배 오르지 못하는게 전자공학 아닌가??
(IP보기클릭)211.36.***.***
(IP보기클릭)110.70.***.***
(IP보기클릭)175.193.***.***
(IP보기클릭)39.7.***.***
1. 코어성능 제 1요소는 명령어 처리속도 2. CISC 프로세서는 모든상황에 대응가능한 범용 명령어세트로 구성됨 3. 그래서 1개 명령어를 처리하는데 필요한 클럭이 길어짐 4. 그래서 클럭을 빠르게 할수록 성능향상되는데, 클럭향상은 한계에 가까운 상태 5. 결국 명령처리 클럭을 짧게 하는 설계가 필요함. 이게 IPC 6. IPC향상 설계 중 킹왕짱은 클럭주기가 길거나 사용빈도가 높은 명령어를 처리하는 물리적 전용회로를 별도로 추가하는거임 7. 근데 RISC프로세서 (대표적으로 GPU가 비슷한 개념) 들은 명령처리 회로의 종류가 적어서 이 방법으로 성능향상이 쉽게 체감됨 8. CISC는 모든경우의수에 대응하기위한 수백가지의 명령세트가 있는데, 범용처리회로만으로는 클럭을 많이 쓰기 때문에 범용회로 + 각종 전용회로들로 되어있는데 IPC향상은 곧 전용회로의 가지수, 트랜지스터수를 늘리는 거라는거 알지만 단순히 숫자만 늘리기는 어려운 이유는, 이 회로들이 연계적으로 작용해서 결과를 내려면 서로 긴밀히 연결되어야 함 9. 때문에 트랜지스터 수를 늘려서 이득을 얻고는 싶은데, 연결구조가 복잡해지거나 레지스터, 캐시의 과부하가 초래 될 수 있음 다중코어는 이러한 한계를 일찍 대비하고자 한 AMD에서 상용으로 처음 제안됨
(IP보기클릭)39.7.***.***
치비™
이런 실질 IPC향상설계가 굉장히 어렵기 때문에 지금까지 하이퍼쓰레딩 같은 연속명령처리기술이나 명령이나 분기예측 같은걸로 긴 클럭을 쓰는 명령이 처리되는 동안의 낭비를 효율적으로 활용토록 함으로써 IPC를 올려온 것으로 생각됨 | 20.02.28 17:56 | | |
(IP보기클릭)121.168.***.***
치비™
| 20.02.28 18:23 | | |
(IP보기클릭)115.40.***.***
근데 애초에 현존 x86 cpu들은 오래 전 파이프라인 구조를 도입할 때부터 CISC 명령어를 변환해서 내부적으론 RISC로 동작함. CISC와 RISC의 효율 차이가 넘사벽이라서 명령어 변환에 따른 손실을 감안해도 그게 더 빠르기 때문에. 다만 이렇게 해도 결국 순수 RISC에 비해선 전성비, 면적 등에서 밀리는 건 어쩔 수 없어서 모바일에선 아톰이 ARM에 밀려나고 말았고. | 20.02.28 20:27 | | |
(IP보기클릭)220.67.***.***
그러면 트랜지스터의 밀도 증가가 코어의 성능에 영향을 거의 미치지 못한 이유가 밀도만 증가한거지 실제 트랜지스터의 갯수에서는 엄청난 차이가 없어서 그런건가요? 성능을 향상 시키는데 이제 더이상 단순히 트랜지스터 수를 늘리는 것보다 분기 예측, 하이퍼쓰레딩 같은 기술 쓰기 때문인건가요? | 20.02.28 21:55 | | |
(IP보기클릭)220.117.***.***
틀린 내용이 좀 섞여 있는 것 같은데요. 저전력 칩인 arm 도 RISC 기반이고 고성능 고전력 칩인 IBM의 PowerPC도 RISC 기반입니다. 고성능과 저전력은 동전의 양면같은거라 둘 다 잡을 수는 없는데.. x86은 설계사상이 고성능 기반이라 아톰이 일정 이하의 저전력으로 못내려가서 실패한거고.. 반대로 전성비가 좋다고 ARM이 x86만큼 전력 소비를 하게 만들기만 하면 x86보다 고성능이 나오느냐.. 그게 아니라서 서버 시장 진입에 실패한거. | 20.02.28 23:32 | | |
(IP보기클릭)115.40.***.***
아뇨. 서버 시장은 지난 세월 동안 쌓여진 방대한 API의 규모를 따라가기 어렵기 때문에 진입하기 어려운 겁니다. 압도적인 성능우위가 아니면 시장에 진입할 수 없는데, 그건 현재로선 불가능한 얘기죠. 혹시 일본의 슈퍼컴퓨터 Gyoukou를 아시는지 모르겠는데, 이 놈 MIPS 기반 매니코어 프로세서를 바탕으로 한 슈퍼컴퓨터입니다. 2천만 개에 가까운 코어 수를 지녔죠. 2017년 11월 기준 TOP 500 4위. 아이폰으로 ARM이 대세가 되기 전에 MIPS 기반으로 매니코어 프로젝트가 시작되어 만들어졌습니다. 전성비는 그야말로 압도적입니다만, 호환성의 문제로 쓸 곳이 마땅치가 않다는 게 문제라죠. 아키텍쳐가 아예 근본부터 다르니 제로베이스에서 슈퍼컴에 돌릴 프로그램을 만들어야 한다는... 후속모델 NA-1이 나오긴 했지만 개발 방향은 성능보단 그 전성비를 살리는 쪽으로 가는 것 같네요. 2019년 11월 기준 Top 500 420위에 Green 500 2위입니다. 성능은 위의 예처럼 어쨌든 때려박으면 얼마든지 늘릴 수 있지만, 호환성의 장벽은 못 넘습니다. 그게 문제죠. | 20.02.29 00:19 | | |
(IP보기클릭)115.40.***.***
글고, 서버 시장 진입이 마냥 실패한 건 아닙니다. 구글이나 아마존 등은 자체 서버용 칩을 스스로 개발해 도입하고 있어요. 외부 회사들은 이들 기업의 요구스펙을 상세히 알 길이 없다보니 퀄컴 등의 서버용 ARM 프로세서는 실패했지만 실제론 아마존의 그라비톤 시리즈 등이 이미 현장에 도입해 쓰이고 있죠. 호환성, 생태계의 문제로 x86을 전면대체하는 것은 무리지만요. | 20.02.29 00:46 | | |
(IP보기클릭)130.126.***.***
음 그럴듯해 보이는 설명이지만 틀린곳이 너무 많아 보충 들어갈게요 1. 애슬론-펜티엄을 기점으로 현대의 프로세서들은 한 클럭에 여러 명령어를 처리할수가 있습니다. 그래서 한 클럭당 완료할 수 있는 평균 명령어 수를 IPC라고 부릅니다. 2. 문제는 이러한 동시 처리를 하면서도 순차 처리를 한 것과 동일한 결과를 내려면 의존성을 해결하는 아주 복잡한 회로가 필요합니다. 그래서 00년대 초~중반까지는 늘어난 트랜지스터를 코어 안에 때려박아서 동시 처리 용량을 늘리는 방식으로 성능 향상이 가능했고, 동시에 실행 단계를 잘게 나눠서 클럭도 끌어올렸죠. 3. 문제는 이게 너무 넓어지니까 한 개 스레드가 코어 처리 용량을 다 쓰지 못하는 상황이 벌어지기 시작합니다. 다시 말해 IPC 향상에 한계가 온거죠. 그래서 이 다음부터는 강한 한 코어를 만드는 것 보다는 코어 수를 늘리는 방향으로 선회하게 됩니다. 또 코어 내 남는 자원을 활용하기 위해 두 스레드가 동시에 들어가는 기술도 개발하죠. 4. 코어 수가 늘어나기 시작하니 이제는 메모리 성능이 발목을 잡습니다. 메모리를 기다리는 동안 처리를 못하면 그만큼 IPC가 떨어지는거니까요. 그래서 요즘은 캐시 성능과 용량을 늘리는데 트랜지스터를 집중 투자합니다. Zen2만 해도 코어 트랜지스터 절반 이상을 캐시 늘리는데 때려박았죠. | 20.02.29 03:23 | | |
(IP보기클릭)221.138.***.***
그러면 트랜지스터 수가 더 많아졌는데도 싱글코어 성능이 비슷한 이유는 늘어난 트랜지스터를 싱글 코어 성능 향상이 아닌 캐시 성능이나 그 외 다른 곳에 투자했기 때문인가요? | 20.02.29 11:50 | | |
(IP보기클릭)61.76.***.***
(IP보기클릭)222.108.***.***
seaislands
7nmFF = 96MTr/mm2 7nmHPC = 67MTr/mm2 50은 넘을걸요.... 12nm LP랑 14nm LPP가 33이 채 안 되구요. | 20.02.28 21:05 | | |
(IP보기클릭)175.204.***.***