※ 이 글은 오가사와라 히로유키(小笠原博之) 씨가 블로그에 적은 글을 번역한 것입니다. 사정에 따라 예고없이 삭제될 수 있으므로 양해부탁드립니다.

iPhone 5s A7 arm64 전용 명령의 속도 (2) (ARMv8 AArch64)

(원문 : iPhone 5s A7 arm64 専用命令の速度 (2) (ARMv8 AArch64))

ARMv8의 AES 명령을 사용해보았기에 아래 CPU 벤치를 갱신했습니다.

이하 발췌

CPU            arch           GHz  time      MB/sec   1GHz당
---------------------------------------------------------------
Apple A7 CPU   ARMv8 + AES    1.3  0.13s   837.54MB/s  644.26MB
Apple A7 CPU   ARMv8 (arm64)  1.3  1.04s   104.27MB/s   80.21MB
Apple A7 CPU   ARMv7          1.3  1.16s    93.04MB/s   71.57MB
Cortex-A15     ARMv7          1.7  1.49s    72.61MB/s   42.71MB
A6 swift       ARMv7          1.3  1.87s    57.96MB/s   44.58MB
Krait          ARMv7          1.5  2.28s    47.64MB/s   31.82MB
A5 Cortex-A9   ARMv7          0.8  5.78s    18.76MB/s   23.44MB

Core i7 3930K  x64 + AES-NI   3.2  0.05s  2299.54MB/s  718.61MB
Core i7 3930K  x86 + AES-NI   3.2  0.06s  1682.35MB/s  525.74MB
Core i7 2600S  x64 + AES-NI   2.8  0.05s  2113.03MB/s  754.66MB
Core i7 2600S  x86 + AES-NI   2.8  0.06s  1683.66MB/s  601.31MB
Core i7 620M   x64 + AES-NI   2.7  0.08s  1410.61MB/s  528.32MB
Core i7 620M   x86 + AES-NI   2.7  0.10s  1064.06MB/s  398.53MB
Core i7 3930K  x64            3.2  0.48s   228.05MB/s   71.26MB
Core i7 3930K  x86            3.2  0.50s   216.50MB/s   67.66MB
Core2 duo x64  x64            2.4  0.75s   143.56MB/s   59.81MB
Core2 duo x86  x86            2.4  0.85s   127.99MB/s   53.33MB
Atom N270      x86            1.6  4.21s    25.74MB/s   16.09MB

 ・「MB/sec」가 높을수록 고속
 ・「1GHz당」은 동일 CPU 클럭에서의 비교

A7 ARMv8 + AES를 사용함으로써 명령을 사용하지 않을때의 약 8배, ARMv7 (32bit) 때의 9배 고속으로 실행되었습니다.

다만 AES-NI[각주:1] 모두 컴파일러의 intrinsic (builtin)[각주:2]을 늘어놓은 것 뿐이므로 실제로는 더욱 최적화될 가능성이 있습니다.

Intel의 AES-NI는 상당히 심플하여, 1 round 마다 1명령, 최종 round에서만 다른 명령이 할당되어있었습니다.

ARMv8의 경우에는 AddRoundKey, SubBytes, ShiftRows와 MixColumns가 나뉘어져 있습니다. 지원하는 명령수는 늘어났습니다만, 이 조합으로 최종 round도 표현할 수 있으므로 전용명령을 쓸 필요는 없습니다. 또, AES-NI와는 xor(eor)의 위치가 딱 하나 비껴있는 형태입니다

관련 글

  1. 인텔의 웨스트미어 프로세서에서 제공하는 AES 암호화-복호화를 처리하기 위한 명령어 집합 [본문으로]
  2. 컴파일러에서 지원하는 내장함수. 일반적으로 어셈블리와 1대 1로 대응되어 어셈블리 명령어를 C/C++에서 사용하기 쉽게 만들어줌 [본문으로]

※ 이 글은 오가사와라 히로유키(小笠原博之) 씨가 블로그에 적은 글을 번역한 것입니다. 사정에 따라 예고없이 삭제될 수 있으므로 양해부탁드립니다.

iPhone 5s A7 CPU의 속도비교 arm64 (ARMv8 AArch64)

