64bit ARM은 과연 의미가 있는가 (내용 추가, 스압 주의) : 클리앙

새소게에서 64비트 ARM 관련 얘기만 나오면 논란이 많은데요, 이 부분 정리 해 드리겠습니다.

일단 간단하게 제 소개를 드리자면 :

16년간 ARM 어셈블리만 해 온 최적화의 달인 암빠... 입니다.

16년은 아니고 ARM을 처음 접한지 정확히 11년 째네요. 그 한참 전에는 모토롤라 MC68k 시리즈로 작업 했고요.

현재는 이학렬 기자와 비슷한 처지입니다. 안드로이드로 돈 벌어서 아이폰이랑 맥북 사서 씁니다.

ARM의 64비트 전향을 한 단어로 요약하면 : 할렐루야

그럼 왜 그런지, (알고 그러는지 모르고 그러는지) 몇몇 분들이 퍼뜨리는 루머만 반박하면 간단하게 설명 가능합니다.

- 64비트 CPU가 32비트로 동작하면 에뮬레이션이라서 32비트 CPU보다 느리다 :

ARM은 아닙니다. 32비트 모드가 존재하지만 에뮬레이션이 아니라 전용 네이티브 모드입니다.

더군다나 파이프라인 유닛이 향상되어 64비트 v8이 32비트 모드에서 동클럭 v7보다 빠릅니다.

- 64비트는 앞으로는 몰라도 당장은 큰 의미가 없다 :

앱 개발자가 OS 최소 사양을 7 미만으로 설정하여도 v7/v8 하이브리드 바이너리가 생성된다면 이건 100% 틀린 말이고요 (앱 개발 손 뗀 지 좀 되어서 확인 불가능하니 현역이신 분 댓글로 답변 주시기 바랍니다) 그렇지 않다 하여도 반도 안 맞는 얘기입니다.

전자인 경우 iOS7 출시 이후 업데이트 된 앱이라면 5s에서 100% 64비트로 동작하고, 후자인 경우라도 64비트로 구현 된 웹킷 및 기본 OS 컴포넌트/프레임웍들의 잇점을 톡톡히 보게 됩니다. 더더군다나 HTML5로 작성 된 앱이라면 두 말 할 것도 없습니다.

- 64비트 전향이 애당초 퍼포먼스상 큰 잇점이 없다. 64비트 윈도우 보면 4기가 이상 사용 가능한 것 말고 무엇이 있는가 :

RISC와 CISC에는 큰 차이가 있습니다. RISC상에서는 CISC와 달리 레지스터 갯수가 엄청 중요한데 너무 깊게 내려가면 이해하시기 힘들테니 간단히 예를 들어보겠습니다.

고학생 출신 R군과 유복한 집의 C군이 인턴사원으로 입사 합니다. 월급은 160만원.

월급이 같다고 둘의 생활 수준이 같을까요? 그럴 리 없겠죠?

R군은 월급에서 세금, 4대보험, 교통비, 중식비등을 공제한 나머지 돈으로 학자금 대출 상환, 식비, 임대료 등 생활과 관련된 모든 것을 해결해야 합니다. 엄청 빡빡하죠.

반면 C군에게는 기본공제를 제외한 전체 금액이 그야말로 용돈입니다. 학자금 대출은 애당초 없고 숙식은 부모님이 해결 해 줍니다.

세월은 흘러 두 사람 다 인턴과정을 마치고 정사원으로 채용 됩니다. 급여도 320만원으로 인상되고요.

C군에게 급여인상은 큰 의미가 없습니다. 급여가 인상되었으니 부모님께서 용돈/생활비를 달라 하셔서 실제 굴릴 수 있는 돈은 인턴 시절과 별 차이가 없습니다.

반면 R군은 드디어 고생 끝 행복 시작입니다. 급여인상 이전과 동일한 생활수준을 유지한다면 월별 유용금액은 단순 두 배가 아니라 네다섯 배로 껑충 뛰는 것입니다.

