원문 원본 : http://www.anandtech.com/show/7910/apples-cyclone-microarchitecture-detailed

번역본 : http://knotes.tistory.com/6


본 글은 아난드텍의 Cyclone 아키텍처 분석을 번역한 글입니다. (애플 A7, A8 칩의 마이크로아키텍처)

A6 SoC (완)

A7 SoC : Apple's Cyclone Microarchitecture Detailed (본 글)

LLVM_678x452.png

지난 해 저희가 iPhone 5s 리뷰를 쓰면서 가장 힘들었던 점은 애플의 도움 없이 A7 칩을 파헤치는 것이었습니다. 저는 채 일주일도 안 되는 시간동안 리뷰를 해야 했고 애플이 또다시 CPU에서 2배에 달하는 성능향상을 이뤄낸 것에 대해서 측정할 툴도 없었습니다(Swift때처럼 직접 툴을 만들기엔 시간이 부족했었구요). 그래서 결국은 (부정확한) 추측으로 결론을 낼 수 밖에 없었습니다. 애플이 그들의 첫 ARMv7 아키텍처(코드명 : Swift)를 단순히 진화시켰다고만 생각했습니다. 그 당시 저에게 애플이 준 정보는 쉽게 측정할 수 있는 내용들 뿐이었습니다.(예를 들자면 메모리 접근 레이턴시 등) 제한된 시간과 제한된 정보가 애플의 첫 64비트 ARMv8 코어에 대한 오해를 낳았습니다. 아이패드 에어 리뷰를 낼 때에서는 저는 조금 더 많은 정보를 갖게 되었습니다:

제가 말할 수 있는 것은 Cyclone이 6개의 명령어를 발행할 수 있다는 것입니다. 이것은 적어도 Swift와 Krait의 2배에 해당하는 수치이며, 명령어의 조합에 따라 3배까지 커질 수 있습니다. 예를 들면 부동소수점 연산과 정수 연산이 동시에 들어올 경우가 있는데 최대 네 개의 정수 연산과 두 개의 부동소수점 연산이 동시에 처리될 수 있습니다. 게다가 클럭당 최대 두 번의 로드/스토어를 수행할 수 있습니다.

Swift 때는 LLVM 컴파일러에 애플이 단순한 코드네임 뿐만 아니라 CPU의 대략적인 사항들 까지도 기재를 해놨습니다. (세 개의 디코더, 2개의 산술 연산 유닛, 그리고 하나의 로드/스토어 유닛) 하지만 애플은 Cyclone에 대한 사항들은 공개적으로 기재하지 않았습니다. 단순히 코드네임을 알아내는 것 이상의 정보를 얻기 위해서는 많은 노력이 필요했습니다.

지난 주, Swift 당시 세부사항을 전달해 준 그 독자분께서 며칠 전 애플이 Cyclone 아키텍처에 대한 세부 내용을 LLVM에 기재했다고 알려주었습니다(다시 한번 고마워요 R!). 저희가 경험적으로 얻은 사실을 종합해서 Cyclone에 대한 좀 더 자세한 특성들을 작년 iPad Air 리뷰 당시에 쓰긴 했지만, 오늘 애플의 첫 64비트 ARMv8 기반 아키텍처에 대한 더 확실한 정보를 보여드리도록 하겠습니다.

이 아래의 표는 애플이 LLVM에 기재한 내용을 바탕으로 만들어졌습니다(그리고 가능하면 테스트를 통해 확인했습니다.)

Apple Custom CPU Core Comparison
 Apple A6Apple A7
CPU CodenameSwiftCyclone
ARM ISAARMv7-A (32-bit)ARMv8-A (32/64-bit)
Issue Width3 micro-ops6 micro-ops
Reorder Buffer Size45 micro-ops192 micro-ops
Branch Mispredict Penalty14 cycles16 cycles (14 - 19)
Integer ALUs24
Load/Store Units12
Load Latency3 cycles4 cycles
Branch Units12
Indirect Branch Units01
FP/NEON ALUs?3
L1 Cache32KB I$ + 32KB D$64KB I$ + 64KB D$
L2 Cache1MB1MB
L3 Cache-4MB

제가 iPad Air 리뷰 당시 언급했듯이, Cyclone 아키텍처는 그 폭이 넓습니다. Cyclone은 클럭당 최대 6개의 마이크로옵을 디코드하고, 발행하고 실행할 수 있습니다. 저는 iPad Air 리뷰 당시 네 개의 정수 연산과 두 개의 부동소수점 연산을 병렬 실행시킴으로서 이를 확인했습니다. 같은 테스트를 Swift에서 실행했을 때는 3개의 명령어만이 동시에 실행될 수 있었습니다. 모든 정수, 부동소수점 파이프라인이 병렬로 점유되고 있기 때문이죠. 이는 Krait에서도 비슷합니다.