(원문 : iPhone 5s A7 CPU の速度比較 arm64 (ARMv8 AArch64))

아래 CPU 벤치 결과를 갱신했습니다. 이 결과만 보면 iPhone 5s는 iPhone 5 (A6)보다 약 1.8배 빠르며, Core2 duo의 1.74GHz에 상당합니다.

이하 발췌 (자세한 것은 위에 적은 페이지를 참조하시길) 
CPU            arch           GHz  time     MB/sec   1GHz당
--------------------------------------------------------------
Apple A7 CPU   ARMv8 (arm64)  1.3  1.04s  104.27MB/s   80.21MB
Apple A7 CPU   ARMv8 (armv7s) 1.3  1.16s   93.04MB/s   71.57MB
Cortex-A15     ARMv7A         1.7  1.49s   72.61MB/s   42.71MB
A6 swift       ARMv7A(armv7s) 1.3  1.87s   57.96MB/s   44.58MB
Krait          ARMv7A         1.5  2.28s   47.64MB/s   31.82MB
A5 Cortex-A9   ARMv7A(armv7)  0.8  5.78s   18.76MB/s   23.44MB

Core i7 3930K  x64 (Win+VC)   3.2  0.48s  228.05MB/s   71.26MB
Core i7 3930K  x86 (Win+VC)   3.2  0.50s  216.50MB/s   67.66MB
Core2 duo x64  x64 (Win+VC)   2.4  0.75s  143.56MB/s   59.81MB
Core2 duo x86  x86 (Win+VC)   2.4  0.85s  127.99MB/s   53.33MB
Atom N270      x86 (Win+VC)   1.6  4.21s   25.74MB/s   16.09MB

 ・「MB/sec」가 높을수록 고속
 ・「1GHz당」은 동일 CPU 클럭에서의 비교

지난번 테스트와 달리 부동소수점 연산은 포함되어있지 않습니다. 그래도 역시 32bit (AArch32)보다도 64bit (AArch64) 쪽이 빠르며, 공식수치인 "A6의 2배"에 가까운 결과를 얻을 수 있습니다.

클럭차가 있음에도 Core2 시대의 PC와 비교가능한 영역에 달했으며, 조금 믿기 힘들지만 clock당 실행효율은 Core i 클래스입니다.

다만 링크한 곳에도 적혀있지만, 결과에는 컴파일러의 성능차나 실행환경의 차이도 포함되어 있다는 점에 주의바랍니다. x86/x64는 VC보다 clang 쪽이 스코어가 높으므로, 실제로는 좀더 차가 벌어질 것이라 예상됩니다.

또한 이 점수는 벤치마크용입니다. ARMv8에는 x86/x64와 마찬가지로 AES 전용명령이 탑재되어있어 실제 사용시에는 훨씬 더 고속으로 실행될 수 있습니다.

ARMv8의 AES 명령을 사용한 경우의 벤치마크 점수는 아직 계측하지 않았습니다. 여유가 있으면 좀 더 폭넓게 테스트해볼까 합니다.

관련 글

※ 이 글은 오가사와라 히로유키(小笠原博之) 씨가 블로그에 적은 글을 번역한 것입니다. 사정에 따라 예고없이 삭제될 수 있으므로 양해부탁드립니다.

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)

관련글

※ 이 글은 오가사와라 히로유키(小笠原博之) 씨가 블로그에 적은 글을 번역한 것입니다. 사정에 따라 예고없이 삭제될 수 있으므로 양해부탁드립니다.

iPhone 5s A7 CPU의 부동소수점 연산속도(2) (AArch64/64bit)

(원문 : iPhone 5s A7 CPU の浮動小数点演算速度 (2) (AArch64/64bit))

64bit mode (AArch64)에서 테스트해봤습니다. 명령도 레지스터 구조도 다르므로 다른 코드를 썼습니다. 검증이 불완전하기에 이 결과에 잘못된 부분이 들어가 있을 가능성이 있습니다.

                  (1)    (2)     (3)       (4)       (5)
               iPhone5  HTL21  Nexus10   iPhone5s iPhone5s
                Swift   Krait Cortex-A15  AArch32  AArch64
                  A6   APQ8064 Exynos5D     A7       A7
                1.3GHz  1.5GHz  1.7GHz    1.3GHz?  1.3GHz?
