A7의 성능과 64비트 CPU 성능 by 김민장

역시 애플이 나서야 하는가. 모바일에서도 분명 64비트가 필요하긴 하지만, 2015년 정도라고 생각했는데, 애플이 아이폰 5S에서 64비트 A7 SOC를 내놓았다. 애플이 이렇게 64비트를 내놓으니 일반인들까지 64비트 이야기를 하게 되었다. 나는 애플의 이 64비트 전환을 아주 긍정적으로 생각한다. 그래야 다른 경쟁자들도 빨리 64비트를 내놓아 개발 생태계도 64비트로 옮겨갈 수 있고, 더 높은 성능의 장치와 응용을 기대할 수 있어서이다. 한편, A7 SOC의 ARM 프로세서 성능이 매우 인상 깊다. 이 이야기와 일반적인 64비트 성능 이야기를 좀 해보자.

 

iPhone 5S A7의 놀라운 성능 향상

AnandTech의 A7 CPU의 성능을 보면 매우 놀랍다. 물론, 벤치마크 점수에 온갖 꼼수가 다 들어간 건 다 알고 있지만, 여기서는 같은 아이폰에서의 결과이고 절대적인 점수보다 상대적인 발전을 본다.

이전 세대 A6 (iPhone 5)에 비해 A7 (5S)의 Geekbench 점수는 50%, 64비트는 거의 두 배 가까이 향상 되었다. 아니 지금이 클럭 속도가 두 배씩 올라 성능 역시 마구 두 배씩 증가하는 시절인가?? 그런데 클럭 속도는 A6, A7 모두 1.3GHz로 동일하다. 결국 이 성능 차이는 메모리 성능, L2 캐시 성능, 마이크로아키텍처 차이 외에는 설명이 안 된다. L2 캐시 크기는 역시 모두 1MB로 같으나 레이턴시 등은 얼마든지 개선될 수 있다. 참고로 iPhone 4S는 클럭 속도가 800MHz 였다.

인텔은 상당히 세부적인 CPU 구조도 개발자 포럼 등으로 공개를 한다. 하지만 이넘의 모바일 프로세서들은 공개된 자료가 너무나 제한적이다. 회사 내에 안드로이드 드라이버 만드는 분의 이야기를 들었는데, 프로세서 버그로 의심되는 것이 보여 그 쪽 팀에 물으니 절대 이메일로 안 알려주고 전화로만 알려준다고 한다. 제품의 개발 주기가 데스크탑 시절보다 훨씬 짧고, 경쟁이 치열하다 보니 같은 회사 내에서도 구체적인 내용이 공유가 안 되는 것 같다. 아시다시피 A6/A7은 모두 애플이 직접 설계한 구조이다. 아무리 애플의 보안이 예전 같지 않다 하더라도 A7의 자세한 파이프라인 구조를 알 길은 거의 없어 보인다. 물론 거시적인 구조는 예측이 되지만 인텔 프로세서 내부 만큼 알 수가 없다.

그렇다면 도대체 같은 클럭에서 이렇게 성능이 개선된 이유가 뭘까.

대충 나의 짐작으론 아직 모바일 영역에서 비순차 프로세서가 도입된 것이 얼마 되지 않았기에 개선의 여지가 꽤 있는 것 같다. 모바일에서는 아직 데스크탑 수준의 비순차 실행, 그러니까 가능한 모든 명령에 대해 최대한 비순차 실행이 제대로 다 안 되는 걸로 알고 있다. 다른 몇몇 이야기도 들었지만 여기서 쓰기는 그렇고, 대략 아직 동 클럭 내에서 성능 향상의 여지가 있다고 봐도 좋을 것이다.

그래도 클럭과 발열이라는 강력한 제한이 있는 모바일에서 앞으로도 이런 두 배 - 두 배라는 정의가 매우 모호하지만 - 씩 증가하는 성능을 언제까지 보여줄지는 회의적이다. 과거 펜티엄 4에서 Core로 넘어올 땐 엄청난 싱글 스레드 성능 향상이 있었는데, 이제는 그런 것을 기대할 수 없다. 최신 Haswell이 이전 Ivy Bridge에 비해 같은 클럭 당 성능이 50%씩 증가하는 건 아니다.

