32P by xguru 2020-12-04 | favorite | 댓글 17개

- M1은 한개의 CPU가 아니라, 대형 실리콘 패키지에 여러개의 칩들을 넣은 전체 시스템. CPU는 그중의 하나 일뿐
ㅤ→ CPU,GPU,메모리,IO콘트롤러 등을 묶은 SoC(System on a Chip)
- 범용 코어를 많이 넣는 대신, 특정 작업에 특화된 칩들을 넣음
ㅤ→ CPU : OS와 앱들을 실행
ㅤ→ GPU : 그래픽 작업을 수행. 앱의 UI, 2D/3D 게임등
ㅤ→ ISP(Image Processing Unit) : 이미지 프로세싱 속도 증가
ㅤ→ DSP(Digital Signal Processor) : CPU보다 더 수학집약적인 기능을 수행. 음악파일 압축 해제와 같은
ㅤ→ NPU(Neural Processing Unit) : 머신러닝, 음성인식, 카메라 처리등을 가속
ㅤ→ Video Encoder/Decoder : 저전력으로 비디오 파일/포맷 처리
ㅤ→ Secure Enclave - 암호화, 인증, 보안
ㅤ→ UMA(Unified Memory Architecture) : CPU,GPU 및 다른 코어들이 빠르게 정보 교환
ㅤ이런 칩들이 이미지/비디오 편집 및 큰 비디오 인코딩에서 성능이 뛰어난 이유 임

- Unified Memory Architecture(UMA)는 뭐가 특별한거야 ?
ㅤ→ 이 전의 CPU/GPU 통합 칩들은 느렸음
ㅤㅤㅤ둘은 서로 다른 메모리 영역을 서로 다른 방식으로 사용.
ㅤㅤㅤ게다가 GPU는 발열이 심하니까 큰 쿨링팬이 있는 거대한 카드들이 고성능을 보임
ㅤㅤㅤ하지만 이러면 서로간에 많은 데이터를 복사해야 하다보니 PCIe 같은 버스가 필요해짐

ㅤ→ Unified Memory 는 CPU/GPU를 위해 따로 할당하지 않음 그냥 같이 씀.
ㅤㅤㅤShared Memory 와 다르게 CPU와 GPU가 동시에 접근이 가능하며, 위치 정보 교환만으로 접근해서 복사가 필요없어짐

- 이 SoC 방식이 좋으면 다른 제조사들은 왜 안하지 ?
ㅤ→ 하고 있음. AMD가 CPU/GPU를 같은 실리콘 다이에 올린 APU형태를 만들기 시작
ㅤ→ 하지만 실제로 하기는 어려움. 왜나면 SoC 는 전체 컴퓨터를 하나의 칩에 올리는 것이기 때문에 HP나 델 같은컴퓨터 제조사에 더 어울림
ㅤ→ 인텔과 AMD의 비즈니스 모델은 사람들이 PC마더보드에 꼽는 범용 CPU기반인데,
ㅤㅤ 새로운 SoC 시장은 서로 다른 벤더의 피지컬 제품들을 가져와서 조립하는게 아니라, IP(Intellectual Property)를 조립하는 것
ㅤ→ 과연 인텔,AMD,Nvidia 가 Dell 이나 HP에 IP를 라이센스 줄 수 있을까 ?
ㅤ→ 물론 인텔과 AMD가 완성된 SoC를 판매할수 있지만, CPU제조사/PC제조업체/MS 간에 이해의 충돌(뭘 넣어야 할지 등)이 발생 가능
ㅤ→ 하지만 애플에겐 간단한 이슈. 그들은 자신이 모든걸 만듬. "They control the whole widget"

- CPU를 빠르게 만드는 가장 근본적인 도전
ㅤ→ M1의 빠른 범용 CPU 코어인 Firestorm 은 진짜로 빠름. 이게 기존 AMD/Intel 등과 비교했을때 느렸던 기존 ARM과의 차이
ㅤ→ Firestorm은 대부분의 인텔/AMD Ryzen 코어를 속도면에서 다 이기는데, 상식으로는 일어나지 않을 일.
ㅤ→ 빠른 CPU를 만드는 전략은 뭔가 ?
ㅤㅤㅤ1. 순차적으로 더 빠르게 명령을 실행
ㅤㅤㅤ2. 여러개의 명령을 병렬로 실행

