※ 이 글은 오가사와라 히로유키(小笠原博之) 씨가 블로그에 적은 글을 번역한 것입니다. 사정에 따라 예고없이 삭제될 수 있으므로 양해부탁드립니다.
iPhone 5s A7 64bit CPU와 AArch64
(원문 : iPhone 5s A7 64bit CPU と AArch64)스마트폰에 탑재되어 있는 메모리 용량은 굉장히 빠른 페이스로 증가하고 있습니다. 다음 페이지에 일본에 발매된 단말의 스펙을 모았습니다.
대충 훑어보기만 했지만 대충 이런 느낌↓이 아닐까 합니다.
2008년 128MB 2009년 128MB〜256MB 2010년 256MB〜512MB 2011년 512MB〜1GB 2012년 1GB〜2GB 2013년 1/2GB〜?
특히 Android 기기에서 용량증가가 두드러짐을 알 수 있습니다. 이 페이스가 앞으로도 지속될 거라고 예상하면, 내년에는 32bit 프로세서의 벽에 부딪히게 됩니다.
많은 RAM 용량을 필요로 하게 되는 원인 중 하나로 화면의 고해상도화를 들 수 있겠습니다. 이쪽도 RAM 용량에 지지 않을 페이스로 진화해왔습니다.
2008년 128MB 480x320 x1.0 2009년 128MB〜256MB 480x320〜800x480 x2.5 2010년 256MB〜512MB 854x480〜1024x768 x5.12 2011년 512MB〜1GB 854x480〜1280x800 x6.67 2012년 1GB〜2GB 854x480〜2560x1600 x26.67 2013년 1/2GB〜? 1280x720〜?
고해상도화에 따라 응용 프로그램에 필요한 묘화 리소스량도 증가합니다. 해상도가 높으면 CPU 묘화가 늦어지므로, GPU의 지원이 필수가 됩니다. 묘화나 레이어의 합성 등 OS가 관리하는 GPU 리소스도 대폭으로 늘어나게 됨을 예상할 수 있습니다.
그 이외에도 여러가지 요인이 있을거라 생각하지만, 프로세서 전체의 성능향상과 그에 맞춘 요구에서 볼때, 64bit화는 자연스러운 흐름이라 할 수 있을 것입니다.
하지만 지금 가장 RAM 용량이 절박한 것은 Android 쪽입니다. iOS는 Android의 약 절반 정도의 RAM 용량으로 동작하고 있으므로, iPhone 5s의 A7가 스타트를 끊은 것은 상당히 의외라는 생각이었습니다.
64bit화의 메리트로 주소 공간의 확장을 듭니다만, 그 외에도 여러가지 메리트가 있습니다. 특히 64bit mode는 호환성의 족쇄에서 벗어날 큰 기회이며, 64bit 화되면서 여러가지 아키텍처의 변경이 이루어지고 있는 듯 합니다.
하나는 명령어 집합이나 레지스터 등 하드웨어적인 아키텍처의 변경이고, 또 하나는 소프트웨어적인 결정사항을 재설계할 수 있다는 것입니다. 전혀 쓰이지않지만 호환성 때문에 남겨져있는 기능이라던가, 설계가 낡아서 영 좋지않게 된 사양등을 쳐낼 수 있게 됩니다. (물론 32bit 동작 mode에서는 호환성이 유지됩니다.)
ARM은 로드 스토어형의 RISC 프로세서이지만, 한 인스트럭션에 복수의 기능이 들어간 다기능적인 명령체계였습니다. 예를 들면 명령 필드에 Condition Code가 포함되어 있어 조건부 실행이 가능하거나, 소스 오퍼랜드에 Shifter가 들어가 있는 등 상당히 독특합니다.
AArch64에서는 전혀 다른 명령어 집합이 되었습니다. 보다 심플하고 실용적인 설계가 되었다고들 합니다만, 대충 본 결과 편리해보이는 특이한 기능도 풍부하여, 충분히 ARM 답다고 느꼈습니다.
컴파일러의 출력 코드와 비교하면, 함수에 있어서는 64bit 쪽이 명령수가 줄어 컴팩트해짐을 알 수 있습니다.
위에서 적은 바와 같이 ARMv7에서는 호환성 문제로 softfp (soft-float)가 사용되는 경우가 있습니다. 부동소수점값도 함수 입출력에서는 일단 정수 레지스터를 경유하게 되어 낭비가 발생합니다.
AArch64 (64bit)에서는 이런 배려가 필요없으므로 처음부터 hard-float에 해당되게 된 것 같습니다.
// AArch64 __Z5func3fff: ; @_Z5func3fff ; BB#0: fadd s0, s0, s1 fsub s0, s0, s2 ret lr __Z5func419__simd128_float32_tS_: ; @_Z5func419__simd128_float32_tS_ ; BB#0: fmul.4s v1, v0, v1 fadd.4s v0, v1, v0 ret lr
// AArch32
__Z5func3fff: @ @_Z5func3fff
@ BB#0:
vmov d18, r1, r1
vmov d20, r0, r0
vmov d16, r2, r2
vadd.f32 d18, d20, d18
vsub.f32 d0, d18, d16
vmov r0, s0
bx lr
__Z5func419__simd128_float32_tS_: @ @_Z5func419__simd128_float32_tS_
@ BB#0:
vmov d17, r2, r3
vmov d16, r0, r1
mov r0, sp
vld1.32 {d18, d19}, [r0]
vmul.f32 q9, q8, q9
vadd.f32 q8, q9, q8
vmov r0, r1, d16
vmov r2, r3, d17
bx lr
64bit 화가 직접적인 이유인 건 아니지만, ABI나 스택 프레임을 개량할 수 있다는 것도 실제 퍼포먼스에 영향을 주는게 아닐까 합니다.
실제로 Windows의 x86/x64에서도, 양쪽을 다 써보면 같은 CPU 위에서도 64bit 쪽이 확실히 빠름을 알 수 있습니다. 64bit 성능이 떨어진다는 Core 2에서도 확실히 효과가 납니다.
x64에서 레지스터 수가 두배로 늘어난 것이 가장 큰 원인이겠지만, ABI처럼 소프트웨어 디자인면에서 호환성을 가질 필요가 없다는 점도 커다란 메리트가 됨을 예상할 수 있습니다.
iPhone의 메모리 공간에는 아직 여유가 있습니다만, 퍼포먼스의 향상이나 이용효율을 올려 전력절감으로 유도한다는 의미에서도 iPhone 5s의 64bit 화는 의미가 있다고 생각합니다.
어제 ARMv8 AArch64의 부동소수점 연산속도 비교를 위해 컴파일러의 출력 코드를 조사해본 결과, 그때는 이것↓이 뭔지 몰랐습니다.
orr.16b v5, v1, v1
의미없는 or 명령은 레지스터간의 move였습니다. (mov v5,v1)