어쨌거나 벤치마크 점수만 보면 애플은 ARM 모바일 프로세서에서도 거의 최고 수준의 설계 능력을 가지고 있음을 보여줬다. 현 스냅드래곤(Krait)의 다음 세대가 나오는 내년이 되어봐야 얼마나 A7의 위치를 판단할 수 있을 것이다. 그런데 64비트를 당장에 준비하지 않은 걸로 알고 있는데 경쟁사들의 대응이 어떻게 될지 궁금하다. 날짜를 앞당겨서라도 경쟁사들도 내년에 64비트 칩을 내놓을 것 같다.

 

A7 32비트 벤치마크 점수 자세히 보기

벤치마크 점수에는 치팅을 차치하고서라도 늘 맹점이 있음을 유의해야 한다. Geekbench 기준, 전체 점수로는 32비트 기준 50%의 향상이 있었다. Geekbench를 살펴보니 C 아니면 C++로 만들어진 네이티브 벤치마크이고 정수/실수/메모리 성능을 작은 벤치마크를 여러 돌려서 전체 점수를 합한다. 여기에는 압축(Bzip2, JPEG, PNG), 암호(AES, SHA1), 그래프 연산(Dijkstra), 스텐실 연산(Sharpen/Blur filters) 등이 있다.

아난드텍과 Geekbench에서 공개된 A6 자료로 각 세부 벤치마크 별 A6 (32-bit) 대비 A7 (32-bit)의 성능 향상 정도를 비교해봤다. 무려… 엑셀로 그렸다. 참고로 MT가 붙은 것은 멀티스레드로 작동한 버전을 가리킨다.

A6 대비 A7의 성능 향상: A7 성능/A6 성능으로 구함. 클럭은 모두 1.3GHz로 같음. 붉은 선 아래는 성능 하락. 녹색 선은 전체 평균.

기하 평균으로 정수 프로그램에서는 1.4배, 실수 프로그램에서는 1.7배, 전체적으로 약 1.5배 정도 나온다. 그래프에서 보다시피 붉은 선 아래에 있는 오히려 성능이 떨어진 프로그램도 하나 있었고, 전체 기하 평균인 녹색 선 아래에 있는 벤치마크가 더 많다. 별로 놀랍지 않는 사실이다. 보통은 몇몇 프로그램에서 큰 성능 개선이 이뤄져서 전체 평균이 높아지는 경향이 있다. 이런 통계/평균의 맹점을 고려하더라도 같은 클럭에서 이 정도의 성능 향상은 사실 정말 대단한 것이다. 20-30%의 성능 향상이 대부분에 걸쳐 나타난다. 물론, 절대 치팅이나 소프트웨어 속임수를 하지 않는다고 가정이 필요하다.

정수 프로그램에서 특별히 빨라진 것은 Sobel (경계 추출 이미지 프로세싱 알고리즘), Lua (루아 스크립트 코드), JPEG 해제이다. Dijkstra 그래프 알고리즘도 40%나 빨라진 것도 매우 인상 깊다. 하지만 왜 Mandelbrot 벤치마크 성능이 하락했는지 상당히 궁금하다. 자세한 마이크로아키텍처를 모르니 이런 변화를 별 설명할 길이 없다. 그냥 전체적으로 빡세게 잘 만든 것 같다….

참고로 나는 자바스크립트/안드로이드 자바 벤치마크가 그다지 CPU의 원 성능을 가늠하는 좋은 잣대라고 생각하지 않는다. 자바스크립트는 웹브라우저의 자바스크립트 엔진(JIT 컴파일러)의 성능에 매우 많은 영향을 받는다. 안드로이드 기반 벤치마크 역시 그러하다. 물론 비 NDK 앱에 한해서이다. 특히, Quadrant 벤치마크 같은 경우는 핵심 루프가 매우 짧다. 여기서 자바 컴파일러가 최적화를 어떻게 하냐에 따라 점수가 큰 폭으로 변하기 쉽다. 그래서 벤치마크가 JIT 기반인 것은 늘 주의해서 봐야 한다. 간단하게 말하면 소프트웨어의 영향을 심하게 받을 수 있다. 완벽하게 동일한 웹브라우저와 순정 안드로이드가 아니면 소프트웨어로 인한 차이가 클 수 있다. 이에 비해 네이티브 기반 벤치마크는 CPU의 원 성능을 더 잘 드러낸다. 물론 컴파일러가 당연히 영향을 줄 수 있고, 컴파일러 수준에서 치팅도 가능하다.

