Section by Anand Shimpi

애플 A6는 우리에게 독특한 도전과제였습니다. 통상적으로 우리는 제조사로부터 새 아키텍처에 대한 정보를 얻을 수 있습니다. 우리 나름대로도 수많은 테스트를 거쳐서 나름의 결론을 얻은 뒤 제조사의 도움을 받아 그 결과들을 더 잘 이해할 수 있지요. 하지만 A6에 대해 우리는 애플로부터 예쁘게 그려진 블록 다이어그램이나 아키텍쳐에 관한 ISCCC 논문을 제공받지 못했습니다. 그리고 벤치마크 면에서도 좋은 스마트폰 벤치마크가 없었기에 할 수 있는 것이 매우 제한적이었습니다. 하지만 A6칩을 이해하는 것은 아이폰 5를 이해하는 핵심입니다. 게다가 그것은 우리에게 애플이 어디로 가고있는지에 대한 통찰도 제공해 줄 수 있을 것입니다. 아이폰 5 리뷰에 있어서 A6에 대한 깊은 분석은 필수적인 것입니다.

첫 번째 할 일은 그것의 이름을 알아내는 것입니다. 이름을 아는 것은 단지 그 이상의 의미가 있다는 오랜 환상도 있지만, 단순히 감춰진 코드네임을 알아내는 것 자체도 멋진 일입니다. 독자가 우리에게 올바른 방향으로 갈 수 있도록 팁을 좀 줬습니다(고마워요 R!). iPhone 5 백그라운드에서 구동되고 있는 iOS 6 코드는 우리에게 그 이름을 확인시켜줬습니다. 애플의 첫 번째 커스텀 ARM CPU 코어는 Swift라고 불립니다. 

다음우로 우리는 클럭 스피드를 확정지어야 했습니다. 스위프트의 작동 클럭을 알아야만 스위프트의 IPC가 Coretex A9 아키텍처에 비해 어느 정도의 IPC 향상을 이뤘는지 알 수 있습니다. Geekbench는 우리가 이전에 했던 iPhone 5 성능 프리뷰 이후로 업데이트되어 정확한 클럭 스피드를 보고합니다. Swift는 1.3Ghz로 작동하며 이는 기존 A5에 쓰인 Coretex A9의 800MHz보다 확실히 높은 클럭스피드지만, 퀄컴이나 엔비디아, 삼성 또는 TI가 채택한 것만큼 높은 수치는 아닙니다. 클럭스피드는 62.5% 밖에 빨라지지 않았지만 애플은 성능이 두 배 향상됬노라 공언했습니다. 이것은 분명히 Swift가 Coretex A9에 비해 클럭 그 이상의 발전이 있었다는 것을 알려줍니다. 게다가 Swift는 2013년 말에 새로운 아이폰이 출시되기 전 까지 현역입니다. 즉, 퀄컴의 Krait나 ARM의 Cortex A15와 경쟁이 가능해야 합니다. 애플이 종종 퍼포먼스나 스펙에는 큰 신경을 쓰지않는다고 말하지만, 사실은 그렇지 않습니다. Coretex A9 기반의 Soc를 2013년 말까지 플래그쉽을 책임져야 할 기기에 넣는 것은 너무 위험합니다. 비슷하게, 어떤 SoC 제조사도 2012년 3분기 현재 A15 기반의 SoC를 대량생산 제품에 넣을 준비가 되지 않았습니다. 이런 상황이 애플이 직접 그들의 코어를 디자인하게 하는 데 추진력을 주었습니다.

이제 우리는 코드네임과 클럭 스피드를 가지고 있습니다. 나머지 빈 칸을 채워넣어 봅시다.

Chipworks의 멋진 작업은 우리가 코어 자체를 들여다볼 수 있게 해 주었습니다, Chipworks는 Swfit코어가 A5에 사용된 Coretex A9 코어에 비해 50%정도 크다고 추산했습니다.

두 개의 애플 Swift 코어, 사진제공 Chipworks, 표시는 아난드텍이 함

두 개의 ARM Cortex A9 코어 , 사진제공 Chipworks, 표시는 아난드텍이 함

위 다이 사진을 보면 캐시와 코어의 비율이 Swift쪽이 Cortex A9에 비해 훨씬 커진 것을 알 수 있습니다. 우리는 L1/L2 캐시의 크기가 변하지 않았다는 사실을 알기 때문에 (32KB/1MB) 이 차이는 코어가 더 크고 복잡해졌기 때문에 생긴 것입니다.