Cyclone 아키텍처의 크기는 제가 초기에 예상했던 것보다 훨씬 컸습니다. 애플이 LLVM에 기재한 바에 따르면 Cyclone은 거대한 192 엔트리의 재정렬 버퍼를 보유하고 있습니다.(이는 하스웰의 재정렬 버퍼와 같은 크기입니다.) 분기예측 실패 패널티는 Swift에 비해 전체적으로 약간 증가했습니다. 애플은 이를 범위로 표현하는데 14 - 19 사이클 정도가 낭비됩니다. 이 값은 역시 샌디브릿지 이후의 인텔 코어 아키텍처와 같은 범위입니다.(하스웰도 포함) Cyclone의 사이즈 증가에는 L1 캐시의 용량이 2배로 증가한 것 역시 영향을 주었습니다.

백엔드부에서 Cyclone은 두 배의 정수연산유닛, 로드/스토어 유닛 그리고 분기예측 유닛을 가지고 있습니다. Cyclone은 역시 간접 분기예측기와 적어도 하나 이상의 부동소수점 파이프라인이 추가되었습니다. Cyclone은 꾸준히 세 개의 부동소수점 연산을 병렬로 수행할 수 있습니다.(3개의 FP/NEON 덧셈연산을 포함) 세 번째 FP/NEON 파이프라인은 나눗셈과 루트 연산에 사용됩니다. FP/NEON 곱셈의 경우 병렬로 두 개의 명령어만을 처리할 수 있습니다.

저는 각각의 유닛에 대한 버퍼 사이즈에 대한 참고문헌을 찾았습니다. 이것은 제가 각 유닛에 공급되는 마이크로옵의 갯수를 추정할 수 있게 해 주었습니다. Cyclone이 모든 실행 유닛 앞에 위치한 대기소에 통합 스케쥴러를 가지고 있을거라고는 생각하지 않습니다. 대신에 정적으로 나눠진 버퍼가 각 포트의 앞에 위치합니다. 이런 정보를 종합해서 블록 다이어그램을 그려보면 아래와 같습니다:

Cyclone_575px.png

불행하게도 위 다이어그램에 해당하는 Swift의 블록 다이어그램을 그리기엔 정보가 부족해서 비교 이미지를 제작하진 못했습니다. Cyclone은 6개의 디코더와 실행 유닛에 할당된 9개의 포트가 존재합니다, 거대한 구조입니다. 이전에 언급했던 것처럼 이는 지금까지 어떤 폰에 적용된 CPU보다 거대한 구조입니다. 애플은 Krait/Silvermont의 대항마를 만든 것이 아닙니다. Cyclone은 오히려 인텔의 큰 코어와 더 유사합니다. iPhone 5s 출시 당시 애플은 A7 칩을 가르켜 "데스크탑 클래스"라고 말했었습니다. 이것은 절대로 과장이 아니었습니다.

Cyclone은 애플의 과감한 발전이지만 그 이상은 아닙니다. 저는 아직 CPU의 모든 프로세싱 파워를 이용하는 iOS 앱을 거의 보지 못했습니다. 이 칩으로 무얼 할 수 있는지를 제시해 줄 수 있는 애플의 퍼스트 파티 앱이 더 많이 필요합니다. 장기적으로 봤을 때 Cyclone의 또 다른 문제는 1GB 메모리가 될 가능성이 큽니다. 아마도 당신이 Cyclone이 들어간 기기를 오래 사용하려고 한다면 CPU 성능보다는 메모리 부족이 먼저 발목을 잡을 것입니다.

AppleTownHall-869_575px.jpg

이 부분을 쓰고 있는 도중 애플의 코드네임에 대해 생각해봤습니다. Swift는 빨랐습니다, 하지만 Cyclone은 정말로 모든 걸 뒤흔들어 버릴 정도입니다. 모두가 방심하고 있을 때 소비자용 64비트 ARMv8 SoC를 그 누구의 예상보다도 빨리 소개한 것입니다.

진짜 질문은 이제 애플은 어디로 갈까? 란 것입니다. 일단 우리는 올 후반에 A8 이라 이름붙여진 애플의 SoC가 iPhone 6와 차기 iPad Air에 들어갈 것이라 기대할 수 있습니다. 분명히 그 성능에 향상이 있겠지만 그 정도가 Cyclone이 넓어진 정도만큼의 파급력은 아닐 것입니다. 한 가지 시나리오를 생각해 보자면 코어 클럭을 올리는 방법이 있습니다. Cyclone의 코어 클럭은 굉장히 낮게 설정되어 있습니다.(5s와 iPad mini with Retina Display 에서 1.3GHz, iPad Air에서 1.4GHz) 애플이 내년에 20nm 공정으로 이행한다고 가정하면 추가적인 전력 소모 없이 클럭스피드를 올림으로서 성능 향상을 얻을 수 있을 것입니다. 물론 애플은 몇 가지 방법을 동원해 추가적인 성능 향상을 꾀할 것입니다. Swift와 Cyclone은 인텔의 입장에서 보자면 두 번의 '톡'이 연속적으로 일어난 것입니다. 물론 이런 일이 흔치는 않지만 아예 없지도 않았습니다.(인텔은 2012년부터 2014년까지 같은 일을 Saltwell/Silvermont/Airmont를 거치며 했습니다.)

Cyclone을 보면 한 가지 사실이 분명해집니다: 나머지 모바일 CPU 회사들은 그 목표를 충분히 높게 잡지 않았습니다. 저는 이제 다음에 시장에 무슨 일이 일어날지 기대하고 있습니다.