ㅤㅤ80년대엔 쉬웠음. 그냥 클럭주파수를 높이면 명령이 빨리 실행됨.
ㅤㅤ컴퓨터는 클럭 사이클당 뭔가를 하는데, 이 "뭔가"는 아주 작아서, 명령 하나가 몇개의 클럭 사이클이 필요하기도 함
ㅤㅤ하지만, 현대에 와서는 클럭 주파수를 높이는 데에는 한계가 있음.
ㅤㅤ"무어 법칙의 끝"
ㅤㅤ따라서, 이젠 최대한 많은 명령을 병렬로 실행하는 것이 중요

- Multi-core or Out-of-Order processors?
ㅤ→ 병렬실행엔 두가지 접근 방법이 있다
ㅤㅤㅤ1. 더 많은 CPU코어를 넣는 것 (개발자 관점에서는 쓰레드를 더 추가하는 것 )
ㅤㅤㅤㅤㅤ이론적으로는, 프로세서의 코어는 여러개의 쓰레드를 실행할 수 있음(소프트웨어 쓰레드)
ㅤㅤㅤㅤㅤ이건 쓰레드간에 전환하며 실행하는 거라, I/O 나 네트웍에서 뭔가를 대기하는 상황에서나 사용
ㅤㅤㅤㅤㅤ하드웨어 쓰레드는 속도가 빨라지지만, 개발자가 이를 활용하기 위한 코드를 작성해야함.
ㅤㅤㅤㅤㅤ서버/클라우드에서는 이 모델이 적합.
ㅤㅤㅤㅤㅤ그래서 Ampere 같은 회사가 128코어를 가지는 Altra Max 같은 클라우드용 ARM CPU를 만드는 것.

ㅤㅤㅤㅤㅤ애플은 이것의 정확히 반대임. 애플은 싱글 사용자를 위한 기기를 만드는 회사
ㅤㅤㅤㅤㅤ데스크탑 소프트웨어들은 대부분 많은 코어를 활용하도록 만들어지지 않음.
ㅤㅤㅤㅤㅤ게임은 8코어에서는 성능 향상이 되겠지만, 128 코어는 낭비일뿐.
ㅤㅤㅤㅤㅤ그래서, 더 적은수의 강력한 코어를 필요로 하게 됨
ㅤㅤㅤ2. 비순차 실행 (Out-of-Order Execution, OoO )은 더 많은 명령을 병렬로 실행하지만 다중쓰레드 처럼 명시해서 사용할 필요가 없음
ㅤㅤㅤㅤㅤ개발자 관점에선 그냥 각 코어들이 빠르게 동작하는 것처럼 보임

ㅤㅤㅤㅤㅤ특정 위치의 메모리 장소에서 데이터를 가져오는 것은 느림
ㅤㅤㅤㅤㅤ하지만, 1바이트를 가져오나 128바이트를 가져오나 Delay 차이는 없음
ㅤㅤㅤㅤㅤ데이터는 데이터버스를 통해서 이동하는데, 이 버스가 넓으면 동시에 여러 바이트를 읽어올수 있음

ㅤㅤㅤㅤㅤCPU는 실행할때 여러 덩어리의 명령어들을 한번에 실행하게 되는데, 이 명령어들은 순차적으로 실행하게 작성되어 있음
ㅤㅤㅤㅤㅤ최신 마이크로프로세서들은 Out-Of-Order 실행을 함.
ㅤㅤㅤㅤㅤ즉 여러개의 명령어들을 분석해서, 서로간에 의존성이 있는지를 알아냄.

ㅤㅤㅤㅤㅤㅤㅤㅤ01: mul r1, r2, r3 // r1 ← r2 × r3
ㅤㅤㅤㅤㅤㅤㅤㅤ02: add r4, r1, 5 // r4 ← r1 + 5
ㅤㅤㅤㅤㅤㅤㅤㅤ03: add r6, r2, 1 // r6 ← r2 + 1

