본문 바로가기

Lecture & Column/ict_lec_col

애플의 새로운 모바일 SoC, A9 : 1부. 성능 및 아키텍처 분석

Author : Jin Hyeop Lee

(Any action violating either copyright laws or CCL policy of the original source is strictly prohibited)




안녕하세요 독자 여러분 IYD의 편집장을 맡게 된 이진협입니다. 오랫만에 새 글로 인사드립니다. 모쪼록 즐겁게 읽어주시면 감사하겠습니다.



들어가며

아이폰 6s 시리즈가 정식 출시된지 어느 정도 시간이 지났습니다. 아이폰의 s 세대가 그래왔듯 이번 세대 역시 외형적인 변경점은 미미하고 내부적으로 큰 변화가 있었습니다. 3d 터치나 카메라 모듈 등의 변화도 있었지만 이 글에서 다룰 내용은 아이폰의 가장 핵심적인 기능을 담고 있는 A9 SoC, 그 중에서도 CPU 부분입니다. 물론 실기기를 입수하여 직접 벤치마크를 하는 게 가장 적당한 방법이겠지만 아직 아이폰 6s/6s Plus이 국내에 출시되지 않은 상황이므로 geekbench 브라우저의 데이터를 가져다 쓸 수 밖에 없었습니다. 최대한 공정한 비교를 위해 6s의 경우 벤치마크 점수를 명시한 리뷰 중 그 테스트 방법을 명시한 리뷰(링크)에서 얻은 점수와 가장 유사한 스코어를 가진 표본을 골랐습니다. 대조군이 될 A8의 데이터는 보유하고 있는 아이폰 6를 이용해 위 리뷰의 테스트 방법을 그대로 사용(모든 앱 종료 후 재부팅, 독립적으로 3회 측정한 점수 평균)하여 산출했습니다. 또 각 테스트 항목이 명확히 명시되어있고 리뷰어들이 실측한 데이터가 존재하는 geekbench 3의 데이터를 기반으로 분석이 이루어졌으며 추가적인 분석은 아이폰 6s가 정식으로 출시된 후 실기기를 입수하여 작성할 리뷰에서 진행하도록 하겠습니다. 본 글은 A9의 성능을 분석하고 Twister 아키텍처에 대해 다루는 1부와 애플이 A9을 설계한 의도 등 성능 외적인 부분을 다루는 2부로 진행될 예정입니다. 먼저 A9 CPU의 성능을 확인해보도록 하겠습니다.

A9 CPU 성능 분석 : Based on Geekbench 3


A9이 출시되기 전부터 코어수에 대해 여러 가지 루머가 있었습니다.(링크) 심지어 애플이 스페셜 이벤트를 가지고 A9 SoC에 대한 일부 정보를 제공했음에도 불구하고 논란은 사그라들지 않았습니다. 애플이 제시한 70%의 성능 향상은 사람들의 생각을 훨씬 뛰어넘는 수준이었습니다. 상식적으로 Typhoon은 이미 충분히 고 IPC 아키텍처였고, 스마트폰이 갖고 있는 여러 가지 한계상 여기서 IPC가 유의미하게 커지리라 기대한 사람은 많지 않았습니다. 따라서 자세한 사항들이 공개되기 이전까지 고클럭 듀얼코어냐 저클럭 트리플코어냐에 대한 논란이 있었습니다. 이런 논란은 애플이 아이폰 6s를 판매하기 위해 중국 당국에 인증받은 내역이 공개되면서 종결되었습니다. 인증 내역에 따르면 아이폰 6s의 프로세서는 1.8GHz로 동작하는 듀얼코어를 가진 것으로 확인되었습니다. 이후 실제 제품이 출시되고 여러 가지 추가 자료들이 밝혀졌습니다. 먼저 A9 SoC의 CPU의 스펙시트를 살펴봅시다.



