iPhone 5S: 64-bit A7 칩 탑재는 홍보용일 뿐... 실제 퍼포먼스 향상은 없어 [ExtremeTech]



원제: iPhone 5S: The 64-bit A7 chip is marketing fluff and won’t improve performance [ExtremeTech]


원래 기사를 번역하고 있었는데... 망할 놈의 backspace를 잘못 눌러 글이 다 날아가 버렸네요 (...) 그래서 그냥 기사 요약. 궁금하신 분들은 [원문]으로 GoGo.

말인 즉슨 이렇습니다. 64-bit CPU 사용의 가장 큰 이유는 4GB 이상되는 RAM의 구동이 가능하다는 것인데 이건 서버에나 해당하는 문제지, 한 푼의 전력이라도 아쉬운 모바일의 입장에서는 필요도 없는 RAM 크게 달아 전력소비를 늘릴 이유가 없다. 실제 Apple도 4GB 이상의 용량을 가진 RAM을 가진 폰을 출시할 계획은 없는 것 같다, 아니, 사실 그건 고려할 가치도 없는 일이라는 것입니다.

64-bit으로의 이행이 주는 또 하나의 이점은 그 간 32-bit 시스템에서 발견했던 문제들을 한방에(!) 처리해 버릴 수 있다는 점, 말하자면 새 집으로 이사감으로써 헌 집이 가지고 있었던 고질적인 문제들로부터 일거에 벗어날 수 있다는 점입니다. 그런데 이 역시 이번 iPhone 5S에는 해당되지 않는게, 아무래도 당분간 App 시장은 32-bit App들이 주류를 이룰테고, 결국 호환모드를 통해 32-bit App들을 돌릴테지만 호환모드의 근본적인 한계상 최대 성능을 발휘하지 못하는 어정쩡한 상태가 한동안 지속될 거라 말합니다. 결국 iPhone 5를 쓰던 사람이 iPhone 5S로 옮겨 탔을 때 64-bit CPU란 이유로 체감할 성능의 차가 그렇게 크지 못할 거란 말이지요.

마지막으로 64-bit 시스템의 경우 구동되는 프로그램의 크기가 32-bit에 비해 아무래도 클 수 밖에 없고, 데스크탑에서는 그 정도가 성능에 크게 영향을 주지 않으나 용량에 민감한 모바일의 경우 퍼포먼스 저하의 원인이 될 수 있음을 지적합니다. 결국 Apple이 64-bit 모바일 폰의 첫 주자로써 얻을 수 있는 이익은 거의 제로에 가깝다는게 글쓴이의 총평입니다. 아마 Apple 기술진도 이 사실을 잘 알고 있을 거고, 결국 64-bit를 전면에 내세운 건 마케팅을 위한 얄팍한 술수에 지나지 않는다고 말하고 있습니다. 마지막 문단의 제목을 그대로 적어보자면,

Don't be fooled (현혹되지 마세요)