ㅤㅤㅤㅤㅤ위 명령에서 1과2는 의존성이 있지만, 3번은 앞과 전혀 상관이 없음.
ㅤㅤㅤㅤㅤ이러면 Out-of-Order 프로세서들은 의존성이 없는 3번 명령을 병렬로 실행할수 있음.
ㅤㅤㅤㅤㅤ실제로는 CPU가 한두개가 아닌 수백개의 명령어들간에 의존성을 파악할 수 있음.

ㅤㅤㅤㅤㅤCPU는 명령어를 노드 그래프로 연결하고 그걸 분석해서 병렬로 수행할수 있는 명령과, 실행전에 결과를 기다려야 하는 위치를 알아낼수 있음.

ㅤㅤㅤㅤㅤM1의 Firestrom 코어가 엄청난 속도를 내는 이유는 아주 뛰어난 Out-of-Order 실행을 하기 때문.
ㅤㅤㅤㅤㅤIntel/AMD 를 포함한 주류시장의 다른 누구보다도 뛰어날 것 같음.

- 왜 AMD 와 Intel 의 Out-of-Order 실행은 M1보다 느릴까 ?
ㅤ→ 앞에서 얘기한건 실제로는 ROB(Reorder Buffer) 라고 하며 일반적인 기계어 코드 명령이 아님(CPU가 실행하기 위해 메모리에서 가져오는)
ㅤㅤ이 명령어들은 CPU Instruction Set Architecture(ISA)라고 하며, 우리가 x86, ARM, PowerPC 라고 부르는 것들임.
ㅤ→ CPU는 내부에서 프로그래머가 모르는 완전히 다른 명령어 세트인 micro-operations (마이크로 명령어, micro-ops or μops)로 실행되며, ROB는 이 micro-ops 로 가득 차 있음
ㅤ→ ARM/x86 명령어는 공개 API, micro-ops 는 비공개 API라고 생각하면 됨.
ㅤ→ CISC 는 명령어가 크고 복잡하기 때문에 micro-ops를 꼭 써야하지만, RISC는 쓸지말지 선택할 수 있음.
ㅤㅤ(예를 들어, 작은 ARM CPU들은 micro-ops를 안써도 됨. 그렇다고 OoO를 못하는건 아님)

ㅤ→ 이게 왜 중요할까 ? "빠른 속도는 ROB를 얼마나 빨리,많이 채울수 있는지"가 중요
ㅤ→ 더 빠르게 채울수록, 더 많은 명령어를 병렬로 실행할수 있는 기회가 많아져서 성능이 향상
ㅤ→ 기계어 코드들은 디코더에 의해서 micro-ops 로 분할이 됨.

ㅤ→ 인텔/AMD 코어는 4개의 디코더가 있는데,
ㅤㅤ애플은 '미친' 8개의 디코더가 있고, ROB가 3배 더 커서 기본적으로 3배더 많은 명령어들을 담을 수 있음

- 그럼 왜 인텔과 AMD는 더 많은 명령어 디코더를 안 넣어 ?
ㅤ→ 여기서 RISC의 반격이 시작됨. M1 Firestorm 코어에 ARM RISC가 있다는게 중요.
ㅤ→ x86 명령어의 길이는 1~15바이트이고, RISC는 고정 사이즈
ㅤ→ 모든 명령어의 길이가 같으면 그냥 8개의 다른 디코더에다 잘라서 던지면 그만임
ㅤ→ 하지만, x86은 한 명령어의 다음 명령어가 언제 시작하는지를 모르기때문에 실제로 각 명령어를 분석하는 수 밖에 없음

ㅤ→ 인텔과 AMD는 이 문제를 brute-force 하게 처리하는 방법은 모든 명령어의 시작마다 디코딩 하는것
ㅤㅤ즉, 잘못된 추측이나 실수를 계속 버려야 한다는 것.
ㅤㅤ그래서 더 많은 디코더를 추가하기가 어렵지만, 애플은 아주 쉬움

ㅤ→ 이게 기본적으로 동일한 클럭 주파수에서 AMD/Intel CPU보다 두 배 많은 명령을 처리할수 있게 하는 것
ㅤ→ 현실에선 x86은 복잡한 CISC는 잘 안쓰고 RISC 처럼 짧은 명령을 주로 쓰기는 하지만, 저 15바이트짜리 명령어를 처리는 해야하기 때문에 복잡성은 있음.