이게 바로 RISC와 CISC의 차이입니다. ARMv8에서 레지스터 갯수가 16개에서 32개로 증가했는데, 이는 어마어마한 차이입니다.

ARM의 발전 과정을 보면 다음과 같습니다

ARMv5E (ARM9) : DSP 명령어 추가. 16비트 연산으로 속도 및 레지스터 효율 향상

ARMv6 (ARM11) : SIMD 유사 명령어 추가. 레지스터 부족으로 효율은 제한적임. VFP(FPU)추가.

ARMv7 (Cortex A8, A9, A15) : 비트 연산 명령어 추가. 듀얼/트리플 이슈 추가. 레지스터 부족으로 극도로 제한적인 성능 향상. NEON (SIMD) 추가

ARMv8 (Cortex A53, A57) : 64비트 명령어 풀셋 추가. 레지스터 갯수 2배(ARM 32개, NEON 64개)

요약하자면 CISC와 달리 RISC에서는 레지스터가 부족하여 그간 꾸준히 이루어진 아키텍쳐의 향상된 기능들이 극히 제한적인 성능 향상만을 가져왔다는 것입니다. 그런데 레지스터가 두 배가 되니 실제 가용 레지스터는 네다섯배로 껑충 뜁니다.

즉, 레지스터 부족으로 인한 고질적인 병목현상이 완전히 해소되는 것으로, 그야말로 봉인이 풀리는 수준의 성능향상이 나옵니다.

반면 여기서 NEON은 좀 다른데요, v7에서 32개의 NEON레지스터는 대부분의 경우 부족하지 않습니다.

즉, NEON에 의존적인 루틴들은 상대적으로 v8에서 성능향상이 거의 없다고 볼 수 있지만 두 가지 예외가 있습니다 : DCT와 Image Processing입니다.

8x8 DCT Type II는 (일명 iDCT) jpeg과 동영상 디코딩시 반드시 필요하고, 데이터 사이즈 대비 연산량이 어마어마한 루틴입니다.

32개의 레지스터는 부족하여 트랜스폼을 가로로 한 번 하여 중간 저장하고 이를 가지고 세로로 처리하여 최종 결과물을 만들어 내는데요, 64개의 레지스터로는 이를 한 큐에 처리 할 수 있게 됩니다. 각종 벤치에서 보듯이 jpeg과 동영상에서 상당한 수준의 성능향상이 나타남은 물론 중간 저장 과정이 생략되는 만큼 전력소모도 크게 줄어듭니다. (메모리 RW가 전력소모가 큽니다)

또한 32개의 레지스터로는 3x3까지의 이미지 필터만 싱글패스로 가능했는데 64개라면 9x9까지도 싱글패스 처리 가능합니다. 예를 들어 일명 뽀샤시로 통하는 5X5 Gaussian Blur쯤은 완전 껌으로 FHD 해상도 카메라 프리뷰 실시간 처리 가능합니다.

한 줄 요약 : 모바일에서 64비트와 32비트의 차이는 어마어마하다. 몇 푼 아끼자고 5S대신 5C를 구매하는 것은 치명적인 실수이다.

아이폰 싫증나서 넥서스5 나오면 갈아타려 했는데 5S가 64비트로 출시되는 바람에 계획이 무산되었네요. 어서 25일이 와서 문서로만 보던 64비트 명령어 실제로 써보고 싶습니다. (개발자 프로그램 리뉴얼 해야겠네요)

아이러니하게도 아이폰에서 안드로이드용 64비트 코드 구현하게 생겼습니다.

내년에는 자칫하면 64비트 기기에 32비트 안드로이드 탑재되어 출시되는 엽기적인 상황이 연출 되겠네요.