덧글

  • PFN 2013/09/12 20:56 # 답글

    저도 애슬론 64 보급되고 크라이시스도 64비트 버전 나오고 그럴때

    아 이제 64비트 세상이 열리는구나 했는데

    아직도 주류는 32비트;;

    이젠 64비트 지원 안하는 시퓨 찾기가 더 힘들 지경인데도 그렇더군요
  • hyunyi 2013/09/12 23:31 #

    네 맞습니다. 원문에 보면 글쓴이도 데스크탑 시장의 예를 들어가면서 데스크탑도 이러한 마당에 모바일에 64-bit를 도입하는 것은 정말 시기상조라고 주장하고 있습니다.
  • 로오나 2013/09/12 21:37 # 답글

    이 시점에서는 다른 경쟁자들보다 먼저 64비트로 나아갔다... 이상의 의미는 없겠지요, 아무래도. 4GB 램을 달아주는 것도 아니고. 애플은 램에는 쫀쫀하기 그지없으니까요.

    하지만 미래를 생각하면 한발 앞서서 준비하는게 의미가 없진 않을 겁니다.

  • hyunyi 2013/09/12 23:35 #

    맞는 말씀입니다. 사실 이번 64-bit 채택은 end-user들 보다는 도리어 개발자들에게 의미있는 전환이라고 봐야할 것 같습니다. 저도 이번 이벤트를 보지 않아 잘은 모르겠지만 글쓴이는 아마도 Apple이 64-bit로의 전환이 사용자들한테 대단한 이점을 제공할 것 마냥 선전했다고 느낀 모양입니다. 전체적인 글의 방향도 '너무 이른 전환'이라는데 초점이 맞춰져 있지, 방향 자체를 부정적으로 본 것은 아닌 것 같습니다.
  • 달려옹 2013/09/12 22:27 # 답글

    애플은 맥킨토시의 경우도 64bit로 전환을 빨리 했으니까요...아마 ios앱들도 빨리 전환시켜서 컴퓨터랑 연동시키고 싶은거 같습니다...
  • hyunyi 2013/09/12 23:38 #

    그럴지도 모르겠네요. 여튼 방향은 틀림없는데, 다소 이른 감이 있는 건 사실인 듯 싶습니다.
  • DUPLICIK 2013/09/13 02:08 # 답글


    퍼포먼스 향상에 대한 기대가 없어졌으니 5s와 5 사이의 차이는 샴페인골드컬러, 카메라 조리개(f2.4에서 f2.0으로 향상... 근데 이게 폰카메라 수준에서 의미있을만한 수치인지는 의문.), 지문인식 기능
    세가지 뿐이네요. 저 세가지 차이만 감안하고 5s로 넘어갈만한 사람들은 솔직히 많지 않을거라고 봅니다.

    그렇다고 5c도 가격 메리트가 생각보다 약해보인다고 생각했는데 발표회에서 5를 단종예고 했었군요...애플이 정말 약아빠졌네요ㅋㅋㅋ
  • hyunyi 2013/09/13 03:03 #

    개인적으로는 듀얼 플래쉬는 좀 기대되긴 했습니다.ㅋ 왠지 이제 혁신 보다는 현상 유지에 급급한 Apple을 보는 것 같아 좀 서글픈 기분입니다. 정말 잡스의 부재가 큰 걸까요? 아니면 스마트폰 산업 자체가 성숙단계에 이르러 더 이상의 혁명은 기대하기 힘든 걸까요...? 이제 더 이상의 서프라이즈는 기대하기 힘든 것인가요...
  • 원기 2013/09/13 06:48 # 삭제 답글

    코드 자체가 64비트 용으로 개발되지 않았더라도, 컴파일러가 알아서 64비트로 만들어 줄 것 같습니다. long long, double 같은 타입들의 연산속도 향상이야 당연할 거고. 32비트 타입들이라도 SIMD 인스트럭션으로 컴파일러가 알아서 바꿔줄 수 있지 않을까요? 64비트 용으로 빌드 되지 않아도 모든 라이브러리가 64비트로 최적화되었다면 이로 인한 속도 향상도 있을거고요. 마케팅용이라고 평가절하하는 건 애플의 개발자들을 너무 무시하는 것 같습니다.
  • hyunyi 2013/09/13 13:02 #

    댓글 감사드립니다. 그런데 32-bit <-> 64-bit 간의 호환문제가 컴파일러 만으로 정말 해결될 수 있는지요? 그렇담 왜 굳이 64-bit CPU에 32-bit 호환모드가 필요한지, 그리고 데스크탑의 경우에는 벌써 64-bit가 출시된지 10년이 다 되가는 상황에서 32-bit를 버리지 못하고 있는지 이해가 가지 않습니다...
  • asdf 2014/06/03 19:48 # 삭제

    아직 데스크탑환경에서도 64비트 지원하는 어플리케이션들이 적은데 모바일이라고 다를까요...
  • 오오 2013/09/13 07:43 # 답글

    정상적인 상황이라면 컴파일러가 빌드시 64비트 실행파일을 만듭니다. 그래서 데모용이었던 인피니트 블레이드3도 2시간 작업해서 완료했다고 나왔구요.
    OS나 앱의 64비트 전환은 별 문제가 없을 것입니다. 그래서 애플 생태계 입장에서 볼때 시기상조라는 것은 다소 맞지 않을 수 있다고 보입니다.
    이미 OSX은 64비트로 돌아가고 있고...
    속도면의 이점이 있는 분야는 분명 있을 것이고, 애플의 퍼포먼스 그래프는 그다지 뻥을 치는 것 같진 않더라구요.

    최대의 단점은 메모리 부하가 커진다는 것인데(애플의 64비트 전환 가이드라인에 나옴) 향후 메모리 양이 늘어날 핑계거리가 생긴 것이죠.
    (이게 약간 5S가 불안한 요소임. iFixit등에서 내부를 까본거 본 뒤에 5S로 갈지 생각해야 될 듯)
    나와보면 알겠죠.
  • hyunyi 2013/09/13 13:08 #

    댓글 감사드립니다. 말씀하신대로 다소 논란의 여지가 있는 글임에는 틀림없습니다. 윗분도 32-bit <-> 64-bit 간의 호환문제가 컴파일러만으로 해결 가능하다고 하셨는데, 그렇다면 굳이 ARMv8에 32-bit 호환모드가 들어간 이유를 모르겠습니다. 글쓴이는 32-bit 프로그램들 경우에는 다 32-bit 호환모드로 돌려야 할 것 처럼 이야기 하더군요. App의 대세가 32-bit에서 64-bit로 전환되는데 대락 6~12개월은 걸릴거라고 말하고 있습니다. 만약 정말 컴파일러로 해결될 문제라면 거의 당장 64-bit 버젼을 내놓을 수도 있을텐데 말이죠...
  • 오오 2013/09/13 13:55 #

    그건 발빠른 개발자라면 64비트용 실행파일로 컴파일(및 필요한 수정을)해서 업데이트 하겠으나, 개발사가 여력이 없거나, 뭐 이런저런 이유로 그렇지 못한 경우는 32비트 버전에서 더 이상 업데이트를 안할(또는 포기할) 수도 있기 때문이죠. 새로 컴파일 안했다고 기존에 있는 그 많은 프로그램을 다 버리고 갈 수는 없으니까요. 원문 필자에게는 의외일수도 있지만, 기술적으로 코드상에서 고쳐야 될 부분은 아주 적을 수도 있습니다. 그렇긴 해도 모두가 다 그럴 능력이 되진 않겠죠. 또 경우에 따라서는 별 생각없이 코딩해서 다 고쳐야 될 수도 있구요.

    몇년 뒤에 아이폰5C와 현행 아이패드가 다 단종되고 A7이후의 64비트용 CPU들만 있는 세상이되면 아예 64비트용 바이너리만 넣어서 빌드하는 때가 올 수도 있겠지만...어찌되었든 그때까지는 공존하게 될테니...

    이미 맥용 앱은 기본 셋팅이 64비트용만 빌드하게 되어있어요.
  • 오오 2013/09/13 13:58 #

    그리고 어쩐지 얼마전부터 32비트/64비트 관련되어 애매하게 해도 넘어갔던 부분이 훨씬 더 치밀하게 컴파일 단계에서 워닝을 뿜어내더니...
    이미 이걸 염두에 둔 것이었겠죠.

    개발자가 그 워닝들이 보기 싫어서 잘 고쳐놓았던 경우에는 아마 그냥 컴파일 하면 64비트로 넘어갈 것입니다.
  • 마크 2013/09/13 09:22 # 삭제 답글

    고작 얄팍한 술수에 활용하려고 64bit를 도입해요? -_-;;;
    Apple이 64-bit 모바일 폰의 첫 주자로써 얻을 수 있는 이익이
    거의 제로에 가깝다구요? -ㅁ-;;;;

    5s 기기 자체에서 64bit로서의 고성능은 적을거라고 말한다면 수긍하겟지만
    원문 작성한 Joel Hruska 라는 사람, 너무 저평가해서 글을 썼네요.
    동의 못하겠습니다.
  • hyunyi 2013/09/13 13:26 #

    의견 감사드립니다. 저도 다소 논란의 여지가 있는 글임에는 동의합니다. 솔직히 제목을 쓴 방식 부터가 '함 싸워보자!'라는 식이였죠...

    그래도 저는 글의 전체적인 방향에는 동감하는 편입니다. 굳이 Apple이 지금 시점에서 64-bit를 도입할 필요가 있었을까? 하는 생각이 듭니다. 개인적으로는 무엇보다도 베터리가 문제로 보이는데, 현재 용량의 베터리로 64-bit를 완벽하게 지원한다는게 과연 가능한가 싶은거죠.

    또한 글쓴이는 App의 대세가 32-bit에서 64-bit로 바뀌기 까지 6~12개월의 시간이 걸릴 것으로 보고 있습니다. Apple의 신제품 발표주기를 대략 1년이라고 보았을 때 이번 iPhone S5 구입자는 자신의 기기 성능을 최대한으로 써보지도 못한 채 다음 버젼의 발표 소식을 들을 수도 있는 상황입니다.

    특히 일반 사용자들은 64-bit, 32-bit 호환문제에 대해 알 수 없습니다. Apple이 우리 폰은 64-bit인데 현재 App들이 32-bit라 당분간은 호환모드로 돌리시게 된다... 라고 자세하게 설명해 주는 것도 아니죠. 사실 이번 버젼은 64-bit라는 것 외에는 거의 소소한 변화 뿐입니다. 그래서 이런 생각이 드는 겁니다. 매번 혁신을 보여줘야 한다는 부담과 64-bit를 미리 테스트해 보려는 욕심이 결합되서 나온 '적당한' 산물이 바로 iPhone S5가 아닌가 하는...
  • Ya펭귄 2013/09/13 10:32 # 답글

    마지막으로 64-bit 시스템의 경우 구동되는 프로그램의 크기가 32-bit에 비해 아무래도 클 수 밖에 없고

    ==> 이 부분은 좀 단언하기 힘든 게 x86_32 ==> x86_64에서는 일률적으로 8bit의 프리픽스가 붙었습니다만(그래서 단순계산으로는 코드 크기가 40%정도 증가할 요인이 있었습니다만...) A32==>A64에서는 그냥 32bit의 명령어 크기를 그대로 유지하고 있지요...

  • hyunyi 2013/09/13 13:29 #

    지적 감사합니다. 저도 이 부분에 전문가는 아닌지라 한 수 배울 수 있으면 좋겠습니다. 그런데 A32=>A64라는 것은 32-bit 프로그램을 64-bit CPU의 32-bit 호환모드에서 돌리는 것을 말씀하시는 건가요?
  • Ya펭귄 2013/09/13 14:31 #

    32비트시절의 x86 명령어 크기 : 가변길이 명령어인데 대략 평균잡아 17~18비트
    64비트로 넘어와서의 x86 명령어 크기 : 64비트용 명령어들의 길이가 8비트 추가되어 대략 25~26바이트.

    기존 32비트용 A32(ARMv7) 명령어의 크기 :32비트.
    신형 64비트용 A64(ARMv8) 명령어의 크기 : 그대로 32비트.

    그런 뜻입니다.
  • 은이 2013/09/13 11:18 # 답글

    64비트의 가장 큰 이유가 4GB 램이라니요.. 윈도우 PC도 아니고 모바일의 4GB램은 아직 별다른 의미를 가지지 못합니다.
    말 그대로 64비트 아키텍쳐를 쓸수 있다는 그 자체가 커다란 의미가 됩니다.
    윗 분들께서 여러가지 적어주신만큼의 상세한 지식은 부족하지만,
    64비트로 구현/또는 최적화 가능한 기술을 쓸 수 있는 여건을 만들었다는 그 자체만으로 의미가 있습니다.
    유저에겐 그냥 x2 로 보이지만, 제대로 활용가능한 개발자에겐 세상이 두배로 넓어졌다고 해도 될 대사건이죠.

    물론, 반대로 말하면 이제 시작이니만큼 64비트의 체감은 사실상 느끼기 힘들고
    일반 사용자가 쓰는 폰에 64비트를 활용할 수 있는 기능/앱이 얼마나 될지, 모바일 iOS에서 64비트가 얼마나 위력을 발휘할 지는
    지켜봐야 된다느 관점으로 봐야될 거 같습니다.
  • hyunyi 2013/09/13 13:36 #

    맞는 말씀이십니다. 저도 개발자들에게는 매우 흥미로운 전환이라 생각합니다.

    글쓴이는 주로 일반 사용자 입장에서 글을 쓰고 있는 것 같더군요. 원문에 보면 32-bit가 대세인 지금의 App 시장이 64-bit 중심으로 전환되려면 대략 6~12개월이 걸릴 것이라 말하고 있습니다. 그렇다면 Apple의 신제품 출시 주기가 대략 1년이라고 봤을 때, iPhone 5S의 구입자들은 자신의 폰을 최대로 활용해보지도 못한 채 후속 버젼의 발표를 볼지도 모르는 일입니다.

    따라서 어떤 일반 사용자가 64-bit라는 이유만으로 iPhone 5S으로 갈아탄다면 그야말로 fooled 된 상황이라 할 수 있지 않을까요. 적어도 Apple이, 혹은 iPhone 5S의 판매자들이 우리 폰은 64-bit인데 현재 App들이 32-bit라 당분간은 호환모드로 돌리시게 된다... 라고 자세하게 설명해 주는 일은 없을 듯이 보입니다...
  • kokey 2013/09/13 12:42 # 답글

    저도 완전히 동의하긴 힘들겠네요;
    사실상 현재 구동되는 앱들은 99% 이상이 32bit 이겠지만 아이폰5S가 64bit로 출시된다고 했던 시점부터 개발자들은 준비를 하고 있겠죠.
    64bit로 구동되는 앱들을 말이죠~
    그러면 기본적으로 아무리 메모리가 적어도 한번에 처리되는 데이터량이 확 증가할 겁니다.
    그런 부분에서 나타는 퍼포먼스 향상은 무시 못하겠죠, 물론 램의 부족으로 64bit cpu를 100% 활용 못한다고 하더라도
    이미 포화상태에 다다른 모바일 환경에서 64bit라는 새로운 환경을 제공하는 것은 충분히 잘하는 일이라고 생각됩니다.

    개발자들이 고생하는거야 뭐 하루이틀 문제도 아니었고, 64bit를 제공하면서 할 수 있는 것이 훨씬 많다고 생각되네요.

    윗분들 중에 시기상조라고 하는 분들이 계시는데.. 이미 64bit 아키텍쳐 cpu가 개발되고 내년이면 나오냐 안나오냐라는 말이 나오는 상황에서
    어떤 점이 시기상조인지 모르겠네요;; 앱 생태계로 보자면 64bit cpu가 나오는 시점에서 64bit 에서 제대로 돌아가는 앱들이 많은 생태계가 좀더 우월한 위치에 위치 하지않을까요?
    그런 점에서 이번에 64bit 아키텍쳐를 도입한건 어떻게 보면 신의 한수인겁니다.
    지금 A7 칩이 100% 64bit 칩이 아니라 아키텍쳐만 끌어와서 쓴 칩이라 할지라도 말입니다.
    이미 애플 앱 개발자들은 64bit 앱을 개발하기 시작했을테니까요.

    지금은 엄청난 물량공세로 안드로이드가 우위점을 가져가고 있지만 애플은 지금 당장이 아닌 좀더 먼 미래를 본겁니다.
    모바일 64bit 환경이라는 한발 앞선 미래를요.

    개인적으로 64bit 모바일 환경이 되었을 때 IOS와 안드로이드의 대결이 기대되네요.
  • hyunyi 2013/09/13 18:25 #

    의견 감사드립니다. 저도 남겨주신 댓글들 보고 Apple이 나름 64-bit로의 빠른 전환을 위해 많은 노력을 하고 있음을 알 수 있었습니다. 원글에서도 글쓴이는 64-bit의 전환 자체가 나쁘다고 말하진 않습니다. 시기상조, 즉 지금 상황에서 64-bit CPU를 탑재해 실제 일반 사용자가 얻을 수 있는 이점이 매우 제한적이라는 점입니다.

    ARMv8 아키텍처는 이미 2년 전에 발표된 바 있습니다 (http://www.extremetech.com/computing/102131-arm-details-64-bit-plans-new-armv8-cpu-architecture). 그럼에도 불구하고 아직까지 ARMv8 아키텍처가 모바일에 널리 쓰이지 않는 이유는 아무래도 환경 탓이라고 해야겠죠. 메모리 확장을 포함하여 ARMv8의 성능을 십분 활용하기에 아직 모바일용 베터리들은 아직 조루(...) 수준이고, App 시장 사정 상 당분간은 64-bit CPU를 박아도 32-bit 호환모드로 줄창 돌릴 것이 분명한 상황에서 제조사들이 64-bit로 넘어갈 필요성을 크게 못느꼈던 것입니다. 더구나 당장 32-bit 시스템이라 구현 못하는 서비스들이 넘쳐나는 상황도 아니지 않습니까.

    물론, 기술의 입장에서, 개발자들의 입장에서 보면 64-bit로의 이행은 분명히 의미가 있습니다. 하지만 64-bit가 실제로 일반 사용자한테 정말 이득을 줄 수 있는지에 대해서는 여전히 의문입니다.
  • kokey 2013/09/14 16:10 #

    적어도 앱의 구동속도는 지금보다 빨라질 겁니다.
    앱의 구동속도에 영향을 미치는 것은 앱의 최적화 정도, 메모리의 최대 가용량, 시스템 환경입니다.
    앱의 최적화 정도는 개발자가 앱을 얼마나 잘 만드냐에 따라 판가름 납니다. 아이폰의 환경과는 별개니 여기서는 넘어가죠.
    메모리의 최대 가용량은 기존의 아이폰과 동일할 거 같으니 이것도 넘어가겠습니다.

    제가 말씀드리고 싶은 건 시스템 환경입니다.
    32bit에서 64bit로 넘어갈 경우 향상된 시스템 환경으로 인해 한번에 처리할 수 있는 데이터의 양 자체가 늘어나고, 결과적으로 앱의 구동속도가 향상될 겁니다.
    거기다 개발자가 64bit 환경에 맞게 앱을 수정하면 구동 속도는 지금과 비교할 수 없을 정도로 더 빨라지겠죠.
    아마 아이폰5S가 나오는 시점에 이미 64bit로 개발된 앱이 있을테니 그때 비교해보시면 알 수 있을거라 생각합니다. 그리고 앞으로는 더 좋아지겠죠.

    제가 이렇게 생각하는 가장 큰 이유는 애플의 최적화 수준이 매우 뛰어나기 때문입니다.
    이미 예전에 인텔에서 Windows 환경을 64bit로 올린 예가 있었지만 최적화에 실패해서 욕을 많이 먹었었죠. ^^; (이젠 많이 좋아졌습니다만...)
    하지만 애플의 경우 이번 키노트에서 1년 안에 거의 모든 iOS용 앱이 64bit 환경에 최적화될 것이라고 공언했고, 그동안 애플이 보여준 최적화 능력으로 보아 기대를 걸어도 좋을 것 같습니다.
  • 나인테일 2013/09/13 14:14 # 답글

    애플 계열 플랫폼은 64비트 전환이 빠르고 앱 호환성도 빠른 시간 내로 정리됩니다. 커널인 넥스트스텝이 아무래도 64비트 전환기를 예비하고 만들어진 비교적 최신 아키텍쳐인데다 데스크톱에서 파워PC -> 인텔 전환을 위해 똥줄이 빠지게 준비했던 몇 가지 장치가 있었는데 그걸 지금까지 플랫폼 이전이 있을 때마다 잘도 우려먹고 있어서요.

    아마 트위터, 페이스북, 에버노트, 드롭박스 등 소위 말하는 주요 앱들은 3개월 내로 64비트 이전이 완료되고 정말 장사 할 생각 없이 방치되고 있는 앱이 아닌 다음엔 거의 모든 앱들이 최대 1년 내로는 이전이 끝날겁니다.
  • hyunyi 2013/09/13 18:33 #

    네. 저도 댓글들을 보다보니 64-bit로의 빠른 이행을 위해 Apple이 많은 채비를 하고 있음을 느낄 수 있었습니다. 적어도 데스크탑 시장에서의 지지부진한 전환은 걱정하지 않아도 되겠네요.

    하지만 일반 사용자의 입장에서는 64-bit를 탑재한 iPhone 5S가 얼마나 유용할지는 아직도 의문입니다. 말씀대로 App들이 64-bit 환경에 적응하는데 걸리는 시간이 빠르면 3개월, 느리면 1년. Apple의 신제품 발표 주기가 대략 1년임을 감안하면 결국 iPhone 5S의 구매자들은 자신의 폰의 최대 성능을 활용해보지도 못한 채 후속 버젼이 발표되는 상황을 맞을 수도 있는 거 아닌가요. 그렇담, 저는 사용자들이 당장 iPhone 5S를 구매해야 할 이유를 모르겠습니다...
  • 원기 2013/09/13 16:32 # 삭제 답글

    답글에 댓글 다는 법을 몰라서 그냥 이렇게 남깁니다.
    일단 어셉블러가 아닌 C(iOS니 Objective C겠군요)와 같은 언어로 만들어진 경우라면 컴파일만으로 64비트 인스트럭션으로 코드가 생성이 됩니다. 어셈블러야 인스트럭션과 1:1 매칭되니 64비트 instruction으로 모두 바꾸지 않는 이상 64비트로 돌 수가 없겠지요. 같은 C 코드라도 아키텍쳐에 따라 만들어지는 코드의 속도는 달라질 수 있습니다. 예를 들어 32비트 암은 레지스터가 15개정도 인데, 64비트는 30개 정도입니다. 사용할 수 있는 레지스터 개수가 2배가 늘어나니, 변수들을 레지스터에 할당을 많이 할 수 있고 메모리 접근 회수를 줄이는 것 만으로도 속도 향상이 발생합니다.
    그리고 가장 큰 속도 향상이 기대되는 건 이전에도 언급했던 것 처런 long long, double(VFP 같은 extension이 있으니 속도 향상이 있을지 아리까리 하긴 하네요) 같은 64bit data 연산입니다. 32비트 머신에서는 레지스터도 2개 잡아먹고, 더하기 같은 연산도 몇 개의 인스트럭션이 필요했지만. 64비트에서는 레지스터도 하나 인스트럭션도 하나가 되니 이 경우 속도 향상은 4배 이상일 될 수도 있습니다.
    아마도 이런 큰 데이타를 다루는 어플들이 제대로 버프 받을겁니다.
    32비트로 빌드된 이미지라도 데이타 버스도 넓어졌으니 이로 인한 속도 향상도 있을 것으로 보입니다.(이도 무시 못할 버프입니다.)

    그리고 64비트 머신이라도 하위 호환성을 위해서 32비트 모드를 제공하는 것은 매우 당연합니다. 피시에서 64비트로 넘어가는 속도가 느린 이유는 잘 모르겠습니다. 나름 사정이 있는 거겠지요. 다만 인스트럭션 길이가 늘어날 경우에는 인스트럭션 캐시에서 miss가 날 확률도 높아지기 때문에, 경우에 따라 속도가 더 느려질 수도 있을 것 같습니다. 간혹 들리는 이야기로는 code size 줄이는 컴파일러 최적화 옵션 쓰는 경우가 속도가 젤 좋더라는 것도 있거든요.

    64비트로 가는 게 정말 쉬운 일이 아닌데, 너무 폄하되는 게 가슴 아파서 짧은 지식으로라도 이렇게 글 남깁니다.
  • 은이 2013/09/13 18:06 #

    오오.. 뭔가 오래전 전공 수업시간에 들은 레지스터와 비트가 떠오릅니다. 이렇게 정리해 주시니 알기 쉽네요 :)
  • hyunyi 2013/09/13 18:48 #

    세세한 설명 정말 감사드립니다. 많은 공부가 되고 있습니다. 다른 글들을 보니, 32-bit 기반으로 쓰여진 코드도 64-bit로 컴파일 가능하지만 64-bit 용으로 최적화되지 않으면 그 크기가 늘어나고 효율이 떨어질 수 밖에 없다는 지적도 있더군요 (https://medium.com/tech-talk/fb96c0d7fd4e).

    저도 64-bit로의 이행이 의미있는 것이며 특히 개발자 입장에서는 매우 흥미로운 것이라는 점에는 십분 동의합니다. 하지만 어느 모로도 64-bit CPU가 반쪽 활용이 될 수 밖에 없는 상황에서 Apple이 굳이 64-bit 탑재를 택했는지에 대해서는 여전히 의문입니다. 사실 당장 32-bit라 구현할 수 없는 서비스들이 넘쳐나는 것도 아니지 않습니까. 사실 그간 Apple 제품들은 낭비없이 딱딱 맞아들어가는, 무척 최적화가 잘 된 그런 느낌이었는데 이번엔 왠지 머리만 비정상적으로 커진, 마치 가분수를 보는 듯한 느낌을 지울 수 없습니다...
  • 오오 2013/09/14 08:58 # 답글

    http://www.theverge.com/2013/9/12/4722470/iphone-5s-64-bit-processor-is-a-bigger-deal-than-you-think
    아마도 원문에 대한 반박글인 듯. 당장을 염두에 두는 것이 아니라 근미래를 염두에 둔 것이라 할 수 있죠.
    물론 1세대인 iPhone 5S에서는 체감 효과가 조금 적을 수도 있지만, 그렇다고 이행을 안하고 미뤄두는 것도 웃기죠.
    그럼 언제 이행하는데요? 64비트로 가면 유리해 지는 부분이 적지 않은데...남이 먼저 하고 환경이 요구할 때까지 기다릴까요(이게 윈도 데스크탑의 상황같은데)?

    언젠가는 '시작'이라는 것이 존재해야 되니까요. 애플다운 선택으로 보입니다.

    코코아내에서 시간을 표현하는 타입인 NSTimeInterval 이라는 것이 있습니다. 사실 64비트 부동소수점 실수인데, 이걸 32비트에서 연산하면 아주 비효율적으로 되어 느립니다. 제가 오래전에 이런 작업이 필요했는데, 결국 요걸 32비트로 다운해서 처리했죠. 그리고 최종적으로는 또 64비트로 바꾸고. 이런 추가 작업 및 잃어버리는 정밀도 없이 그냥 네이티브하게 되면 좋죠. 특히 시간같은 것은 엄청나게 많은 곳에서 사용되는 데이터타입인데. 즉, 대부분의 앱의 효율성에 직접적인 영향을 줄 수 있죠.

    그리고 뭔가 많은 데이터를 메모리상에서 복사를 하거나(특히 그래픽 같은 쪽에서 아주 많이 벌어지는 일) 그럴때도 64비트씩 복사하게 되어 32비트보다 산술적으로 2배의 효율이 나오게 되죠.

    저는 이런 유리한 변화를 아직...어쩌고 하면서 멍때리는 것이야말로 애플답지 않다고 생각합니다.
    32비트에서 구현하지 못할 서비스가 없는 것이 아니라, 32비트에서는 환경이 안되어 구현을 못했거나, 현실적으로 생각하기 힘들었던 것'도' 가능해 질 수 있는 것이죠. 그렇다면 충분히 시작할 가치가 있는 변화라고 생각합니다.
  • snhsj 2013/09/16 10:28 # 삭제 답글

    기초로 다시 돌아가봅시다.
    8bit, 16bit, 32bit 컴퓨터가 무엇이었습니까?
    CPU 가 한번에 처리하는 데이터의 크기였습니다.
    java에서 int 는 4바이트=32bit 입니다. 한번에 처리하죠. long 은 8바이트, CPU 가 두번에 나눠서 처리합니다. 32bit CPU라면. 64bit은? 한번에 하겠죠?

    근데 처리할 숫자가 42억이 안넘으면 long 을 쓸 필요가 없습니다. int 로 쓰는게 더 효율적이죠. (32bit에서)
    상당수의 경우 int 로 충분하여 그렇게 프로그래밍 되어 있습니다. 그렇다면 64bit 에서도 한번 32bit에서도 한번에 처리하므로 별 차이가 없습니다.

    처리할 데이터가 많고, 큰 숫자의 연산을 많이 한다면 당연히 64bit 이 훨씬 빠릅니다.
    괜히 서버들이 다 64bit 로 간 것이 아닙니다.

    이번 발표에서 인피니티 블레이드 보여주면서 뭐라고 자랑했습니까? 새로운 장면으로 넘어갈 때 로딩이 몇배 빨라졌다고.. 왜 그랬을까요?
  • snhsj 2013/09/16 10:33 # 삭제 답글

    32bit 호환모드가 필요한 이유는, 32bit 용으로 컴파일된 기존의 앱들이 실행되어야 하기 때문입니다.

    애플에서 전환이 쉽다고 하는건
    32bit로 개발해 놓은 소스코드를 새로운 툴에서 64bit로 컴파일만 하면 어렵지 않게 64bit 용 프로그램으로 컴파일 되고
    64bit로 실행되어 성능이 향상된다는 말이죠.

    기존 프로그램이 자동으로 64비트로 실행될 순 없습니다.
    같은 소스코드를 컴파일 했어도 기계어로 된 프로그램은 완전히 다른 녀석이 되는거죠.
  • snhsj 2013/09/16 10:35 # 삭제 답글

    아, 정수형은 개인적으로 습관적으로
    long 보다 int 를 많이 쓰지만,

    소수점이 있는 경우(부동소수점이라고 하죠)는 자연스럽게 double 을 씁니다.
    double 은 64bit 입니다.
    64bit CPU 가 필요한 경우죠.

    *** 물론 이건 "기초"적 개념이고.... 현대의 CPU 들은 32bit 모드에서도 대부분 한번에 데이터 여러개를 동시 처리합니다....
    SIMD 라고... 더 궁금하시면 구글해보세요..^^
댓글 입력 영역