이미 말했듯이 모든 회사들은 이런 벤치마크 점수에 굉장히 민감하다. 온갖 최적화, 어떨 때는 도를 넘어서 속임수도 쓴다. 모바일 같이 발열/배터리가 중요한 곳에서는 벤치마크가 작동할 때 그냥 더 빡세게 하드웨어를 돌리는 것으로 치팅을 하기도 하지만, 더 심한 치팅도 과거에 많았다. 그래픽 드라이버에서 특정 게임이 실행되면 몇몇 작업을 빼버려 점수를 더 잘나오게 한다거나, 아주 심한 건 자바 컴파일러가 특정 벤치마크의 패턴을 인식해 ‘정답’을 내놓기도 한다. 컴파일러가 하기 어려우니 손으로 최적화한 정답 코드로 바꿔치기 하는 것이다. 물론 이런 부정은 사라져야 한다.

 

A7 32비트에서 64비트의 성능 향상

이번에는 같은 A7에서 같은 벤치마크에서 32비트에서 64비트 변환 시 성능 향상이다. 4개의 벤치마크 성능이 대폭으로 향상이 되어 통계 값이 왜곡이 많이 된다. 원 자료는 아래와 같다.

보다시피 AES가 너무 튄다. 그래프 상한선을 2배까지로 제한해서 좀 사실적인 결과를 보자.

전체적으로는 1.4배 정도의 성능 향상이 있었으나 특별히 많이 오른 AES/SHA/DGEMM/SFFT를 제외하면 64비트의 성능 향상은 1.1배이다. 대략 10%의 향상인데, 그러니까 컴파일만 64비트에 새로 해서 10% 성능이 오른 것이다. 물론 Geekbench 제작자가 64비트 전용 최적화를 손수 했는지는 모른다. 그랬으면 이야기가 좀 달라지겠지만, 큰 노력을 안 하고 64비트로 재컴파일만 해서 얻은 10% 성능 향상은 분명 의미 있다. 하지만 나빠지는 결과도 있다. Dijkstra가 특히 성능이 많이 하락하였다. 몇몇 벤치마크는 성능이 하락하기도 하지만 대략 5~10% 정도의 성능 향상은 x86에서도 보통 볼 수 있는 수치이다 (참고 논문 하나). 이 큰 폭의 성능 상승/하락은 뒤에서 설명한다.

먼저, 일반적인 32비트에서 64비트 프로세서의 전환의 의미를 알아보자.

CPU가 가장 빨리 수행할 수 있는 연산은 정수 덧셈/뺄셈/비트연산이다. 이 정수의 크기가 32비트에서는 32비트이고 64비트에서는 64비트가 된다. 64비트 정수 계산을 명령어 하나로 지원하려면 레지스터 크기 역시 64비트가 되어야 하며, 데이터패쓰(datapath) 내 버스도 두 배 늘려야 한다. 이 덕분에 메모리 주소를 가리키는 포인터 역시 64비트가 되어 사용 가능한 메모리가 4GB에서 2^64라는 숫자까지 된다. 32비트 시절에도 우회적인 방법으로 4GB 이상의 메모리를 쓸 수 있었지만, 64비트는 이런 임시 방편 필요 없이 깔끔하게 해결된다. 64비트의 완전한 구현은 부담이 되기도 한다. 특히 페이지 테이블이나 캐시는 64비트 주소를 다뤄야 한다. 그래서 인텔이나 ARM이나 64비트 주소 공간을 지금 당장 쓰는 건 아니고 48비트까지만 허용한다.

이 변화는 그냥 일반적인 64비트의 장점이다. 요약하면 32비트에서는 최소 두 개 이상의 연산이 필요한 64비트 연산이 하나로 되고, 4GB 넘는 메모리를 쉽게 쓸 수 있다.