밥벌이 차원에서라도 그러지 않기를 바라지만 안드로이드는 너무 복잡하게 이해관계가 얽혀있어서 내년 가을 넥서스 신모델 쯤 되어서야 64비트로 전향하지 싶습니다.

내용 추가 :

자고 일어나서 접속했더니 완전 흥하는군요.

서정우님 지적하신대로 명령어 인코딩은 32비트가 맞습니다. 지적 감사합니다.

내킨 김에 밀린 숙제 하는 기분으로 v8 명령어를 익혔는데 일단 꽤 실망스럽습니다. 제 소감은 이렇습니다 :

+ 32비트 레지스터 32개, 혹은 64비트 16개가 아니라 64비트 32개임. 따라서 레지스터 용량은 두 배가 아니라 네 배임

+ 메모리 관련 명령어들이 영리해짐 ==> 캐쉬 효율 상승

- 명령어가 전반적으로 단순화되고 약화 됨. 메모리 명령어는 강화, 곱셈은 약화

- conditional execution, inline barrel shifter 대폭 하향

- v5E, v6, v7을 거치며 추가된 명령어들 대부분 칼질 당함

- SIMD식 처리 지원 없음

테스트 해 본 코드는 간단한 BGRA 알파블렌딩 처리입니다. A15용 디스어셈블리 루프 내부를 보면 다음과 같습니다. (이러고 싶진 않았는데 결국 하드코어하게 가는군요) :

1 LDR r6,[r1],#4 SUBS r10,r10,#1

1 LDR r4,[r2],#4

2 LSR r3,r6,#24 UBFX r8,r6,#8,#8

2 UBFX r9,r4,#16,#8 RSB r12,r3,#0xff UBFX r11,r6,#16,#8

2 MUL r9,r9,r12 UBFX r7,r4,#8,#8 UXTB r6,r6

2 MUL r7,r7,r12