먼저 제가 알고싶었던 것은 low level 연산 성능이 어느 정도로 변했는가 하는 것이었습니다. 고맙게도 우리는 여기에 대한 마이크로벤치마크가 가능했습니다. 이 때 ARM의 Cortex A9과의 비교를 어렵게 만드는 변수가 두 가지 있었습니다. Swift가 새로운 아키텍처로 추정된다는 점과 기존 애플의 A5 SoC에 탑재된 Cortex A9 보다 높은 클럭스피드로 작동한다는 점이었습니다. 아래에 있는 표는 아이폰 4S를 이용해 측정한 800Mhz의 Cortex A9 성능과, 이론적으로 클럭이 1300Mhz 일때의 성능을 함께 비교하고 있습니다(아이폰 4S 측정치에 1300/800을 곱함). 이 비교의 핵심은 순수히 클럭스피드만을 올렸을 때 어느 정도의 성능 향상이 있는가입니다. 물론 Cortex A9이 800MHz에서 1300MHz로 이렇게 완벽하게 스케일링 되지는 않겠지만, 그 오차는 프로세서간의 성능을 비교하기에 충분히 작은 수준일 것입니다.

우리의 실험은 Geekbench 2에서부터 시작됩니다. 이 툴은 low level의 수치 계산 성능을 알아보기에 매우 훌륭합니다. 이는 정수성능, 부동소수점 성능 그리고 메모리 워크로드를 분리해서 확인할 수 있습니다. 우리는 먼저 정수 성능부터 테스트했습니다. 저는 Geekbench 소스에 접근할 수는 없지만 CPU코어 성능을 최대한 잘 테스트할 수 있도록 아래와 같은 테스트들을 진행했습니다.

Blowfish 테스트는 Blowfish 알고리듬을 이용한 암호화/복호화 테스트입니다. 이 알고리즘은 캐시에 민감하며 많은 정수연산과 비트 논리 연산을 시행합니다. 여기서 우리는 Swift가 1.3Ghz로 보정된 Cortex A9을 대략 35%정도 앞서는 것을 볼 수 있습니다. 전반적으로 이와 비슷하게 대략 30% 정도의 정수연산 향상이 있는 것을 보실 수 있으실 겁니다.

텍스트 압축/압축 해제 테스트는 bzip2를 이용해 텍스트 파일을 압축하고 압축 해제했습니다. 텍스트 파일을 압축하는 이 테스트는 매우 low level의 CPU 벤치마크입니다. bzip2는 매우 많은 정렬을 사용하고, 많은 분기 예측 연산을 시행하며 논리 연산 역시 많습니다(정수 연산 유닛이 여기서 사용됩니다). 우리는 이 테스트에서 사용된 데이터 셋의 크기가 정확히 얼마인지는 알지 못하지만, 짧은 실행 시간으로 볼 때 캐시 안에 포함되기에 충분하다고 생각합니다. 위키피디아에 있는 모든 텍스트를 압축하고 압축 해제하지는 않는다는 뜻입니다. 즉 이 테스트가 캐시의 크기를 넘어서는 영향을 받지 않을 것입니다. 여기서 우리는 완벽히 스케일된 Cortex A9에 비해 38 - 40%에 해당하는 성능 향상을 볼 수 있습니다. MP text 압축 테스트는 Swift가 가장 힘을 못 쓰는 테스트였습니다. 1.3Ghz Cortex A9과 비교했을 때 27.3%에 해당하는 성능 향상만을 얻었습니다. 여러 가지 설명이 가능한데 L2 캐시의 접근 상한이나 여타 다른 메모리에 관련된 문제로 보입니다. 

이미지 압축/압축 해제 테스트는 특히 유용합니다. 그들은 JPEG 압축/해제 성능을 보여주는데 이는 실제 사용간에 애플리케이션이 자주 활용하기 때문입니다(웹 브라우징, 사진 뷰어 등등...). 여기에 사용된 코드는 정수 연산이 매우 큰 비중을 차지하며(더하기, 나누기 그리고 곱하기), 약간의 분기예측 연산을 포함하고 있습니다. 여기서 Swift는 다시 한번 33 - 43% 범위의 성능 향상을 보여주고 있습니다.

정수 연산 테스트의 마지막 세트는 스크립트화된 LUA 벤치마크입니다. 이것은 200,000이하의 모든 소수를 찾는 알고리듬입니다. 가장 원시적인 테스트이기도 하지요, 여기서 쓰인 LUA 벤치마크는 많은 정수연산 뿐만 아니라 꽤 많은 양의 분기예측 연산도 포함하고 있습니다. LUA 테스트에서 관측된 성능 향상값은 30% 정도입니다.

평균적으로, 우리는 1.3Ghz Cortex A9에 비해 37% 정도의 성능 향상이 있다는 것을 알수 있습니다. Cortex A9은 두 개의 정수 연산 유닛을 이미 가지고 있는데, 가능한 시나리오 중 하나는 (안 이랬겠지만) 애플이 연산성능을 높이기 위해 정수 연산 유닛을 추가했다는 것입니다. 다른 설명은 확장된 프론트엔드가 기존에 존재하던 두 개의 정수연산유닛의 활용도를 높였다는 것입니다. 만약 이 경우라면 더 많은 데이터를 동시에 처리하지는 못하고 단지 데이터를 실행 유닛에 더 빨리 전달해주는 효과만을 기대할 수 있습니다.