그런데 이왕 64비트 같은 새로운 아키텍처로 넘어갈 때 다른 부분도 개선을 같이 하면 좋을 것이다. ARM이나 x86처럼 매우 널리 쓰이는 구조는 하위호환성이 생명이므로 새로운 명령어를 추가하는 것 같은 제한적인 진보만 할 수 있다. 그래서 64비트 같이 모드가 바뀌는 시점이 좋은 기회이다. x86 역시 그러했고 ARM 역시 그러하다.

ARMv8 Technology Preview에서 가져옴. (링크)

ARM의 64비트 구조는 ARMv8라 불리며 당연히 예전 32비트 모드를 지원한다. 단순히 64비트로의 이전 외에 ARMv8가 이전 구조에 비해 개선된 점은 대략 이러하다.

  • 범용 목적 레지스터(GPR, general purpose register) 개수가 32비트 시절의 16개에서 거의 두 배가 되어 31개.
  • SIMD 명령어 강화: 128비트 레지스터가 기존의 16개에서 32개로 증가. Double 형 지원.
  • AES 암호, SHA 해시 명령어 추가

이 변화로 위 벤치마크 점수 변화를 설명할 수 있다. AES/SHA가 각각 9배, 3.5배 증가한 것은 “64비트”가 되어서가 아니라 64비트 ARM 구조에서 AES/SHA 가속이 되어서이다. 아난드텍의 분석에 따르면 DGEMM/SFFT는 double을 쓰는데 ARMv8의 개선된 SIMD가 double을 지원해서이다. 따라서 이 4개 벤치마크를 제외해야 레지스터 두 배 증가와 64비트 연산의 이득/손실을 볼 수 있다. SIMD나 암호 연산은 굳이 64비트 전환이 아니더라도 언제든지 추가할 수 있기 때문이다.

Dijkstra 프로그램이 거의 25% 정도 성능이 하락했다. Dijkstra 벤치마크는 그래프 자료구조에서 최단 거리를 찾는 알고리즘인데, 그래프가 행렬로 표현이 되었다면 이런 큰 손실은 없을 것이다. 아마 노드 기반이고, 노드 크기가 여기서 크지 않으므로, 결국 두 배 커지는 포인터가 큰 부담이 된다. 포인터 기반 자료구조는 생각보다 64비트에서 메모리 사용량이 크게 늘 수 있다. 결국 이것으로 캐시 성능이 나빠지니 전체적인 성능 하락으로 연결된다. 나도 이 문제로 고생을 많이 하였는데, 그래서 64비트 포인터에서 아직 쓰지 않는 상위 16비트에 다른 정보를 저장해 메모리를 아끼는 짓도 해보았다.

 

간단한 프로그램으로 64비트 성능 비교

64비트 CPU의 성능 차이를 시각화 해보고자… 간단한 프로그램을 만들어서 그냥 x86 컴퓨터에서 돌려보았다. 검증할 건 레지스터의 개수 차이와 64비트 연산이다. x86에서도 64비트로 가면서 범용 목적 레지스터가 두 배 늘었다 (8개 –> 16개). 그래서 ARM도 이 결과와 비슷할 것이다.

  • 두 배가 된 레지스터 영향: Register spill(레지스터가 부족해 스택 메모리로 잠시 변수 값을 보냄)이 64비트에서는 안 나고 32비트에서는 나는 코드를 만들어 봄.
  • 64비트 정수 연산의 영향: 그냥 변수 연산을 할 때 32비트냐 64비트로 조절.

코드는 무지 간단한데 여기서 볼 수 있다. (코드에 대해 부연 설명을 하면: 의도적으로 for 루프 안에 여러 변수들에 대해 정수 연산을 할 때 직렬로 이루어지도록 의존성을 차례대로 걸었다. +을 안 쓰고 &-^|를 쓴 이유는 x86 컴파일러는 +이 있으면 add 보다 lea를 이용해 코드를 생성한다. 보기가 안 좋아 +는 안 썼다. 컴파일러는 Visual Studio 2013 RC 버전을 이용했고 최적화는 최대한으로. 레지스터를 최대로 쓰고자 omit frame pointer 최적화도 켬.)