--------------------------------------------------------------------
a:m44 vmla_A Q   1.293   1.337   0.619     0.700    -----
b:m44 vmla_B Q   1.359   0.931   0.569     0.670    -----
c:m44 vmla_A D   1.669   1.889   0.557     0.649    -----
d:m44 vmla_B D   1.329   1.532   0.568     0.745    -----
A:m44 vfma_A Q   1.632   1.882   0.746     0.707    0.692  (fmla v)
B:m44 vfma_B Q   1.594   0.695   0.840     0.699    0.696  (fmla v)
e:fadds      A   3.090   2.774   2.383     3.551    1.043  (fadd s)
f:fmuls      A   3.167   2.747   2.369     3.475    1.548  (fmul s)
g:fmacs      A   6.180   5.574   2.956     3.480    -----
h:vfma.f32   A   6.180   2.747   2.957     3.480    3.185  (fmadd s)
i:vadd.f32 D A   3.091   2.762   1.183     1.031    1.031  (fadd.2s)
j:vmul.f32 D A   3.168   2.746   1.478     1.545    1.545  (fmul.2s)
k:vmla.f32 D A   3.166   5.604   1.480     1.567    -----
o:vfma.f32 D A   3.167   2.833   1.479     1.574    1.753  (fmla.2s)
l:vadd.f32 Q A   3.090   2.801   2.365     1.031    1.039  (fadd.4s)
m:vmul.f32 Q A   3.166   2.761   2.364     1.548    1.548  (fmul.4s)
n:vmla.f32 Q A   3.167   5.606   2.367     1.574    -----
*:vfma.f32 Q A   -----   -----   -----     -----    1.696  (fmla.4s)
p:fadds      B   6.181   3.467   2.956     6.953    3.663  (fadd s)
q:fmuls      B   6.180   3.556   3.558     6.652    3.296  (fmul s)
r:fmacs      B   2.361   6.298   5.912     9.867    -----
s:vfma.f32   B   2.363   3.430   5.910     9.859    3.292  (fmadd s)
t:vadd.f32 D B   3.090   3.529   2.958     3.663    3.643  (fadd.2s)
u:vmul.f32 D B   3.169   3.447   2.364     3.114    3.289  (fmul.2s)
v:vmla.f32 D B   6.180   6.293   4.728     6.185    -----
z:vfma.f32 D B   6.181   3.437   4.730     6.188    6.237  (fmla.2s)
w:vadd.f32 Q B   3.090   3.457   2.961     3.659    3.641  (fadd.4s)
x:vmul.f32 Q B   3.167   3.428   2.363     3.101    3.276  (fmul.4s)
y:vmla.f32 Q B   6.179   6.372   4.729     6.199    -----
*:vfma.f32 Q B   -----   -----   -----     -----    6.226  (fmla.4s)

↑수치는 실행시간(초) 수치가 작을수록 고속

scalar 연산은 예상대로 AArch64 쪽이 고속으로 실행되는 것 같습니다. AArch64에서는 vector 때와 동등하여 NEON에 통합되었다고 예상됩니다.

ARMv8의 AArch64에서는 SIMD 레지스터의 구조가 변하여, 전부 128bit 사이즈가 되었습니다. 스칼라 연산은 그 일부만을 이용하는 구조로, x86의 SSE와 정확하게 같은 방식입니다. 스칼라를 로드할 때에도 레지스터 전체가 클리어됩니다.

32bit (ARMv7)에서는 Q(128bit) x 8 = D(64bit) x 16 = S(32bit) x 32가 같은 영역이었습니다. D는 S의 2개분이고, Q에는 S레지스터가 4개 포함되어 있습니다.

AArch32의 경우, 스칼라 연산은 레지스터의 일부 다시 쓰기에 해당되기에 그 때문에 파이프라인 실행효율이 떨어지는 것이라 예상됩니다.

fmadd가 느린 경향은 Swift와 같습니다. AArch64에서는 이 명령만 4 오퍼랜드였습니다.