A9 SoC의 CPU 코어 코드네임은 'Twister'인것으로 알려졌습니다. Swift - Cyclone - Typhoon - Twister로 이어지는 애플의 자체 디자인 코어는 이제 4세대에 이르렀고 또 한번 큰 도약을 해냈습니다. A9의 Twister는 1.8GHz로 동작하는 듀얼코어입니다. 기존 A8이 사용하던 20nm 평면 공정에서 삼성/TSMC의 14nm/16nm FinFET 공정으로의 이행은 전력소모를 늘리지 않으면서 더 커진 코어를 30% 더 빠른 클럭스피드로 동작할 수 있도록 만들었습니다. 이 외에 특기할 만한 것은 L2, L3캐시가 각각 3배, 2배 커졌다는 것입니다. 메인 메모리 역시 LPDDR3 1GB에서 LPDDR4 2GB로 이행하여 큰 성능 향상을 기대할 수 있게 되었습니다.



이제 본격적으로 CPU 성능을 분석해 봅시다. 위 표에 기술된 점수는 Geekbench 3를 이용해 측정된 점수이며 정수 연산성능, 부동소수점 연산성능, 메모리 연산성능을 산술적으로 종합한 점수입니다. 표에 대해 조금 더 설명을 하면 가장 좌측은 아이폰 6에서 3회 측정된 평균값이며 두 번째 항목은 A8칩의 성능이 1800MHz로 완벽하게 스케일링 될 경우의 이론상 성능입니다. 이 때 단순 스케일을 할 경우 문제가 발생하게 되는데 Geekbench의 총점은 정수연산점수, 부동소수점 연산점수, 메모리 연산점수를 각각 가중치를 두어 합산한 수치입니다. 하지만 메모리성능은 CPU의 성능 스케일과는 별도로 작동합니다. 따라서 기존 구해진 총점에서 메모리 점수를 빼고 나머지 총점에 1800/1400을 곱한 뒤 다시 메모리 점수를 더하는 방식으로 계산했습니다. A8은 싱글코어 성능이 메모리에 병목을 일으키는데 1800MHz로 스케일된 성능으로 계산해보면 병목 지점을 넘긴다는 것을 확인할 수 있습니다. 따라서 싱글코어 총점의 경우 조금 더 복잡한데 기존의 총점에서 싱글코어 메모리 총점을 빼고 나머지를 스케일 시킨 뒤 멀티코어 메모리 총점을 합산하는 방식으로 산출했습니다. 그리고 A9의 경우 아이폰 6s(iPhone8,1)에서 측정된 값입니다. 우리는 여기서 동클럭시 성능비교와 A8, A9간의 성능 비교를 동시에 할 수 있게 됩니다. 긱벤치 싱글코어를 기준으로 56% 정도의 성능향상이 있었음을 알 수 있습니다. 멀티코어의 경우 그 성능향상폭이 줄어드는데 여기에 대해서는 뒷쪽에서 다시 짚어드리도록 하겠습니다. 또 동일 클럭을 기준으로 했을 때도 약 25%에 달하는 성능향상이 있었는데 이는 상당히 큰 변화입니다. 인텔이 2년에 한번씩 시행하는 아키텍처 개선에서도 이 정도의 IPC 향상은 이뤄내지 못하고 있다는 점을 보면 좀 더 이해하기 쉬울 것입니다. 우리는 여기서 A9의 Twister가 근본적인 수준에서 확장되었다고 추론할 수 있습니다.



위 표는 Geekbench 3의 정수연산 세부 점수입니다. 세부 점수 비교는 각 항목의 싱글코어 점수를 다뤘습니다. 매우 많은 알고리즘들이 CPU의 정수연산성능을 테스트하게 되는데 각 알고리즘이 사용하는 연산의 종류와 그 비율이 조금씩 다르기에 이들의 특성을 이해하면 A9의 특성에 대해서 더 잘 이해할 수 있을 것입니다. 이제 각 세부 점수에 대해서 알아보도록 합시다.

 

AES는 고급 암호화 표준의 약자로 대칭키 방식의 암호화 기법입니다. 키를 만들고 복호화하는 데 많은 정수연산과 약간의 분기예측연산, 비트논리연산이 필요합니다. ARMv8이나 x86에서는 이를 지원하는 특수한 명령어가 존재하기 때문에 성능상에 이득을 얻을 수 있습니다. 이 항목에서 Twister는 Typhoon과 비교했을 때 큰 성능향상을 얻지 못했습니다. 동일 클럭 비교에서 오히려 더 낮은 성능을 보이는데 이는 1400MHz에서 1800MHz로 성능이 정확히 산술적으로 스케일되지 않기에 생기는 문제입니다. 즉 두 아키텍처간에 AES 성능은 사실상 동일하다고 볼 수 있습니다.

 