이쯤 되니 너무 귀찮아져서 그냥 절대 수행시간으로 그래프를 그렸다.

보다시피 같은 코드인데 어떤 것은 성능이 똑같고 어떤 것은 3배까지 벌어졌다. 각 경우를 살펴보면 이러하다.

(1) 붉은 색 막대끼리 비교: 64비트 모드에서는 32비트/64비트 정수 연산에 속도 차이는 없다. (단, 곱셈/나눗셈은 테스트 안 함.)

(2) 맨 왼쪽 No Spill + 32비트 연산: 레지스터 스필이 나지 않고 32비트 연산만 하면 64비트 코드와 성능 차이는 없다.

(3) 두 번째 그룹, No Spill + 64비트 연산: 성능이 거의 3배 나빠졌다 (2초 => 6초). 32비트에서 64비트 연산을 하려고 하니 상위 32비트/하위 32비트로 나누어서 계산하니 두 배 이상이 드는 것은 예측이 된다. 그런데 3배까지 나빠진 이유를 보니 이 나누어서 연산하는 과정에서 레지스터가 더 필요해서 예상치 않은 스필이 일어났다. 그 영향을 빼면 성능 하락은 두 배가 된다.

(4) 세 번째 그룹, Spill + 32비트 연산: 64비트 연산에 대한 패널티가 없는 상황에서 레지스터 스필만 일어나도록 했는데 대략 4초에서 12초까지 성능이 2.7배 정도 차이가 났다. 어차피 레지스터 스필이 일어나도 스택은 모두 캐시 적중이 되니 실제 메모리에 갈 일은 없다고 봐도 되니 L1 캐시 접근 영향이 더해 진다. 2배 정도라고 예상했는데 생각보다 컸다.

(5) 마지막 그룹, Spill + 64비트 연산: 32비트 컴퓨터에서 최악의 상황이다. 연산도 64비트를 해야하고 레지스터 스필도 난다. 약 3배 정도 성능 하락이 있다.