A: 와 B: 는 다음과 같습니다.

; A: m44 fmla  A Q
ldp q0, q1, [%0]
ldp q2, q3, [%0,#32]
ldp q4, q5, [%1]
ldp q6, q7, [%1,#32]

fmul.4s	v8, v0, v4[0]
fmla.4s	v8, v1, v4[1]
fmla.4s	v8, v2, v4[2]
fmla.4s	v8, v3, v4[3]
str  q8, [%2]
〜
fmul.4s	v8, v0, v7[0]
fmla.4s	v8, v1, v7[1]
fmla.4s	v8, v2, v7[2]
fmla.4s	v8, v3, v7[3]
str  q8, [%2,#48]
; B: m44 fmla  B Q
ldp q0, q1, [%0]
ldp q4, q5, [%1]
ldp q6, q7, [%1,#32]

fmul.4s	v8,  v0, v4[0]
fmul.4s	v9,  v0, v5[0]
fmul.4s	v10, v0, v6[0]
fmul.4s	v11, v0, v7[0]
ldp	q2, q3, [%0,#32]
〜
fmla.4s	v8,  v3, v4[3]
fmla.4s	v9,  v3, v5[3]
fmla.4s	v10, v3, v6[3]
fmla.4s	v11, v3, v7[3]
stp  q8,  q9,  [%2]
stp  q10, q11, [%2,#32]

레지스터 번호가 일치하므로 굉장히 쓰기 쉬워졌습니다.

※ 이 글은 오가사와라 히로유키(小笠原博之) 씨가 블로그에 적은 글을 번역한 것입니다. 사정에 따라 예고없이 삭제될 수 있으므로 양해부탁드립니다.

iPhone 5s의 Apple A7 GPU

(원문 : iPhone 5s の Apple A7 GPU)

A7의 GPU는 「Apple A7 GPU」라고 표시되며 독자적인 이름이 붙어있습니다.

GL_VERSION: OpenGL ES 3.0 Apple A7 GPU - 27.10
GL_RENDERER: Apple A7 GPU
GL_VENDOR: Apple Inc.
GL_SHADING_LANGUAGE_VERSION: OpenGL ES GLSL ES 3.00

PVRTC에 대응하므로 PowerVR 계열일 가능성이 높습니다. 하지만 PVRTC(v2)가 없고 범용성이 높은 ETC2/EAC로 바뀌기도 해서 PowerVR에 의존하는 방침전환이 엿보이는 것 같습니다.

Mali-T604, Adreno 320과의 비교입니다. (참고)

                                      Nexus 7 (2013)  Nexus 10  iPhone 5s
                                        Adreno 320   Mali-T604   A7 GPU
-------------------------------------------------------------------------
=== GL3:texture
GL_MAX_3D_TEXTURE_SIZE                      1024       4096       2048
GL_MAX_TEXTURE_SIZE                         4096       4096       4096
GL_MAX_ARRAY_TEXTURE_LAYERS                 256        4096       2048
GL_MAX_TEXTURE_LOD_BIAS                     15.984     255.996    16.000
GL_MAX_CUBE_MAP_TEXTURE_SIZE                4096       4096       4096
GL_MAX_RENDERBUFFER_SIZE                    4096       4096       4096
GL_MAX_DRAW_BUFFERS                         4          4          4
GL_MAX_COLOR_ATTACHMENTS                    4          4          4
GL_MAX_VIEWPORT_DIMS                        4096       4096       4096
=== GL3:elements
GL_MAX_ELEMENTS_INDICES                     -1         16777216   150000
GL_MAX_ELEMENTS_VERTICES                    -1         16777216   1048575
=== GL3:vertex
GL_MAX_VERTEX_ATTRIBS                       16         16         16
GL_MAX_VERTEX_OUTPUT_COMPONENTS             69         64         64
=== GL3:pixel
GL_MAX_FRAGMENT_INPUT_COMPONENTS            71         60         64
=== GL3:program
GL_MIN_PROGRAM_TEXEL_OFFSET                 -8         -8         -8
GL_MAX_PROGRAM_TEXEL_OFFSET                 7          7          7
GL_MAX_VARYING_COMPONENTS                   64         60         60
GL_MAX_VARYING_VECTORS                      16         15         15
=== GL3:output stream
GL_MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS 64    64         64
GL_MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS       4     4          4
GL_MAX_TRANSFORM_FEEDBACK_SEPARATE_COMPONENTS    4     4          4
GL_MAX_SAMPLES                                   4     4          8
=== GL3:uniform block
GL_MAX_VERTEX_UNIFORM_COMPONENTS            1024       1024       2048
GL_MAX_VERTEX_UNIFORM_VECTORS               256        256        512
GL_MAX_VERTEX_UNIFORM_BLOCKS                12         12         12
GL_MAX_COMBINED_VERTEX_UNIFORM_COMPONENTS   --         50176      51200
GL_MAX_FRAGMENT_UNIFORM_COMPONENTS          896        4096       896
GL_MAX_FRAGMENT_UNIFORM_VECTORS             224        1024       224
GL_MAX_FRAGMENT_UNIFORM_BLOCKS              12         12         12
GL_MAX_COMBINED_FRAGMENT_UNIFORM_COMPONENTS 197504     53248      50048
GL_MAX_UNIFORM_BUFFER_BINDINGS              24         36         24
GL_MAX_UNIFORM_BLOCK_SIZE                   65536      16384      16384
GL_MAX_COMBINED_UNIFORM_BLOCKS              24         24         24
=== GL3:tex
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS           16         16         16
GL_MAX_TEXTURE_IMAGE_UNITS                  16         16         16
GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS         32         32         32

지금까지와는 다른 GPU라는 것을 알 수 있습니다.

Uniform Block 수는 다른 것과 마찬가지로 12입니다. Fragment의 Uniform 수는 Adreno와 마찬가지로 OpenGL ES 3.0의 최소치인 896(224)으로 Vertex 쪽이 높게 설정되어 있습니다. PowerVR 5는 다른 GPU와 비교해도 Uniform 수가 적어, 한번에 전송할 수 있는 데이터 량에 제한이 있었습니다. OpenGL ES 3.0의 A7에서는 이 부분이 해소되어 오히려 여유가 있습니다.

다만 OpenGL ES 2.0 Context에서의 호환성을 위해서인지 종래의 PowerVR SGX 5 계와 같은 값이 리턴되는 듯 합니다.

GL_VERSION: OpenGL ES 2.0 Apple A7 GPU - 27.10
GL_RENDERER: Apple A7 GPU
GL_VENDOR: Apple Inc.
GL_SHADING_LANGUAGE_VERSION: OpenGL ES GLSL ES 1.00

Precision:
 0: [15 15] 10
 1: [15 15] 10
 2: [127 127] 23
 3: [15 14] 0
 4: [15 14] 0
 5: [31 30] 0
 6: [15 15] 10
 7: [15 15] 10
 8: [127 127] 23
 9: [15 14] 0
10: [15 14] 0
11: [31 30] 0

=== GL2:texture
GL_MAX_TEXTURE_SIZE                      4096
GL_MAX_CUBE_MAP_TEXTURE_SIZE             4096
GL_MAX_VIEWPORT_DIMS                     4096
=== GL2:vertex
GL_MAX_VERTEX_ATTRIBS                    16
GL_MAX_VERTEX_UNIFORM_VECTORS            128
GL_MAX_VARYING_VECTORS                   8
=== GL2:pixel
GL_MAX_FRAGMENT_UNIFORM_VECTORS          64
GL_MAX_RENDERBUFFER_SIZE                 4096
=== GL2:tex
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS        8
GL_MAX_TEXTURE_IMAGE_UNITS               8
GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS      8

TextureFormat 4
00=8c00  GL_COMPRESSED_RGB_PVRTC_4BPPV1_IMG
01=8c01  GL_COMPRESSED_RGB_PVRTC_2BPPV1_IMG
02=8c02  GL_COMPRESSED_RGBA_PVRTC_4BPPV1_IMG
03=8c03  GL_COMPRESSED_RGBA_PVRTC_2BPPV1_IMG

Android 4.3 + OpenGL ES 3.0의 경우에는 사실상 2.0와 3.0으로 Context 차이가 없었지만, 이점에 있어서도 iOS다운 사양이 되어있습니다. 예를 들면 Android 4.2의 Mali-T604은 Fragment Uniform수가 256(vec4)였지만, 4.3에서는 OpenGL ES 2.0에서도 3.0과 마찬가지로 1024(vec4)를 리턴합니다.

OpenGL ES 2.0 Context에서는 Vertex Texture Unit이 유효하게 되어있다는 점이 마음에 걸립니다. A7만 그런건가 싶었지만 PowerVR SGX 5XT에서도 같은 값이 되어있으므로 iOS 7에서 추가된 것일지도 모르겠습니다.

위 글에도 적혀있습니다만 glGetShaderPrecisionFormat()의 결과에 차이가 보입니다. float lowp가 mediump와 같은 fp16이고, int highp도 32bit가 되어있습니다. 아래 페이지도 갱신했습니다.

다만 위 페이제도 적혀있듯 API로 얻을 수 있는 사양과 실제 연산결과가 다른 경우가 있습니다. 같은 fix10이라도 PowerVR series 5(SGX535/540) ＆ Tegra2/3와 series 5XT(SGX543MP/554MP)는 셰이딩 결과에 차이가 있습니다. 5XT 쪽이 Fragment 부분만 lowp의 정밀도가 높아져있는 것으로 보입니다.

A7 GPU의 경우에는 처음부터 fp16이므로, 호환성 측면에서도 잘 맞춰진 사양이라 생각합니다.

관련 글

※ 이 글은 오가사와라 히로유키(小笠原博之) 씨가 블로그에 적은 글을 번역한 것입니다. 사정에 따라 예고없이 삭제될 수 있으므로 양해부탁드립니다.

iPhone 5s A7 CPU의 부동소수점 연산속도 (32bit)

(원문 : iPhone 5s A7 CPU の浮動小数点演算速度 (32bit))

iPhone 5s의 부동소수점 연산속도를 명령단위로 비교해보았습니다. A7의 CPU core는 ARMv8으로 64bit 명령에 대응하지만, 여기서는 AArch32 (32bit mode)의 VFP/NEON 명령을 비교해보겠습니다. 64bit mode (AArch64)에서는 레지스터의 개수와 view가 다르므로 결과가 달라질 가능성이 있습니다.

                 (1)      (2)    (3)     (4)      (5)      (6)
                Nexus7  EVO 3D  iPhone5  HTL21  Nexus10  iPhone5s
              Cortex-A9 Scorpion Swift   Krait Cortex-A15   ?
                Tegra3  MSM8660    A6  APQ8064 Exynos5D     A7
                1.2GHz  1.2GHz  1.3GHz  1.5GHz  1.7GHz    1.3GHz?
-----------------------------------------------------------------
a:m44 vmla_A Q   3.959   2.859   1.293   1.337   0.619     0.700
b:m44 vmla_B Q   2.002   1.136   1.359   0.931   0.569     0.670
c:m44 vmla_A D   3.980   3.053   1.669   1.889   0.557     0.649
d:m44 vmla_B D   2.003   1.434   1.329   1.532   0.568     0.745
A:m44 vfma_A Q   -----   -----   1.632   1.882   0.746     0.707
B:m44 vfma_B Q   -----   -----   1.594   0.695   0.840     0.699
e:fadds      A   3.343   3.383   3.090   2.774   2.383     3.551
f:fmuls      A   3.337   3.383   3.167   2.747   2.369     3.475
g:fmacs      A   3.337   3.379   6.180   5.574   2.956     3.480
h:vfma.f32   A   -----   -----   6.180   2.747   2.957     3.480
i:vadd.f32 D A   3.426   3.377   3.091   2.762   1.183     1.031
j:vmul.f32 D A   3.421   3.383   3.168   2.746   1.478     1.545
k:vmla.f32 D A   3.792   3.380   3.166   5.604   1.480     1.567
l:vadd.f32 Q A   6.688   3.377   3.090   2.801   2.365     1.031
m:vmul.f32 Q A   6.681   3.384   3.166   2.761   2.364     1.548
n:vmla.f32 Q A   6.681   3.380   3.167   5.606   2.367     1.574
o:vfma.f32 D A   -----   -----   3.167   2.833   1.479     1.574
p:fadds      B   3.347   5.917   6.181   3.467   2.956     6.953
q:fmuls      B   4.195   5.917   6.180   3.556   3.558     6.652
r:fmacs      B   6.688   8.451  12.361   6.298   5.912     9.867
s:vfma.f32   B   -----   -----  12.363   3.430   5.910     9.859
t:vadd.f32 D B   3.421   5.916   3.090   3.529   2.958     3.663
u:vmul.f32 D B   3.422   5.073   3.169   3.447   2.364     3.114
v:vmla.f32 D B   7.561   8.451   6.180   6.293   4.728     6.185
w:vadd.f32 Q B   6.705   5.916   3.090   3.457   2.961     3.659
x:vmul.f32 Q B   6.683   5.074   3.167   3.428   2.363     3.101
y:vmla.f32 Q B   7.532   8.457   6.179   6.372   4.729     6.199
z:vfma.f32 D B   -----   -----   6.181   3.437   4.730     6.188

↑수치는 실행시간(초) 수치가 작을수록 고속

빠르다고 생각한 iPhone 5 A6의 Swift로부터 1년, A7은 더욱 강력한 연산능력을 갖고 있는 듯 합니다. 거의 동 클럭(?)에서도 Swift의 최대 3배의 스루풋을 내며, 클럭차가 있음에도 Cortex-A15에 필적하는 점수가 나오고 있습니다.

특히 NEON 명령이 고속이라는 걸 알 수 있습니다. D와 Q에서 차가 없으므로, 연산은 128bit 단위라고 예상할 수 있습니다. 그럼에도 Cortex-A15의 64bit 2pipe로 실현된 속도를 따라잡고 있으므로, 어디까지나 억측이지만 A7은 128bit pipe가 복수 존재하고 있을 가능성이 있습니다.

반면, VFP 쪽은 다른 CPU와 차이가 거의 없는 듯, 동작 클럭분만큼 차가 나고 있습니다. 다만 Swift에서 극단적으로 느렸던 스칼라의 덧곱셈[각주:1]명령에 있어서는 A7에서 제대로 결점을 극복했다는 것을 알 수 있습니다. 그래도 레이턴시는 Swift 정도는 아니지만 비교적 큰 편입니다.

ARMv8의 아키텍처 변경에 따라, NEON 명령에서도 배정밀도 연산이 지원되게 되었습니다. 이 테스트는 단정밀도의 32bit 부동소수점 연산이지만, 만약 배정밀도로 비교한다면 32bit ARMv7세대와는 차이가 훨씬 벌어지게 될겁니다.

x86에서도 SSE2가 배정밀도 연산을 지원하게 됨으로써, 호환성 목적 이외로는 FPU (x87)을 사용할 필요가 없어지게 되었습니다. 실제로 Windows x64의 64bit mode에서는 FPU를 사용하지 않고 SSE 명령만이 이용되고 있습니다.

마찬가지로 ARMv8도 Advanced NEON이 배정밀도를 커버함으로써 VFP를 나눌 필요가 없어지게 되었습니다. AArch32에서는 VFP 명령이었던 것이 AArch64에서는 NEON의 스칼라로 바뀌었음을 예상할 수 있습니다.

Krait, Swift, Cortex-A15과 ARMv7-A로 VFPv4세대의 CPU가 겨우 갖춰졌다 싶었더니, 그에 더해 새로운 세대의 CPU가 등장해버렸습니다. 진짜 퍼포먼스는 AArch64 (64bit mode)에서 발휘되므로, 지금부터가 진짜라 할 수 있겠습니다.

a:〜z: 각개의 상세와 설명은 과거의 기사를 참조해십시오. Cortex-A8을 포함한 여러 기종의 결과를 아래 페이지에 정리했습니다.

  1. 積和의 의역. 값을 곱하고 난 후 목표값에 더하는 명령. vmla, vfla등. [본문으로]

+ Recent posts

티스토리툴바