Twofish는 Blowfish 암호화를 기반으로 한 암호화 알고리즘입니다. 캐시 성능에 민감하고 많은 정수연산, 비트논리연산이 가해지게 됩니다. AES와는 다르게 A8 칩 대비 70% 이상의 성능향상을 보이고 있습니다. 이는 특별한 명령어에 의해 시행되는 AES와는 다르게 실제로 CPU가 정해진 연산을 모두 시행하기 때문입니다.

 

SHA는 해시 암호화 기법인데, 흔히 알고있는 MD-5 등을 대체합니다. 위의 두 암호화에 비해 캐시에 덜 민감하나 많은 정수연산과 비트논리연산 그리고 다소 많은 분기예측 연산이 들어갑니다. SHA-1과 SHA-2의 차이는 쉬프트 연산의 유무와 결과값, 내부 상태의 값 크기에 있습니다. SHA-1의 경우 역시 70% 이상의 성능향상을 보이고, SHA-2의 경우 그보다는 적지만 역시 50%를 넘는 성능 향상을 보여주고 있습니다. 

 

BZip2 압축, 압축 해제 테스트는 BZip2를 이용해 텍스트 파일을 압축하고 압축 해제하는 테스트입니다. 메모리 로드/스토어부터 캐시성능, 정수연산, 쉬프트연산, 분기예측연산, 논리연산이 많이 일어납니다. 성능 향상폭은 40%대입니다. JPEG, PNG 파일의 압축, 압축 해제 역시 메모리 로드/스토어부터 캐시성능에 영향을 받습니다. 또 많은 정수연산과 약간의 분기예측 연산을 시행합니다. 대략 40~50%대의 성능향상을 보여주고 있습니다.

 

마지막 세 알고리즘은 비교적 순수한 정수 연산성능을 평가하는 항목입니다. Sobel 알고리즘은 가장자리를 검출하는 알고리즘입니다. 캐시 성능에 영향을 받고 많은 정수연산과 분기예측 연산이 시행됩니다. 60%를 넘는 성능향상을 보이고 있습니다. Lua는 200000 이하의 모든 소수를 찾는 알고리즘입니다. 가장 단순한 계산 성능을 계측할 수 있는 항목이기도 합니다. 많은 정수연산과 다소 많은 분기예측연산이 시행됩니다. 90%에 달하는 성능향상폭을 보여줍니다. 마지막으로 Dijkstra 알고리즘입니다. 흔히 최단경로 알고리즘이라고도 알려져 있는데 역시 계산성능을 계측하는 데 특화된 항목입니다. 많은 정수연산과 분기예측 연산을 포함하고 있습니다. 역시 60%를 넘는 성능향상폭을 보이고 있습니다.


Geekbench는 사용시 실제 성능을 최대한 반영하기 위해 실생활에서 자주 사용되는 여러 시나리오들과 순수한 연산성능을 측정할 수 있는 시나리오들을 섞어서 CPU의 성능을 테스트합니다. 위 테스트 중 순수한 연산 성능을 최대한 반영하는 Sobel, Lua, Dijkstra가 대략 70%의 성능 향상을 보이고 있는데 이는 애플이 주장하는 성능 향상치와 일치하는 수치입니다. 이는 지난 세대의 사례를 확인함으로서 명확해질 수 있는데 A8 칩이 처음 출시되었을 때 애플은 A7 칩에 비해 25% 향상된 성능을 보인다고 발표했지만 실제 Geekbench 점수에서는 그 정도의 차이를 찾을 수 없었습니다. 하지만 이 때도 Sobel, Lua, Dijkstra 항목을 보면 애플이 주장한 25% 언저리의 성능 향상을 볼 수 있습니다. 이는 A7(아이패드 에어)과 A8X의 경우에도 마찬가지로 찾아볼 수 있는 경향성입니다.(싱글코어 기준 40% 성능 향상) 우리는 애플이 주장하는 CPU 성능 향상이 어떤 식으로 평가된 것인지를 좀 더 정확히 알 수 있게 되었습니다.