x86-64에서 64비트 모드는 스택 포인터를 제외하고 최대 15개까지 범용 레지스터를 쓸 수 있다. 그런데 시간 측정 변수를 희한하게 컴파일러가 계속 레지스터에 담아 두도록 레지스터 할당을 해서 14개까지 쓸 수 있었다. 최상의 경우에 어셈블리 코드를 보면 아래와 같다. 보다시피 레지스터 스필이 하나도 없이 루프 전체가 모두 레지스터에서 계산이 된다.

   1: for (uint32_t i = 0; i < numeric_limits<uint32_t>::max() / 2; ++i) {
   2:   t1 = t1 | tC;
   3: 0000013F6612D0  or          rdi,r10  
   4:   t2 = t2 & t1;
   5: 0000013F6612D3  and         rsi,rdi  
   6:   t3 = t3 - t2;
   7: 0000013F6612D6  sub         rbp,rsi  
   8:   t4 = t4 ^ t3;
   9: 0000013F6612D9  xor         r14,rbp  
  10:   t5 = t5 | t4;
  11: 0000013F6612DC  or          r15,r14  
  12:   t6 = t6 & t5; // <== Fits x86 registers w/o spill
  13: 0000013F6612DF  and         r12,r15  
  14:   t7 = t7 - t6;
  15: 0000013F6612E2  sub         r13,r12  
  16:   t8 = t8 ^ t7;
  17: 0000013F6612E5  xor         rax,r13  
  18:   t9 = t9 | t8;
  19: 0000013F6612E8  or          rcx,rax  
  20:   t0 = t0 & t9;
  21: 0000013F6612EB  and         rdx,rcx  
  22:   tA = tA - t0;
  23: 0000013F6612EE  sub         r8,rdx  
  24:   tB = tB ^ tA;
  25: 0000013F6612F1  xor         r9,r8  
  26:   tC = tC | tB;
  27: 0000013F6612F4  or          r10,r9  
  28: 0000013F6612F7  dec         r11  
  29: 0000013F6612FA  jne         main+60h (013F6612D0h)  

반면 최악의 경우인 32비트 모드에서 64비트 계산과 레지스터 스필까지 동시에 나면 코드는 매우 지저분해진다.

   1: 47:     t0 = t0 & t9;
   2: 00FD137C  mov         ecx,dword ptr [esp+44h]  
   3: 00FD1380  and         ecx,eax  
   4: 00FD1382  mov         dword ptr [esp+4Ch],eax  
   5: 00FD1386  mov         eax,dword ptr [esp+48h]  
   6: 00FD138A  and         eax,dword ptr [esp+24h]  
   7: 48:     tA = tA - t0;
   8: 00FD138E  sub         dword ptr [esp+20h],ecx  
   9: 00FD1392  mov         dword ptr [esp+44h],ecx  
  10: 00FD1396  mov         ecx,dword ptr [esp+40h]  
  11: 00FD139A  sbb         ecx,eax  
  12: 00FD139C  mov         dword ptr [esp+48h],eax  
  13: 49:     tB = tB ^ tA;
  14: 00FD13A0  mov         eax,dword ptr [esp+3Ch]  
  15: 00FD13A4  xor         eax,dword ptr [esp+20h]  
  16: 00FD13A8  xor         dword ptr [esp+1Ch],ecx  
  17: 50:     tC = tC | tB;
  18: 00FD13AC  or          esi,eax  
  19: 00FD13AE  or          edi,dword ptr [esp+1Ch]  
  20: 00FD13B2  dec         dword ptr [esp+68h]  
  21: 00FD13B6  mov         dword ptr [esp+40h],ecx  
  22: 00FD13BA  mov         ecx,dword ptr [esp+70h]  
  23: 00FD13BE  mov         dword ptr [esp+3Ch],eax  
  24: 00FD13C2  mov         eax,dword ptr [esp+6Ch]  
  25: 00FD13C6  jne         main+0B0h (0FD1300h)  

이 벤치마크는 극단적인 상황을 가정해서 같은 코드에서도 성능 차이가 전혀 없게도, 혹은 3배까지도 나게 만들 수 있었다. 하락하는 경우는 앞서 설명했듯이 포인터 기반 자료구조를 빡세게 돌리는 코드면 볼 수 있다.

결국 64비트 프로그램에서 이러한 현상이 얼마나 자주 일어나느냐가 프로그램 성능 향상의 관건이 될 것이다. 일반적으로 64비트 CPU의 정수 연산에 대해서만 정리하면 다음과 같이 말할 수 있다.

  • 메모리/캐시에 큰 압박을 주지 않는다면 64비트 연산을 최대한 활용하는 것이 좋다.
  • 포인터 기반 자료구조에서 실제 데이터보다 포인터 오버헤드가 커지면 성능이 하락할 수도 있다.
  • 범용 레지스터가 늘어나면, 소위 레지스터 압력(register pressure)가 높은 루프에서 효과를 볼 수 있다. 쉽게 말해 긴 루프의 수행 성능이 좋아질 수 있다. (변수가 어떤 구간 동안 계속 살아 있어 사용이 되면 최대한 레지스터에 놓는 것이 좋다. 컴파일러의 레지스터 할당 알고리즘은 이걸 최대한으로 보장하려고 하는데, 여기서 레지스터 개수가 늘어나니 성능 향상에 이득이 된다.)

 

3줄 요약:

  • 벤치마크 점수로 본 A7의 성능은 놀랍다. 도대체 무슨 짓을 한 것인가.
  • 모바일에서도 64비트는 필요하다.
  • 32비트에서 64비트로의 성능 변화는 그때 그때 마다 다르다.

핑백

덧글

  • RuBisCO 2013/10/04 11:47 # 답글

    CPU 코어 사이즈가 거의 기존 ARM 코어들 곱절이던데 작심하고 급격하게 대형화하여 확장한게 분명한데 아무리 듀얼코어라곤 해도 전력소비가 유지된게 경이로운거 같습니다.

    P.S 으아니 말은 많이한 황회장님은 으째 제품이 아직이다요오!
  • Ya펭귄 2013/10/04 11:52 #

    곱절까지는 아니고 대략 스위프트 대비 40% 정도 확장이었던 것 같습니다...
  • 김민장 2013/10/05 02:02 #

    Krait 다음 코드명이 내년에 나오고 삼성도 새로운 엑시노스를 내놓으면 좀 정리가 될 듯.
  • Ya펭귄 2013/10/04 11:48 # 답글

    좋은 글 잘 읽었습니다...

    사실 이번 애플의 A7의 조기 출시는 일반적인 (2014년-20nm에서 제품출시라는)ARM사의 로드맵을 기준으로 움직이는 업체들의 입장에서는 좀 한 방 크게 먹은 셈이기는 하지요.....^^; (대략 1년 정도 뒤쳐진 셈이니...)

  • 김민장 2013/10/05 02:01 #

    64비트도 된통 한방 맞았겠죠. 빨라야 2014년 말이나 2015년인데 1년 빨리 나와서 아마 지금 난리나는 곳이 있을 겁니다.
  • Ya펭귄 2013/10/05 02:03 #

    뭐 그런 이슈가 있을 때 제일 궁금한 두 군데가 S모사와 Q모사이기는 합니다만......... ^^;
  • 김민장 2013/10/05 02:18 #

    저도 얼마나 알고 싶겠습니까. 알 수가 없어요. 인텔은 허접 인턴들에게도 자세한 마이크로아키텍처 알려주는데 여기는 알기가 어려워요. 딱 지난 번에 전체 온라인 강의로 Krait 다음 세대 구조와 64비트 구조 이야기를 하더군요. 그런데 이것도 마케팅적인 성격이 강하고 기술적인 내용은 그냥 간단한 수준으로만. SOC로 가면 다른 IP와 엮는 인터커넥션이 굉장히 중요한데 이것도 차세대가 있긴 한데 역시 정보를 구하기 어렵습니다. 팀장님이 비공식 채널로 알아와서 보여주고 뭐 그런 수준. 이 회사가 이 정도니 애플은 오죽하겠나 싶습니다.
  • regen 2013/10/04 12:48 # 답글

    진짜 ARMv8 이 이렇게 빨리 도입될 거라고는 상상도 못했음..;;
  • 김민장 2013/10/05 02:02 #

    처음 64비트 루머가 돌았을 때 설마했는데 정말로..
  • 원기 2013/10/05 00:31 # 삭제 답글

    파워쪽 한번 정리해주세요.
  • 김민장 2013/10/05 02:02 #

    저도 파워를 건들이고 싶지만 아는게 별로 없어서;;
  • 미칸아빠 2013/10/05 02:16 # 답글

    와~ 감명깊게 읽었습니다.

    브라우저의 특징은 다음과 같습니다. (대부분 범용 어플리케이션의 특징일수도 있겠네요)
    1. 64bit연산 거의 없음
    2. ~100byte정도 되는 c++ instance가 무수하게 graph형태로 연결되어 있음

    브라우저가 64bit로 가면서 성능이 좋아지느냐는
    64bit포인터때문에 생긴 메모리/캐시의 압박을, 두배가 된 범용레지스터가 얼마나 상쇄하느냐에 달린것 같네요.

    다행히 firefox의 경우 6%정도 좋아진듯 하네요. http://boomswaggerboom.wordpress.com/2009/10/01/64-bit-firefox-performance-on-mac-os-x/

    다음은 인텔 Bay trail과 에플 A7 비교 부탁드려요. 굽신굽신
  • 김민장 2013/10/06 15:50 #

    그렇겠죠. 웹 브라우저는 주로 파싱이니 작은 객체가 많이 있고 64비트 연산이 있을리가 거의 없을 겁니다. 인텔 BT는.. 제가 아는 바가 전혀 없어서 ... 나중에 혹시나 시간이 되면 ㅎㅎ
  • 몽몽이 2013/10/05 10:30 # 답글

    저는 그래도 64bit 도입 별로라고 봅니다. 성능이 향상된 부분도 64bit여서 향상된 것인지는 본문을 봐도 잘 모르겠네요.
    물론 레지스터 수가 늘어나니 그 덕분은 있겠지만 모바일 기기에 램이 몇배로 늘어나지 않을 이상 이건 아닌 듯 합니다.
    왜 64bit로 올린 것인지 그 진의가 더욱 궁금해질 따름입니다. (애플이 램을 만들어 팔 생각인가?)
  • 과객 2013/10/08 01:38 # 삭제

    64비트라서 ARMv8이 빠른 게 아니라, 더 진보된 구조에 성능이 우월한 최신 아키텍처인 ARMv8을 도입하는데, 그게 마침 64비트 CPU인 것이겠죠. 더 이상 32비트로 ARMv8과 같은 성능을 낼 수 있는 CPU를 개발할 곳도 없으니, 제대로 성능을 끌어올릴 방법으로 ARMv8을 도입한 CPU를 탑재하는 것이 가장 효과적이지 않겠나요?

    64비트라고 생색내며 광고할 수 있는 것도 나름 쏠쏠하고요.
  • 김민장 2013/10/08 02:00 #

    64비트는 어차피 해야 하는 겁니다. 인텔은 하는데 왜 ARM은 안/못하냐 얘기도 잠재울 수 있고요.
  • 미칸아빠 2013/10/08 19:43 #

    64bit가 일반적인 어플리케이션의 성능이 많이 좋아지게 하지 않는다는것은 동의합니다. 하지만 64bit가 시기상조라는것은 동의 못하겠습니다. 제가 보기에 적당한 시점에 에플이 치고나가 주었다고 보입니다.

    이유
    1. 벌써 모바일에서 물리메모리를 2G씁니다.
    2. 넓어진 bus의 bandwidth가 비디오, 카메라, GPU 성능에 영향을 줄겁니다. 경쟁사와 차별화에 굉장히 중요하죠.
    3. 데스크탑 개발환경이 64bit에 최적화되있습니다. 32bit로 컴파일하고 테스트하는것은 개발속도에 영향을 줍니다. 코드도 지저분해지구요.
  • 몽몽이 2013/10/08 21:45 #

    미칸아빠// 버스 대역폭이 늘어난게 영향을 줘야 할 것인데... 실제로는 그 대역보다 네트웍이 문제지 않습니까?
    동영상을 넣고 다닌다고 해도 무슨 4K 화질로 영화 볼 일도 아니고...
    시뮬레이터가 64bit로 돌아가면 개발이 빠를 것이란 점은 인정이 됩니다만 어차피 이미지 올리고 디버깅하는 단계가 병목인 걸로 아는데 어떤지 모르겠군요.
  • 2013/11/30 03:50 # 삭제

    애플이 댁보단 나을테니 그냥 그런가보다 하세여
  • 64bit 관심자 2013/10/16 09:28 # 삭제 답글

    개발자의 능력에 따라 성능이 상당히 달라질 듯. 64bit 특성을 잘 이해하는 사람과 그걸 알고 투입하는 시간. Software 개발자들의 중요성이 점점 더 커져서 좋습니다.
  • Alquimista 2013/10/16 22:32 # 삭제 답글

    AES는 전용 하드웨어 가속 지원이 추가되어서 특별히 튀는거고요,
    64비트 명령어에서 inline-barrel shifter와 conditional execution이 칼질 당해서 정수 제곱근 같은 수학 관련 함수들이 상당히 느려졌습니다.

    이 때문에 나눗셈도 같이 느려질 형편이었는데 (A15부터) 나눗셈 명령어가 추가되어서 그나마 다행입니다.

    인테저 코어 레지스터 용량이 4배가 되고 (16개->32개 & 32비트->64비트) 메모리 관련 명령어들이 상향되었기에 전체적인 성능향상은 상당하지만 명령어 하나 하나의 효율은 32비트보다 열등합니다. (솔직히 실망스럽습니다)

    반면 VFP와 NEON은 칼질 당하지 않고 유용한 명령어들이 대폭 추가되고 레지스터 용량도 두 배가 된 만큼 멀티미디어 관련 루틴은 대단한 성능향상을 보입니다.
  • sanxiyn 2014/03/31 22:43 # 답글

    AnandTech 후속 기사가 나왔는데요 http://www.anandtech.com/show/7910/apples-cyclone-microarchitecture-detailed

    Q: 도대체 무슨 짓을 한 것인가
    A: 공개된 마이크로아키텍처 정보를 보니 issue width, ALU, LSU 모든 게 다 두 배네요...
댓글 입력 영역