1 STR r6,[sp,#4]

0 *UXTB r6,r4 LSR r4,r4,#24

2 MLA r9,r3,r11,r9

2 MLA r7,r3,r8,r7

2 MUL r6,r6,r12

3 UMULL r8,r9,r5,r9

1 LDR r8,[sp,#4]

2 MUL r4,r4,r12

3 UMULL r12,r7,r5,r7 LSR r9,r9,#7

2 MLA r6,r3,r8,r6

2 MLA r3,r3,r3,r4

1 LSL r9,r9,#16 LSR r7,r7,#7

3 UMULL r12,r6,r5,r6 ADD r7,r9,r7,LSL #8

3 UMULL r8,r3,r5,r3

2 ADD r6,r7,r6,LSR #7 LSR r3,r3,#7

2 ADD r3,r6,r3,LSL #24

1 STR r3,[r0],#4

멀티플 이슈 가능한 부분 전부 한 라인으로 처리했고, 앞의 숫자가 라인당 소요 사이클입니다.

i로 시작하는 라인은 인터락입니다. 해저드라고도 합니다.

0이 붙고 * 처리한 라인은 OOE(Out of Order Execution)에 의하여 그 전 라인에 꼽사리 끼여서 처리 가능한 파트입니다. 딱 한 군데 있군요. 그나마 컴파일러가 똑똑했다면 아예 발생 안 했을겁니다.

루프 1회당 1픽셀만 처리하며, 레지스터가 부족하여 언롤링 불가합니다. 46 사이클 소요합니다.

어셈블리 프로그램 해 보면 느끼지만 OOE야말로 실제로 별 도움이 안 되는 기능입니다.

중간에 메모리 저장 명령어가 있으면 그 후 따라오는 어떤 메모리 관련 명령어 및 이와 연관된 명령어들을 그 앞으로 댕겨오지 못 합니다.

간단한 함수라면 어차피 언롤링을 통하여 다중실행 증가 및 인터락 감소를 도모 할 수 있으니 쓸모가 없고 타이트한 상황에서는 레지스터가 부족하여 전혀 도움이 안 됩니다.

다음은 인간 컴파일러가 작성한 동일한 기능을 하는 v8 코드입니다 (스압 주의) :

ldnp	x4,x6,[x1],#16	subs	w3,w3,#8
ldnp	x5,x7,[x2],#16	ubfx	w15,w4,#24,#8	ubfx	w12,w4,#0,#8
ldnp	x8,x10,[x1],#16	ubfx	w13,w4,#8,#8	ubfx	w14,w4,#16,#8
ldnp	x9,x11,[x2],#16	rsb	w29,w15,#255	ubfx	w16,w5,#0,#8
mul	w13,w13,w15	ubfx	w17,w5,#8,#8	ubfx	w18,w5,#16,#8
mul	w14,w14,w15	ubfx	w19,w5,#24,#8	ubfx	x23,x4,#56,#8
mul	w15,w15,w15	ubfx	x20,x4,#32,#8	ubfx	x21,x4,#40,#8
mul	w12,w12,w15	ubfx	x22,x4,#48,#8	rsb	w28,w22,#255
mla	w12,w16,w29,w12	ubfx	x24,x5,#32,#8	ubfx	x25,x5,#40,#8
mla	w13,w17,w29,w13	ubfx	x26,x5,#48,#8	ubfx	x27,x5,#56,#8
mla	w14,w18,w29,w14
mla	w15,w19,w29,w15
mull	x12,w12,w30
mull	x13,w13,w30
mull	x14,w14,w30
mull	x15,w15,w30
mul	w20,w20,w23	ubfx	x12,x12,#32,#8	ubfx	x13,x13,#32,#8
mul	w21,w21,w23	ubfx	x14,x14,#32,#8	ubfx	x15,x15,#32,#8
mul	w22,w22,w23	ubfx	w15,w6,#24,#8	ubfx	w12,w6,#0,#8
mul	w23,w23,w23	ubfx	w13,w6,#8,#8	ubfx	w14,w6,#16,#8
mla	w20,w24,w28,w20	rsb	w29,w15,#255	ubfx	w16,w7,#0,#8
mla	w21,w25,w28,w21	ubfx	w17,w7,#8,#8	ubfx	w18,w7,#16,#8
mla	w22,w26,w28,w22	ubfx	w19,w7,#24,#8
mla	w23,w27,w28,w23
mull	x20,w20,w30
mull	x21,w21,w30
mull	x22,w22,w30
mull	x23,w23,w30
mul	w13,w13,w15	ubfx	x20,x20,#32,#8	ubfx	x21,x21,#32,#8
mul	w14,w14,w15	ubfx	x22,x22,#32,#8	ubfx	x23,x23,#32,#8
mul	w15,w15,w15	orr	w24,w12,w13,lsl #8	orr	w25,w14,w15,lsl #8
mul	w12,w12,w15	orr	w26,w20,w21,lsl #8	orr	w27,w22,w23,lsl #8
mla	w12,w16,w29,w12	orr	w4,w24,w25,lsl #16	orr	w5,w26,w27,lsl #16
mla	w13,w17,w29,w13	ubfx	x23,x6,#56,#8	ubfx	x20,x6,#32,#8
mla	w14,w18,w29,w14	ubfx	x21,x6,#40,#8	ubfx	x22,x6,#48,#8
mla	w15,w19,w29,w15	rsb	w28,w22,#255	ubfx	x24,x7,#32,#8
mull	x12,w12,w30	ubfx	x25,x7,#40,#8	ubfx	x26,x7,#48,#8
mull	x13,w13,w30	ubfx	x27,x7,#56,#8
mull	x14,w14,w30
mull	x15,w15,w30
mul	w20,w20,w23	ubfx	x12,x12,#32,#8	ubfx	x13,x13,#32,#8
mul	w21,w21,w23	ubfx	x14,x14,#32,#8	ubfx	x15,x15,#32,#8
mul	w22,w22,w23	ubfx	w15,w8,#24,#8	ubfx	w12,w8,#0,#8
mul	w23,w23,w23	ubfx	w13,w8,#8,#8	ubfx	w14,w8,#16,#8
mla	w20,w24,w28,w20	rsb	w29,w15,#255	ubfx	w16,w9,#0,#8
mla	w21,w25,w28,w21	ubfx	w17,w9,#8,#8	ubfx	w18,w9,#16,#8
mla	w22,w26,w28,w22	ubfx	w19,w9,#24,#8
mla	w23,w27,w28,w23
mull	x20,w20,w30
mull	x21,w21,w30
mull	x22,w22,w30
mull	x23,w23,w30
mul	w13,w13,w15	ubfx	x20,x20,#32,#8	ubfx	x21,x21,#32,#8
mul	w14,w14,w15	ubfx	x22,x22,#32,#8	ubfx	x23,x23,#32,#8
mul	w15,w15,w15	orr	w24,w12,w13,lsl #8	orr	w25,w14,w15,lsl #8
mul	w12,w12,w15	orr	w26,w20,w21,lsl #8	orr	w27,w22,w23,lsl #8
mla	w12,w16,w29,w12	orr	w6,w24,w25,lsl #16	orr	w7,w26,w27,lsl #16
mla	w13,w17,w29,w13	ubfx	x23,x8,#56,#8	ubfx	x20,x8,#32,#8
mla	w14,w18,w29,w14	ubfx	x21,x8,#40,#8	ubfx	x22,x8,#48,#8
mla	w15,w19,w29,w15	rsb	w28,w22,#255	ubfx	x24,x9,#32,#8
mull	x12,w12,w30	ubfx	x25,x9,#40,#8	ubfx	x26,x9,#48,#8
mull	x13,w13,w30	ubfx	x27,x9,#56,#8
mull	x14,w14,w30
mull	x15,w15,w30
mul	w20,w20,w23	ubfx	x12,x12,#32,#8	ubfx	x13,x13,#32,#8
mul	w21,w21,w23	ubfx	x14,x14,#32,#8	ubfx	x15,x15,#32,#8
mul	w22,w22,w23	ubfx	w15,w10,#24,#8	ubfx	w12,w10,#0,#8
mul	w23,w23,w23	ubfx	w13,w10,#8,#8	ubfx	w14,w10,#16,#8
mla	w20,w24,w28,w20	rsb	w29,w15,#255	ubfx	w16,w11,#0,#8
mla	w21,w25,w28,w21	ubfx	w17,w11,#8,#8	ubfx	w18,w11,#16,#8
mla	w22,w26,w28,w22	ubfx	w19,w11,#24,#8
mla	w23,w27,w28,w23
mull	x20,w20,w30
mull	x21,w21,w30
mull	x22,w22,w30
mull	x23,w23,w30
mul	w13,w13,w15	ubfx	x20,x20,#32,#8	ubfx	x21,x21,#32,#8
mul	w14,w14,w15	ubfx	x22,x22,#32,#8	ubfx	x23,x23,#32,#8
mul	w15,w15,w15	orr	w24,w12,w13,lsl #8	orr	w25,w14,w15,lsl #8
mul	w12,w12,w15	orr	w26,w20,w21,lsl #8	orr	w27,w22,w23,lsl #8
mla	w12,w16,w29,w12	orr	w8,w24,w25,lsl #16	orr	w9,w26,w27,lsl #16
mla	w13,w17,w29,w13	ubfx	x23,x6,#56,#8	ubfx	x20,x6,#32,#8
mla	w14,w18,w29,w14	ubfx	x21,x6,#40,#8	ubfx	x22,x6,#48,#8
mla	w15,w19,w29,w15	rsb	w28,w22,#255	ubfx	x24,x7,#32,#8
mull	x12,w12,w30	ubfx	x25,x7,#40,#8	ubfx	x26,x7,#48,#8
mull	x13,w13,w30	ubfx	x27,x7,#56,#8
mull	x14,w14,w30
mull	x15,w15,w30
mul	w20,w20,w23	ubfx	x12,x12,#32,#8	ubfx	x13,x13,#32,#8
mul	w21,w21,w23	ubfx	x14,x14,#32,#8	ubfx	x15,x15,#32,#8
mul	w22,w22,w23	orr	x4,x4,x5,lsl #32	orr	x5,x6,x7,lsl #32
mul	w23,w23,w23
mla	w20,w24,w28,w20
mla	w21,w25,w28,w21
mla	w22,w26,w28,w22
mla	w23,w27,w28,w23
mull	x20,w20,w30
mull	x21,w21,w30
mull	x22,w22,w30
mull	x23,w23,w30	ubfx	x20,x20,#32,#8
stnp	x4,x5,[x0],#16	ubfx	x21,x21,#32,#8	ubfx	x22,x22,#32,#8
ubfx	x23,x23,#32,#8	orr	w24,w12,w13,lsl #8	orr	w25,w14,w15,lsl #8
orr	w26,w20,w21,lsl #8	orr	w27,w22,w23,lsl #8	orr	w10,w24,w25,lsl #16
orr	w11,w26,w27,lsl #16	orr	x6,x8,x9,lsl #32
orr	x7,x10,x11,lsl #32
stnp	x6,x7,[x0],#16

레지스터가 넉넉하여 루프 1회당 8픽셀 처리합니다. 제로 인터락에 OOE는 전혀 불필요합니다. (ARM빠이지만 ARM에서 그렇게 내세운 OOE에 대해선 회의적입니다)

루프 1회당 210 사이클 소요하는데, 공식 자료가 없는 관계로 추정치입니다. 5S 있으면 테스트 해 보겠는데 갑갑하네요.

이보다 더 소요한다면 최대 32사이클 늘어나고, 제가 희망하는게 맞다면 100사이클가량 줄어듭니다.

추정치인 210사이클을 기준으로 계산 해 보면 46/(210/8) = 1.752...

대략 75% 가량의 성능 향상이 있을테고, 여기에 추가로 캐쉬 버프가 발생하므로 대략 90%가량의 성능향상이 있으리라 봅니다.

몇몇 분들이 정말로 궁금해 하시는건지, 아니면 트집 잡으려 그러는건지 자꾸 64비트라서 덕을 본게 얼만큼이냐 하시는데, 그에 대한 제 답변은 다음과 같습니다 :

- 늘어난 레지스터의 잇점 : 공격적인 언롤링 가능=>인터락 제로, 다중실행 증가 및 캐쉬 효율 상승

- 신형 아키텍쳐상의 잇점 : 캐쉬 힌팅 메모리 명령어

- 64비트의 잇점 : 메모리 RW 2배속, 32비트 long 곱셈 명령어 2배속, 넓은 레지스터로 인한 효율 상승/추가 언롤 => 인터락, 다중실행, 캐쉬 관련 성능 향상

전체적인 관점에서 레지스터 갯수가 늘어난 것이 아키텍쳐상의 잇점이라 칠 때 64비트가 가져오는 잇점과 얼추 비슷한 것으로 보입니다.

캐쉬라는 것이 워낙에 며느리도 모르는 별개의 생명체인지라 구체적인 수치화는 불가능합니다.

5S 수령하면 실제 벤치마크 구동하여 내용 추가하거나 새로 글 올리겠습니다.

PS : 상기 64비트 코드는 문서만 보고 손으로 작성한 것이므로 오류의 가능성이 높습니다. 그러나 전체적인 카운팅에는 큰 차이가 있을 수 없습니다.

팁과강좌

PC/모바일 64bit ARM은 과연 의미가 있는가 (내용 추가, 스압 주의) 193