다음은 부동소수점 연산 성능의 세부 항목입니다. BlackScholes는 유럽식 옵션의 가치를 측정하는 수식으로 다량의 부동소수점 연산을 요구합니다. 대략 60%의 성능 향상을 보여줍니다. Mandlebrot 벤치마크는 다량의 부동소수점 연산과 분기예측 연산이 요구됩니다. 이 때 각 알고리즘의 실행이 일어날 때마다 메모리에 올려진 Mandlebrot Set과의 일치여부를 확인하는 과정이 필요합니다. 여기서는 60%에 약간 못 미치는 성능 향상을 보여줍니다.

 

Sharpen Filter와 Blur Filter는 각각 메인 메모리의 이미지에 샤픈이나 블러를 먹이는 테스트입니다. 메인 메모리에서 이미지를 읽어와 캐시에 저장하는 과정이 포합됩니다. 각각 80%를 넘는 성능 향상과 60% 언저리의 성능 향상을 보였습니다.

 

GEMM 테스트는 행렬의 곱연산을 시행합니다. 다량의 부동소수점 연산이 시행되며, 분기예측 연산이 발생합니다. S와 D는 각 단정밀도와 배정밀도를 의미합니다. 두 테스트 모두 대략 50% 언저리의 성능 향상을 보였습니다.

 

FFT 테스트는 고속 푸리에 변환 알고리즘으로 많은 부동소수점 연산이 발생합니다. 단정밀도에서는 70%에 가까운 성능 향상을, 배정밀도에서는 60%를 넘는 성능 향상을 보입니다.

 

N-Body는 물리엔진 등에서 가해지는 부하를 측정하기에 적당합니다. 역시 매우 많은 부동소수점 연산이 시행되며, 소량의 분기예측 연산이 동원됩니다. 65%에 달하는 성능 향상을 보입니다.

 

마지막 Ray Trace 항목은 광선을 추적하여 실시간 간접광 등을 계산합니다. 매우 많은 부동소수점 연산, 행렬연산과 다소 많은 분기예측 연산이 필요합니다. 60%에 못 미치는 성능 향상이 있었습니다.


부동소수점 연산의 경우 정수연산에 비해 비교적 고른 성능향상을 보여주고 있습니다. 이는 부동소수점 연산에 주어진 각 시나리오들이 대부분 매우 다량의 연산을 요구하기 때문에 그리고 단일 연산자로 다량의 데이터를 처리하는 특성상 상대적으로 연산 이외의 부분이 미치는 영향이 정수 연산성능 테스트에 비해 낮은 것이라 추론해 볼 수 있습니다. 게다가 부동소수점 연산의 경우 대부분의 캐시 성능에 밀접하다는 것 역시 이들의 성능 향상 편차가 크지 않은 이유 중 하나로 볼 수 있겠습니다. 평균적으로 60%를 조금 상회하는 성능 향상을 보이고 있는데 역시 순수한 연산 부하만을 가한다면 이보다 조금 더 상향된 성능 향상을 보일 것이라 추론할 수 있을 것입니다.



Geekbench 3의 마지막 테스트 항목인 메모리 성능입니다. 앞에서도 말했듯이 A9은 2GB의 LPDDR4 메모리를 채택함으로서 메모리 성능의 향상을 예고했습니다. 메모리 성능의 각 항목은 매우 단순합니다.

 

Stream Copy의 경우 말 그대로 복사 붙여넣기 명령이며, Stream Scale은 한쪽의 데이터 셋에 일정한 숫자를 곱한 뒤 다른 주소로 다시 저장하는 테스트입니다. Stream Add는 두 데이터 셋을 더해 세 번째 공간에 저장하는 명령이고, Stream Triad는 위 두 개의 테스트를 합쳐놓은 것입니다. 한 쪽의 데이터셋에 일정한 수를 곱한 후 그 결과를 두 번째 데이터셋과 합산하여 세 번째 공간에 저장합니다.

 