좀 더 깊게 살펴봅시다.

Geekbench 2의 부동소수점 연산 테스트는 매우 흥미로운 결과를 보여줍니다. 우리가 정수연산쪽에서 30 - 40% 사이의 비교적 일관된 성능향상을 관측한 것과는 다르게, 부동소수점 연산 부분에서 Swift는 예측할 수 없이 행동합니다. 우리가 이런 현상을 설명할 수 있을지 한번 살펴봅시다.

Mandlebrot 벤치마크는 다량의 부동소수점 연산과 분기 예측 연산이 병행되는데 이는 그 알고리듬이 결과값이 Mandlebrot set 안에 포함되는지 아닌지를 보기 때문입니다. 우리는 여기서 큰 성능향상을 보지 못한다는 점이 흥미롭습니다. Swift가 A5의 800Mhz Cortex A9보다 빠른 것은 틀림없지만 같은 클럭으로 환산한 경우 9.6%의 성능향상만 있기 때문입니다. Cortex A9은 부동소수점 연산유닛에 오직 한 개의 포트만이 할당되어 있으며 그마저도 로드/스토어 유닛과 공유하고 있습니다. 일단 여기까지만 보아서는 Swift에서도 이 부분은 변하지 않은 것으로 보입니다. 하지만 성급히 결론짓기는 이릅니다.

Dot Product 테스트 역시 아주 간단한 테스트로 두 부동소수점 벡터의 곱을 구합니다. 다시 한번 다량의 부동소수점 연산이 시행됩니다. 여기서도 성능향상폭은 그리 크지 않습니다. 동 클럭으로 환산했을 때 단지 9 - 12%의 성능 향상만이 있습니다. 이는 완전히 새로 디자인된 아키텍쳐치고 그리 좋아 보이지 않습니다.

LU 디컴포지션 테스트에서는 128 x 128 행렬을 두 개의 인수행렬로 쪼개는 작업을 수행합니다. 행렬의 크기는 반드시 1MB의 L2 캐시 내에 포함될 수준이어야 합니다. 이 테스트에 수반되는 연산은 마찬가지로 부동소수점 연산들이며 데이터 세트의 크기가 중요한 변수가 됩니다. 여기서는 1.3Ghz로 환산시킨 Cortex A9에 비해 35 - 40%의 성능향상이 있었습니다.

Primality 벤치마크는 먼저 몇 번의 반복적인 Lucas-Lehmar 테스트를 시행합니다. 이는 Mersenne 숫자가 소수인지 아닌지를 결정합니다. 이 연산은 매우 많은 부동소수점 연산을 포함합니다. 데이터 셋의 크기는 메인 메모리로 넘어갈 만큼 큰 크기는 아니지만, LU 디컴포지션 테스트에서 보았던 것보다는 더 큽니다. Cortex A9은 부동소수점 연산 유닛 전체가 단일 포트를 공유하는데, 애플은 Swift에서 두 번째 포트를 추가한 걸로 보여집니다. 우리가 이런 비슷한 성능 향상을  Mandlebrot 테스트와 Dot Product 테스트에서 볼 수 없었던 이유는 Primality 테스트에서 사용된 특정 명령어 셋 때문인 것으로 요약해 볼 수 있습니다. 그리고 Geekbench는 FP32 값인지 FP64 값인지를 유심히 살피지 않습니다, 여기서 Swift 아키텍쳐와 Cortex A9의 성능이 약간 다르게 적용될 수 있는 여지가 있습니다.

다음 두 테스트는 부동소수점 연산 테스트 중 가장 큰 성능향상을 보였습니다. 메인 메모리에 저장된 이미지에 이미지에 샤픈을 먹이거나 블러를 먹이는 테스트입니다. 어플리케이션에 내장된 필터는 그 자체로 많은 행렬연산과 분기예측 연산을 포함합니다. 데이터 셋의 크기는 캐시에 포함될 정도입니다.

우리가 이 정보만 가지고는 모든 것을 알 수는 없습니다. 단순한 부동소수점 연산에서는 클럭 보정시킨 Cortex A9에 비해 큰 성능 향상이 없었습니다. 반면 일부 경우에 있어서는 엄청난 성능 향상을 보였습니다. 여기에는 메모리 엑세스가 성능에 가져다주는 상관관계가 분명히 있는 것 같습니다. 그리고 우리는 Swift의 메모리 성능이 향상되었다는 것 역시 유추해볼 수 있습니다. 향상된 메모리 성능은 역시 앞에서 봤던 정수연산 성능의 향상도 설명할 수 있습니다.