- 근데 AMD의 Zen3 코어가 아직 더 빠르자나 ?
ㅤ→ 벤치마크에서 Zen3 가 Firestorm 보다 빠르긴 한데, Zen3는 5Ghz고 파이어스톰은 3.2Ghz
ㅤ→ 애플이 클럭주파수를 높이지 않는건 칩이 뜨거워 지기 때문.
ㅤ→ 기본적으로 Zen3 보다 Firestorm 코어가 우수함
ㅤ→ Zen3는 더 많은 전력을 소비하고 열을 내면서 게임에 사용할수 있지만, "애플은 그걸 하지 않기로 한 것임"
ㅤ→ 애플이 더 높은 성능을 원한다면 더 많은 코어를 추가할 것. 이를 통해 더 높은 성능을 더 적은 전력으로 낼수 있음

- 미래
ㅤ→ AMD/Intel 이 두가지 부분에서 자신들을 코너에 몰아 넣은 것
ㅤㅤ1. 이기종 컴퓨팅 및 SoC 설계를 밀어줄 비즈니스 모델이 없음
ㅤㅤ2. 복잡한 x86 CISC 명령어들이 레거시가 되어 OoO 성능을 개선하기 어렵게 만듬
ㅤ→ 물론 게임 오버는 아님. 더 클럭을 올리고 냉각을 더 하고, 더 많은 코어를 사용하고..
ㅤ→ 인텔은 더 안 좋음. 이미 코어속도에서 Firestorm에 밀리는데다가 SoC에 넣은 GPU가 후짐.
ㅤ→ 많은 코어는 당연히 서버에 좋지만, 아마존과 Ampere가 128코어로 공격하고 있음. 인텔/AMD는 양쪽을 다 싸워야 하는 상황

ㅤ→ 다행스럽게도 AMD/Intel 과 달리 Apple은 칩을 시장에 판매하지 않음
ㅤ→ 당장은 안그렇겠지만, PC사용자들은 천천히 애플로 이동하게 될 것이고, 애플은 PC마켓에서 더 많은 비중을 차지 하게 될 것

글 진짜 잘 쓰신다

너무 이해하기 쉽게 잘 정리해주심에 감사드립니다. 쵝오!

좋은 내용 감사합니다.

고맙습니다!!

M1 기기가 사고 싶었는데 그게 아니라 주식을 사야겠네요..
좋은 글 감사합니다!

저도 애플 주식이 미래가치가 높을거라는 거에 한표입니다.
언젠가 정말 애플Car 가 나오게 될거 같아요.

Weak memory model이 점점 중요해지고 있군요.. 애플은 이제 정말 칩부터 조립, 하드웨어, OS, 앱까지 전부 다 만들 수 있는 (잡스가 꿈꾸던) closed 회사가 되고 있네요.
저도 다음 기기는 m1 맥미니나 맥북에어로 생각하고 있습니다..

저도 2015년 맥북프로에서 m1으로.. 연말 아니면 내년초에 온다고 하네요!

오늘 확인해 보니, 국내 출시됐어요!

와! 구루님 정말 최고!!

고맙습니다 ;)

저 글안에 저자가 적은 RISC/CISC 비교글도 있는데 완전 강추드립니당. 왜 그런 명령어 구조를 가지게 됐을까? 라는 걸 술술 풀어서 설명해줘용.

기본적으로 글을 잘 쓰는 사람인거 같아요. 이 글도 꽤 긴데 잘 읽히더라구요.

와 좋은 내용 감사합니다.

컴퓨터 아키텍처 수업을 다시 듣는 기분이네요 ㅎㅎ
결국 애플은 애플이 가장 잘하는 걸 계속 더 잘할 수 밖에 없는 구조죠

인텔과 AMD는 이제 어쩌나요..

오늘 올린 긱뉴스 팟캐스트 16화에서 M1칩의 Memory-Order 트릭에 대해서 간단히 소개했는데 그것과는 또 다르게 자세한 글이네요.
- https://news.hada.io/podcast/22
다음주 팟캐스트에서도 또 얘기하게 될 듯 ^^;