위 표에 기술된 값은 각 SoC의 멀티 코어 메모리 점수 비교값입니다. 위에서 싱글 코어 성능으로 비교하다가 여기선 왜 멀티코어 성능으로 비교했는지는 바로 아래에 기술하겠습니다. 어쨌든 A8에서 A9으로 이행하면서 40% 정도의 메모리 성능 향상을 얻었다는 것을 알 수 있습니다. 기존의 통념과는 다르게 A8에서 A9으로의 이행에서 메모리 성능 향상폭보다 프로세서 성능 향상폭이 훨씬 컸고, 긱벤치 총점 비교시에 오히려 메모리 성능이 그 발목을 잡는 현상이 벌어집니다. 여기서 가장 먼저 봤던 표를 다시 살펴보도록 합시다.



긱벤치 총점으로 뽑은 점수입니다. 긱벤치 점수 기준으로 정수 연산 성능은 56%, 부동소수점 연산 성능은 62% 증가했는데 메모리 성능 증가가 연산 성능 증가에 비해 낮기 때문에 총 성능 향상이 정수, 부동소수점 향상의 평균에 비해 낮게 책정되었습니다. 여기서 재미있는 부분은 멀티코어에서 그 성능 증가율이 52%까지 떨어졌다는 겁니다. 보통 벤치마크 프로그램은 프로세서의 성능을 최대한 끌어내는 게 목적이기 때문에 명령어 레벨, 스레드 레벨의 병렬성을 고려하여 프로그램이 구성되어 있습니다. 따라서 벤치마크 프로그램에서 코어 수의 증가가 선형적으로 성능향상에 반영되지 않는 가장 큰 이유는 스로틀링입니다. 이것이 '모바일 SoC의 모든 것'(링크)에서 스로틀링 인덱스값을 구하는 이론적 배경이기도 합니다. 단순히 전체 점수만을 놓고 보면 애플이 각 코어를 과도하게 확장하고 그 클럭을 올림으로서 스로틀링이 걸렸다고 생각할 수도 있을 것입니다. 결론부터 말하자면 이 추측은 틀렸습니다. 이런 일이 생긴 이유는 Twister의 싱글코어 성능이 너무 좋기 때문입니다. 


(표 출처 : Daring Fireball)


메모리 스코어를 보시면 싱글코어와 멀티코어의 점수차이가 나는 아이폰 5s, 6와는 다르게 아이폰 6s의 경우 싱글코어와 멀티코어 메모리 점수가 거의 동일합니다. Geekbench의 메모리 벤치마크는 위에서 설명드린것과 같이 네 가지 항목으로 이루어져 있습니다. 네 가지 항목 중 첫 번째 항목은 순수한 메모리 성능의 측정이지만 나머지 세 항목은 CPU의 정수연산이 필요한 구조입니다. 기존 A7, A8 SoC는 싱글코어 상태에서는 위와 같은 테스트에서 메모리 성능을 다 끌어내지 못했다고 해석할 수 있습니다.(CPU에서 병목현상이 생김) 비로소 멀티코어를 활용해야만 메모리의 성능을 모두 끌어낼 수 있었던 것입니다. 반면 A9 SoC의 경우 싱글코어에서 이미 위의 연산들을 병목없이 처리해 낼 수 있게 되었고 싱글코어와 멀티코어에서 메모리 점수의 차이가 사라졌습니다.(따라서 위 메모리 성능 비교에서 순수한 메모리 성능의 비교를 위해 멀티코어 메모리 점수를 이용해 비교했습니다) 따라서 정수, 부동소수점, 메모리 점수를 단순히 가중평균치를 두어 합산하는 방식의 Geekbench 총점에서 이런 왜곡이 발생할 수 밖에 없는 것입니다. 메모리 점수를 제외하고 정수연산과 부동소수점 연산으로 비교했을 때 여전히 멀티코어는 싱글코어에 비해 두 배에 가까운 성능향상을 보여줍니다.(1.93배) 애플은 이번에도 역시 스로틀링 인덱스를 0에 가깝게 유지하는 방법을 찾은 것 같습니다.

 

Twister 파헤치기

 

우리는 위에서 얻은 정보들과 약간의 추가정보들을 이용해 Twister 아키텍처를 파헤쳐 볼 수 있을 것입니다. 저는 가장 먼저 Twister 코어가 기존 Typhoon 코어에 비해 얼마나 커졌는지를 확인하고 싶었습니다. 우리는 A8과 A9의 다이 이미지와 각각의 다이 크기를 알고 있습니다. 이를 이용해서 정확한 코어의 크기를 추정해볼 수 있을 것입니다.

 

        

(사진 출처 : Chipworks, 애플 스페셜 이벤트 슬라이드)

 

각 다이 사이즈에서 CPU 코어가 차지하는 영역의 비율을 단순한 계산을 통해 구해낼 수 있습니다. A8 칩의 다이 면적은 89 제곱밀리미터, A9 칩의 다이 면적은 96 제곱밀리미터(삼성 14nm LPE 기준)입니다. 단순한 비례식 계산을 통해 구해본 CPU 영역의 면적은 각각 12.3 제곱밀리미터, 12.4 제곱밀리미터가 됩니다. Chipworks 분석 결과 14nm LPE 공정에서 면적이 67%로 축소되었습니다. 이를 기반으로 코어 크기 비례를 맞춰볼 수 있습니다. 대략 60% 정도 코어 면적이 넓어졌음을 확인할 수 있습니다. 하지만 우리는 A8에서 A9으로 넘어올 때 L2 캐시가 3배로 늘어났다는 것을 알고 있습니다. L2 캐시은 L3 캐시의 SRAM 면적을 통해 어느 정도 근사할 수 있을 것입니다. 4MB의 L3 캐시의 면적이 20nm 공정 기준으로 4.9 제곱밀리미터이므로 대략 SRAM 1MB당 1.2 제곱밀리미터 정도의 면적을 차지한다고 볼 수 있을 것입니다. 이제 각각의 코어 면적에서 L2 캐시가 차지하는 면적을 빼고 그 비율을 구하면 코어 크기가 대략 40%정도 증가했다는 결론을 얻을 수 있습니다. 물론, 이 수치가 정확하지는 않지만 코어의 크기가 유의미하게 증가했다고 보기에는 충분할 것입니다.

 

Twister는 정수, 부동소수점 연산 모두에서 큰 폭의 성능향상을 보였습니다. 또 코어의 크기 역시 유의미한 폭의 증가를 보였다는 점에서 아키텍처가 확장되었다는 데는 이견이 없을 것으로 보입니다. 위 성능 평가의 각 세부 목록을 살펴보면 전체적으로 유의미한 성능 향상을 가졌다는 것에서 프론트엔드와 백엔드 부분 모두 확장되었다는 것을 추론할 수 있습니다. 정확한 세부 유닛들의 추가를 논하기에는 정보가 부족합니다. 추후 기기를 입수한 후 추가적인 실험을 통해 더 자세한 정보를 전달해드릴 수 있도록 하겠습니다. 지금 추론해 볼 수 있는 것은 디코더 갯수의 증가, 명령어 레벨의 병렬성을 관장하는 비순차 실행 유닛들(재정렬 버퍼, 재정렬 큐) 엔트리 수의 증가와 정수, 부동소수점 연산 유닛갯수와 백엔드의 이슈 폭 증가 등이 있습니다.

 

 

위 다이어그램은 기존 Cyclone의 블록 다이어그램을 기준으로 위에서 설명한 내용을 도식화한 그림입니다. 제가 예상해서 새로 추가한 부분은 점선으로 표시했습니다. 다시 한 번 말씀드리지만 위 블록 다이어그램은 제한된 정보를 가지고 추론된 내용을 정리한 것입니다.

 

이상으로 A9 Twister에 대한 분석을 마치겠습니다. 이어질 2부에서는 애플의 SoC 설계 속에 숨겨진 함의와 시장에 출시된 여러 CPU와의 비교(ARM, x86)등을 통해 A9이 가지는 성능 지위를 확인해 볼 수 있을 것입니다. 물론 이 과정에서 A9X에 대한 예측 역시 이뤄질 것입니다. 그리고 최근 뜨거운 감자인 14nm/16nm 혼용 문제 역시 다루지 않을 수 없겠지요. 많은 기대 부탁드립니다. 곧 2부로 찾아뵙겠습니다.

 

//