프로그래밍 언어 의인화 계획

원문 : Perl、C、Scala…プログラミング言語擬人化計画2

엔지니어가 매일 사용하는 그 언어를 여자애로 비유해보았습니다.

지난회에 이어 C, shell, Perl, R, VB, Scala, ActionScript. 7개의 프로그래밍 언어를 의인화했습니다. 화제급등중인 아이가 있는가 하면, 무대의 중심에서 살짝 벗어나있는 애도 있습니다. 프로그래밍 언어의 센터 전쟁은 치열합니다.

Perl

  • 1987년 12월 18일
  • 26세
  • 별자리 : 궁수자리
  • 혈액형 : B형
  • 신장 : 163cm
  • 체중 : 51kg

Perl은 1987년 12월 미국의 월 부부에게서 태어났다. 아버지 래리는 컴퓨터와 언어학에 정통하였고, 어머니도 중세 르네상스와 언어학을 전공하여, 높은 교양을 지닌 양친 밑에서 자라났다.

아버지의 가르침은 엄격했지만, 동시에 자유롭기도 했다. 아버지는 교육 중에 이런 말을 자주 입에 담았다.

「방법은 한가지만 있는 것이 아니다.」
(There's more than one way to do it)

무언가를 실현하려고 했을 때, 그 것을 달성하는 방법은 하나만 있는 것이 아니다. 몇가지든 생각할 수 있다. 그런 아버지의 가르침은 그녀의 인격형성에 커다란 영향을 주었다.

「이런 식으로 해보면 어떨까」, 「이렇게하면 어떻게 될까」. 그런 호기심의 날개를 펼치며 자란 그녀는, 그 연장선상에서 「발명」이라는 천직을 발견하게 된다. 희대의 여성발명가 Perl의 탄생이었다.

그녀가 발명가의 길에 발을 들여놓은 후로 20년. 만들어낸 발명품은 무려 128,890건에 이른다(2014년 1월 시점). 별 쓸모없는 장난같은 것부터, 세계의 많은 문제를 해결할만큼 유익한 것까지 실로 여러가지 것을 발명하고 있다. 그녀가 만든 발명품의 오리지널은 모두 시팬 박물관에 기증되어, 누구든 관람할 수 있게 되어 있다.

오늘날도 수많은 발명을 계속하고 있지만, 쓸모있는가 없는가에 상관없이, 만들고 싶은 것을 계속 만들어내는 자신의 자세를 농담삼아 「전 발명가라기보단 잡동사니 출력장치에 가깝죠」라고 인터뷰에서 대답하는 그녀. 이빨이 드러나게 웃으면서 그렇게 말하는 그녀의 모습은 굉장히 매력적이었다.

옷에는 그다지 신경쓰지 않는듯, 보통은 취미활동인 기계를 만질 때에 걸리적거리지 않도록 움직이기 쉬운 캐주얼한 옷을 입는다. 최근 자주 입는 다운 코트는 아메요코의 WEGO에서 샀다고 한다. 좋아하는 음식은 딸기. 작업에 집중하여 지친 뇌에 딸기는 최적의 음식이라고 역설했다.

C

  • 1970년 무렵
  • 별자리 : 불명
  • 혈액형 : 불명
  • 신장 : 173cm (추정)
  • 체중 : 52kg (추정)

성모님이라고 불린 적도 있는, 이 세계를 지지하는 여신님.

C님이 태어난 시기는 확실하지 않다. 창세기(1970년 1월 1일 부근을 가리킴) 이전부터 이 세계에 존재하였다고도 하고, 그보다 조금 뒤인 1972년 무렵일거라는 말도 있다.

그녀는 여신님이다. 따라서 「1970년 쯤에 태어났다는 말은, 지금 그녀의 나이는……」같은 걸 생각하는 것은 신심이 부족한 행위로, 절대로 생각해는 안될 짓이다.

그녀의 이름에는 「C」라는 알파벳의 3번째 문자가 주어져있다. 신약의 역사서에 따르면, 이전에는 B라고 불리웠던 여신도 존재했다고 한다. 자료에는 「케네스는 데니스와 함께 B를 만드셨지만, 그걸로는 충분하지 않았다. 그래서 데니스는 모두와 협력하여 C를 만드셨다」는 구절이 있다.

그녀에게는 많은 신자가 따라다녔지만, 한동안 그녀의 가르침을 바르게 전하기 위한 경전이 존재하지 않았다. 처음에는 데니스와 브라이언이 남긴 시편이 그 역할을 하고 있었지만, 사람들은 보다 명확한 말씀을 원했다. 그래서 몇명의 식자가 모여 설화를 정리하여, 그녀의 가르침을 바르게 전하기 위한 경전을 편찬했다. 그 책은 지금까지 몇번인가 개정되어, 개정된 해에 따라 C89, C99, C11 등으로 불리고 있다.

일반인은 C님과 직접 대화할 수 없다. 충분한 수행을 쌓은 자만이 C님과 교신하는 것을 허락받는다.

수행은 매우 엄하여 「포인터・노・포인터」같은 난문을 이해하고, 아무리 수행을 쌓아도 실패하는 자가 끊이지 않는 「엠얼록・프리」를 100% 성공시켜야 한다. 그런 배경으로 인해 그녀와 일상적으로 교신하고 있는 자는 절대 많지 않다.

하지만 교신을 행하는 자들의 손을 통해, 많은 지식과 기술이 이 세계에 태어나고 있다. 만약 당신이 그녀의 모습을 보지 못하더라도, 그 자애는 오늘도 확실히 당신에게 전해지고 있을 것이다.

VisualBasic

  • 1991년 5월 20일
  • 22세
  • 별자리 : 황소자리
  • 혈액형 : O형
  • 신장 : 155cm
  • 체중 : 45kg

성은 Basic, 이름은 Visual. VB라는 닉네임으로 부르는 사람도 많다. 어릴적 이름은 Ruby라고 한다(그 Ruby와는 아무런 관계도 없다). 어릴 적에 어떤 자산가(이름을 불러서는 안되는 그 사람)의 눈에 들어, 일가 전체가 자산가에게 의탁하게 된다. 그 때에 몇번인가 이름이 바뀌다가 지금 이름으로 정착했다는, 조금 복잡한 가정환경을 갖고 있다.

자산가가 어째서 아직 어리던 그녀를 떠맡았는가. 어디까지나 소문에 지나지 않지만, 일설에 의하면 그가 어릴 적에 동경하던 Basic 씨와 어딘가 통하는 점을 그녀에게서 발견한 것이 이유일 것이라 한다. 동경하던 여성과 비슷한 분위기가 있는 아이를 떠맡는, 흔히 말하는 키잡 계획을 실행했다는 것이다.

젊은 사람들은 모를지도 모르겠지만, Basic 씨는 패션잡지 「베마가」의 톱모델도 했던, 당시에는 모든 사람이 동경하던 마돈나였다. 내가 아는 사람 중에도 젊었을 때 그녀에게 심취했던 사람이 굉장히 많다.

VB는 엄한 교육을 받으면서도 올곧게 자라났고, 취미 분야에서 타고난 손재주를 살려 수예나 액세서리 제작 등에 재능을 보였다. 그녀가 비즈 액세서리를 제작하는 것을 본 적이 있는데, 실로 마법과 같았다. 손을 슥슥 움직이는 것만으로도 순식간에 목걸이가 생겨난 것이다.

그녀가 10살 때, 자산가의 집에 새로운 양녀(전에 이야기한 그 사람)가 들어온다.

그래서 요즘은 집에서 좋은 언니가 되기 위해 노력하고 있다. 하지만 원체 기가 약하고 그다지 말을 잘하지 못하는 지라, 10살 연하이면서도 야무지고 말도 잘하는 동생에게 오히려 설교당하기도 한다고. 힘내라 VB양.

어릴 적에는 부모가 사주었던 에밀리 템플의 옷을 입었지만, 지금은 직접 산 로리즈 팜의 옷을 입는 경우가 많다. 올해로 대학을 졸업하고 내년부터는 사회인이 되므로, VB양 나름대로 어른스러운 노선을 지향하고 있는 듯하다.

R

  • 2000년 2월 29일
  • 14세
  • 별자리 : 물고기자리
  • 혈액형 : A형
  • 신장 : 146cm
  • 체중 : 39kg

그녀는 2000년 2월 29일에 태어났다. 400년에 한번 돌아오는 저주받은 날로 사람들이 기억하는 그 날이다. 상당히 불길한 날에 태어났지만, 그녀 자신은 사람들에게 사랑받는 영리한 아이로 성장해갔다.

그녀의 모친의 이름은 S라고 한다. 신화의 세계에서는 B 후에 C가 태어났지만, 그녀의 이름은 반대로 S에서 하나 거슬러 올라가 R이 되었다. 어느쪽이든 상당히 구글링하기 힘든 이름이다.

어머니는 굉장히 숫자에 강한 사람으로 통계학자의 조수등을 하고 있었는데, R도 그 성질을 이어받은 듯 하다. 어릴 적부터 숫자에 강해, 초등학생 시절에 이미 고등학교 수학문제를 쉽게 풀어버리는 수준에 달해있었다. 또, 기하학적인 도형에도 흥미를 갖고 있는 듯, 2차원이나 3차원의 여러 도형을 그려보고는 완성된 그림을 보면서 혼자 만족스러운 표정을 띄우는 모습이 몇번이나 목격되었다는 좀 별난 아이다.

숫자에 강한 대신 언어 쪽은 조금 힘들어하는 것 같다. 예전에 그녀와 인터뷰를 했을 때에는 이쪽에서 던진 질문에 대답을 하려고 했지만 좋은 단어가 생각나지 않았는지, 대신에 산포도(散布図)를 딱 그리고는 「이런 느낌」이라고 대답했던 적이 있었다. 어쩌면 그녀의 눈에는 이 세계가 단어로는 표현하기 힘든, 여러 개가 겹쳐진 수식으로 보이는 것일지도 모른다.

복장은 그다지 신경쓰지 않는 듯, 넉넉한 원피스나 브라우스를 입는 일이 많다.

옷은 부모가 사준다고 하며, 얼마정도 하는 옷이 어디서 파는지 등은 인식하고 있지 않았다. 유일하게 강한 관심을 보이는 것은 최근 받은 플레어 스커트의 옷자락이 펼쳐지는 각도에 관한 것이었다.

장래의 꿈은 통계학자가 되는 것이라고 하며, 14살이라는 연령에도 대학에 출두하여 학생들과 섞여 문제를 푸는 나날을 보내고 있다. 최근에는 대학에만 다니는 것도 질린 듯, 부모에게 부탁하여 여러 연구소에도 드나들고 있다던가.

Scala

  • 2004년 1월 25일
  • 10살
  • 별자리 : 물병자리
  • 혈액형 : AB형
  • 신장 : 141cm
  • 체중 : 35kg

오랜 기간에 걸쳐 종교전쟁이 펼쳐져온 O교와 F교. Scala는 그 두 종교의 목사와 수녀가 결혼하여 태어난 이단의 아이다. 태어난지 얼마 안되어 양가 사이에 심한 대립이 일어났고, 위험을 느낀 양친은 사립 JVM 학원의 오더스키 선생의 양녀로 그녀를 맡겼다.

현재는 당시와 비교하면 두 종교의 관계가 개선의 여지를 보이고 있으며, 일부에서는 그녀의 존재를 융화의 상징으로 보는 시각도 있다. 하지만 아직 강한 대립심을 갖고 있는 사람도 많아, 그녀의 존재가 논쟁의 씨앗이 될 때도 종종 있다. F교의 사람들은 그녀의 존재를 충분히 F하다고 인정하지 않으며, O교의 사람들은 F의 존재가 섞인 그녀를 이해하기 힘들다고 느낀다.

그런 복잡한 환경에서 태어났지만 그녀 자신은 주위의 반응에 크게 신경쓰지 않는 듯, 양쪽 교회에 아무렇지도 않게 나타나 빵을 얻어오는 등 씩씩하게 살아가고 있다. 그녀의 그런 천진난만한 모습에 이끌려 열렬한 팬이 되는 자도 많다고 한다.

Scala는 같은 학원의 고등부에 다니는 Java씨를 좋아하는 듯, 쉬는 시간이 되면 빈번하게 그녀에게 찾아간다. Java씨도 Scala를 나쁘게 생각하지는 않는 듯, 연상의 언니답게 그녀를 무릎 위에 앉히고 상냥하게 머리를 쓰다듬거나 한다고 한다. Scala가 Java씨가 좋아하는 듀크군 인형을 빨간 로프로 묶는 장난을 쳤을 때에는 역시 혼난 듯 하지만, 그 이외에는 싸운 일이 거의 없다. 마치 진짜 자매같은 두 사람이다.

박식한 양부와 상냥한 언니를 가진 Scala는 그 복잡한 출생을 이겨내고, 실로 행복한 장소에서 생활하고 있는 것 같다.

옷은 또렷한 색조의 무늬가 있는 것을 좋아한다고 하며, 알곤킨의 옷을 자주 입는다. 조금 개성적인 패션으로도 보이지만, 성장환경부터 개성적인 그녀가 입으면 그것도 자연스럽게 보이는 것이 신기하다.

shell

  • 생년월일 : 불명
  • 별자리 : 불명
  • 혈액형 : 불명
  • 신장 : 60cm (추정)
  • 체중 : 12kg (추정)

창세기(1970년 1월 1일)로부터 몇년이 경과한 무렵부터 존재가 목격되기 시작한 요정. 집에 눌러앉는, 흔히 말하는 브라우니에 가까운 생태를 갖고 있으며, 가사나 잡일 등을 부탁하면 두가지 대답으로 받아주는 착한 아이들이다.

그녀들은 인간이 있는 곳에는 거의 모습을 드러내지 않고 말도 하지 않기에, 의사소통을 할 때에는 편지를 이용한다. 애매한 부탁을 하면, 내용을 착각하여 엄청난 일을 저지르는 경우도 있으므로, 확실하게 「저것을 한다 | 이것을 한다 > 여기에 놓아둔다」처럼 순서를 세워서 부탁할 일을 적는 것이 요령이 필요하다. 부탁을 제대로 이해하고 나면, 그녀들이 밤 사이에 일을 처리해준다. 제대로 일을 해냈다면 다음날 저녁에 감사의 각설탕을 놓아두는 것을 잊지 말도록.

shell에는 여러 종족이 존재한다. 현재 확인된 종족 중에서 유명한 것을 들자면, 「ba」, 「c」, 「k」, 「tc」, 「z」등이 있다. 복장이나 용모는 종족별로 각자 다르지만, 내가 목격한 개체는 신장 60cm 정도로 버버리의 아동복을 입고 있었다. 아마도 목격예가 많은 「ba」종이 아닐까 한다. 개인적으로는 신장이 좀 더 크고 귀도 뾰족한 「z」종과 조우해보고 싶지만, 지금은 편지를 주고 받고는 있어도 실물을 본 적은 아직 없다.

같은 집에 살고 있음에도 그녀들이 사람의 눈에 띄이거나 하는 일은 거의 없으며, 어떻게 하면 만날 수 있는지도 해명되지 않았다.

일설로는 한밤중까지 프로그래밍을 하는 의식을 며칠동안 계속하고, 카페인으로 머리를 억지로 깨운 상태에서 문득 디스플레이를 보면, 그 너머에 그녀의 모습이 보인다고 한다. 하긴 내가 조우했던 것도 회사에서 밤샘하면서 프로그래밍을 하고 있었을 때였다.

shell은 개체수가 상당히 많아서 한 집에 한 명은 살고 있다고 한다. 사실은 여러분의 집에도 그녀들이 몇명인가 살고 있으면서 편지가 오기를 기다리고 있을지도 모른다.

ActionScript

  • 2000년 8월 24일
  • 13세
  • 별자리 : 처녀자리
  • 혈액형 : 0형
  • 신장 : 144cm
  • 체중 : 38kg

분쟁지역에서 태어난 13살의 여자아이.

아버지는 유명한 디자이너였지만, 그녀가 5살때 전화(戦火)에 휘말려 죽고 만다. 다행히 그녀는 아직 어렸고, 그녀를 맡은 어도비 삼촌이 소중하게 키워준 것도 있어, 마음에 커다란 상처는 남지 않았다. 삼촌이 아버지와 같은 디자이너이고, 그녀의 기억 안에서 두 사람이 자주 혼동되고 있는 것도 구원이었을지도 모른다.

그녀가 사는 나라는 JavaScript가 사는 나라의 옆에 위치하며, 양국은 같은 ECMA 인종으로 구성되어 있다. 외국사람 눈에는 JavaScript와 ActionScript는 같은 얼굴로 비치는 경우도 있다고 한다. 확실히 어린 시절의 사진을 보면 피부색이나 이목구비 등 닮은 부분도 보이지만, 성장한 지금 사진을 보면 어떨지.

노력가로 「조국과 삼촌을 위해 노력하자」를 모토로 하고 있는 그녀이지만, 노력이 보상받지 못하는 일도 많은 박복한 아이이다.

분쟁지역 일대에 새로운 공용어가 채용될 것이라는 뉴스가 흘러나왔을 때의 이야기다. 그녀는 곧 찾아올 평화로운 시대에 일조하고자, 누구보다도 빨리 그 언어의 공부를 시작했다. 하지만 이제야 유창하게 말할 수 있게 되었다고 생각할 때가 되자, 그 언어의 공용어로서의 채용은 미루어지게 된다.

모바일 단말에서의 디자인 쪽으로 그녀가 온힘을 다해 공부하기 시작할 때의 이야기다. 모바일 쪽의 실력자가 되면 삼촌이 하는 일에 도움이 될 수 있다. 조국에 외화를 가져다줄수도 있다. 그런 마음으로 노력했지만, 삼촌이 경영하는 회사가 거대 단말회사에게서 일방적으로 거래를 중지당하면서 모바일 관련 일거리도 급감하게 된다.

노력을 계속하면서도 좀처럼 보상받지 못하는 그녀지만, 오늘도 분쟁이 줄어들 기척을 보이지 않는 대지에 서서 앞으로 나아가려 하고 있다.

언젠가 그 노력이 보상받을 일이 올까. 부디, 10년 후의 미래에도 그녀가 무사히 있어주길. 앞을 보면서 살아가주길.

주의

※ 생년월일은 1.0 발표일을 기준으로 했습니다.

※ 언어 선별은 RedMonk의 Programming Language Ranking(StackOverFlow와 Github의 인기를 기반으로 만들어짐)에서 상위에 위치한 언어들 가운데 필자가 실제로 만나본 적이 있는 아이들을 올렸습니다. 「이 인기언어가 없다니!」하는 경우는, 필자가 직접 만나본 적이 없는 것이 원인입니다.

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

OpenGL ES 2.0 Tegra2/3/4의 Fragment Shader와 동적루프

(원문 : OpenGL ES 2.0 Tegra2/3/4 の Fragment Shader と動的ループ)

Desktop GPU에서 Vertex Shader와 Pixel Shader의 사양이 완전히 통일된 것은 Direct3D 10의 ShaderModel 4.0 이후입니다. 그때까지는 쓸 수 있는 명령이나 Constant 영역, 레지스터 수, 프로그램 사이즈, 텍스처 명령등 여러가지 차이가 남아있었습니다.

Hardware의 Unified Shader화는 ATI의 Xbox360 GPU가 먼저 시작하였습니다. 이것이 지금의 Qualcomm Adreno로 이어집니다. 그 후 일반적인 Desktop PC용으로도 NVIDIA GeForce 8800 (G80)이 등장하여, 이후 Unified Shader Model이 당연해지게 됩니다.

OpenGL ES 2.0의 Shader 세대는 Direct3D 9의 Shader Model 3.0에 해당합니다만, 많은 Mobile GPU가 이미 Unified Shader화되어있습니다. 그렇기에 딱히 Vertex와 Fragment Shader의 성능차를 의식할 필요는 없었습니다.

그 중, Tegra2/3/4는 G70 베이스의 GPU로, Unified Shader화되기 전의 제한이 남아있는 드문 케이스입니다.

코멘트에서 Tegra의 Fragment Shader는 동적 루프를 쓸 수 없다는 지적을 받았기에 테스트해보았습니다.

// (1) 동적 루프
int loop= int( uniform_value );
for( int i= 0 ; i < loop ; i++ ){
   ...
}

↑루프 회수를 동적으로 구하는 경우, Vertex Shader는 통과하지만 Fragment Shader에서는 컴파일 시에 에러가 발생합니다.

예전에 적었듯 Uniform 배열의 index 접근↓(2)도 Tegra의 Fragment Shader에서는 에러가 뜹니다. 둘 다 Direct3D 9 세대의 제한이라 생각됩니다.

// (2) Uniform 배열
uniform vec4 src_color[30];
~
int index= int(tex_color.x);
vec4 color= src_color[ index ]; // Tegra의 Fragment Shader에서는 Error

Tegra 4에서도 마찬가지이므로, 기능은 대폭 확장되었지만 GPU의 베이스는 같다는 것을 알 수 있습니다. 참고로 Tegra와 같은 Discrete Type의 Shader Unit을 갖춘 Mali-400MP에서는 작동합니다.

	     Vertex Shader            Fragment Shader
	     동적Loop  Uniform배열    동적Loop  Uniform배열
-----------------------------------------------------------
Unified      ◯         ◯              ◯         ◯
Mali-400MP   ◯         ◯              ◯         ◯
Tegra2/3/4   ◯         ◯              ERROR     ERROR

하지만 Tegra에서도 동적 분기는 가능하기에, 실행시에 루프 횟수가 변동하는 경우에도 동등한 처리를 실현할 수는 있습니다.

// (3) Tegra용 동적분기에 의한 루프
for( int i= 0 ; i< 100 ; i++ ){
    if( i >= Loop ){
        break;
    }
    ~ 동적 루프에 해당하는 부분
}

이하 정리 (모두 Fragment Shader의 경우)

컴파일 시에 루프 횟수가 정해져 있지 않으면 에러.

// (4) 루프횟수 미정  -- Tegra에서 ERROR
for( int i= start ; i< end ; i++ ){
    ~
}

루프 범위가 정해저 있으면 컴파일 가능

// (5) 상한이 정해져있는 경우 -- Tegra에서도 OK
for( int i= 0 ; i< 100 ; i++ ){
    if( i >= start && i < end ){
        ~ 동적 루프에 해당하는 부분
    }
}

아마도 아래와 같이 전개되지 않을까 생각됩니다.

i= 0;
if( i >= start && i < end ){
    ~
}
i= 1;
if( i >= start && i < end ){
    ~
}

~

i= 99;
if( i >= start && i < end ){
    ~
}

Tegra K1 이후는 ShaderModel 5.0 세대의 GPU core가 되므로 이런 하드웨어적 제한은 없어질 것입니다.

관련글

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

MediaTek MT8125/8389 Cortex-A7의 부동소수점 연산속도

(원문 : MediaTek MT8125/8389 Cortex-A7 の浮動小数点演算速度)

ARM Cortex-A7은 big.LITTLE에 사용될 때 저전력 CPU core에 해당합니다. 소비전력이 낮은 대신 고성능 CPU core보다 성능이 떨어집니다. VFP Benchmark의 결과를 보내드립니다.

결과를 보면, Cortex-A7의 NEON은 32bit 단위로 실행되고 있음을 알 수 있습니다. 연산속도는 NEON이 없는 CPU와 다르지 않습니다만, Cortex-A15와 페어로 기능하게 하기 위해 NEON 명령셋에 대응하는 것이라 생각됩니다.

SIMD (Vector)         SIMD4 single fp (32bit x4)
CPU                   mul    add     mad     fma
------------------------------------------------------
ARM Cortex-A7         1      1       2       2
ARM Cortex-A8         2      2       4       –
ARM Cortex-A9         2      2       4       –
ARM Cortex-A15        4      4       8       8
Qualcomm Scorpion     4      4       8       –
Qualcomm Krait 400    4      4       8       8
Apple A6 Swift        4      4       8       8
Apple A7 Cyclone 32   8      12      16      16
Apple A7 Cyclone 64   8      12      –       16

  * 수치는 1 cycle당 연산수. 클수록 빠름

big.LITTLE에서 사용되는 경우에는 이런 연산을 Cortex-A15가 담당하므로 표면에 나올 일은 아마 없을 것입니다. 단독으로 사용되는 경우, 같은 Quad core CPU라고 쓰지만 성능차가 상당히 벌어지는 것을 고려하는 것이 좋을 듯 합니다. 부동소수점 연산속도만 봐도 최대연산속도에서 Cortex-A9의 절반, Krait/Cortex-A15의 1/4(동일클럭일 때)가 됩니다.

다음은 상세한 내용입니다.

Lenovo YOGA TABLET 8 (3G)
MediaTek MT8389 1.2GHz Cortex-A7 Quad core

SingleT SP max: 2.374 GFLOPS
SingleT DP max: 1.165 GFLOPS
MultiT  SP max: 9.474 GFLOPS
MultiT  DP max: 4.653 GFLOPS

* VFP/NEON (single fp)
VFP fmuls (32bit x1) n8       :    3.634     1100.7     1100.7
VFP fadds (32bit x1) n8       :    3.450     1159.3     1159.3
VFP fmacs (32bit x1) n8       :    3.451     2318.1     2318.1
VFP vfma.f32 (32bit x1) n8    :    3.448     2319.9     2319.9
NEON vmul.f32 (32bit x2) n8   :    6.795     1177.3     1177.3
NEON vadd.f32 (32bit x2) n8   :    6.828     1171.7     1171.7
NEON vmla.f32 (32bit x2) n8   :    6.810     2349.6     2349.6
NEON vfma.f32 (32bit x2) n8   :    6.797     2354.1     2354.1
NEON vmul.f32 (32bit x4) n8   :   13.529     1182.7     1182.7
NEON vadd.f32 (32bit x4) n8   :   13.511     1184.2     1184.2
NEON vmla.f32 (32bit x4) n8   :   13.498     2370.7     2370.7
NEON vfma.f32 (32bit x4) n8   :   13.549     2361.8     2361.8

배정밀도의 경우에는 더욱 차이가 벌어져, 덧은 1 cycle에 실행할 수 있지만 곱셈은 4배 느립니다. 더욱이 fmacd(덧곱셈[각주:1])은 승산과 동등한 속도로 연산되긴 하지만, vfma(FMA)는 병렬화되지 않아 5배(1 add + 4 mul cycle)나 걸리는 것 같습니다.

* VFP/NEON (double fp)
VFP fmuld (64bit x1) n8       :   13.628      293.5      293.5
VFP faddd (64bit x1) n8       :    3.439     1163.0     1163.0
VFP fmacd (64bit x1) n8       :   13.508      592.2      592.2
VFP vfma.f64 (64bit x1) n8    :   16.895      473.5      473.5
VFP fmuld (64bit x1) ns4      :   13.434      297.8      297.8
VFP faddd (64bit x1) ns4      :    3.435     1164.6     1164.6
VFP fmacd (64bit x1) ns4      :   13.430      595.7      595.7
VFP vfma.f64 (64bit x1) ns4   :   16.823      475.5      475.5
VFP fmuld (64bit x1) n1       :   13.439      297.6      297.6
VFP faddd (64bit x1) n1       :    3.447     1160.6     1160.6
VFP fmacd (64bit x1) n1       :   26.856      297.9      297.9
VFP vfma.f64 (64bit x1) n1    :   26.860      297.8      297.8

관련 글

  1. 실수 두 값을 곱한 후 그 결과를 목표값에 더하는 연산(fd += fn * fm)의 의역. fmacd는 배정밀도 실수의 덧곱셈 명령 [본문으로]

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

VFP Benchmark v1.1 부동소수점 연산 명령의 속도 (NEON/SSE/AVX)

(원문 : VFP Benchmark v1.1 浮動小数点演算命令の速度 (NEON/SSE/AVX))

x86의 SSE/AVX 명령에 대응했습니다. ARM CPU와 마찬가지로 SSE/AVX의 명령속도를 계측할 수 있습니다.

위는 Android입니다만, iOS판에서는 ARMv8A (arm64)에 대응합니다. 다음은 갖고 있는 디바이스에서의 결과입니다.

Device           CPU                             sp GFLOPS  dp GFLOPS
---------------------------------------------------------------------
MacBookRetina13  Core i5-3210M Ivy    2.5GHz x2       90.2       45.2
Kindle HDX 7     MSN8974  Krait 400   2.2GHz x4       67.5       16.9
Tegra Note 7     Tegra4   Cortex-A15  1.8GHz x4       51.3        9.8
Nexus 7 (2013)   AQP8064  Krait       1.5GHz x4       47.8       11.8
iPhone 5s        A7 arm64 Cyclone     1.3GHz x2       40.9       20.5
iPhone 5s        A7 arm7s Cyclone     1.3GHz x2       40.9        8.0
Mac mini 2009    Core2 Duo P7350      2.0GHz x2       31.7       12.7
Nexus 10         Exynos5D Cortex-A15  1.7GHz x2       26.7        5.3
iPad 4           A6X      Swift       1.4GHz x2       21.5        3.6
iPhone 5         A6       Swift       1.3GHz x2       20.1        3.4
Nexus 7 (2012)   Tegra3   Cortex-A9   1.3GHz x4       18.9        4.7
EVO 3D ISW12HT   MSM8660  Scorpion    1.2GHz x2       16.6        1.3
VAIO Type P      Atom Z540 Bonnell    1.8GHz x1       10.9        1.9
Desire X06HT     QSD8250  Scorpion    1.0GHz x1        7.1        0.9
iPad 2           A5       Cortex-A9   1.0GHz x2        7.8        2.0
iPod touch 4     A4       Cortex-A8   0.8GHz x1        3.1        0.1
Raspberry Pi     BCM2835  ARM1176JZFS 0.7GHz x1        0.7        0.7

 * 수치가 클수록 빠름
 * sp= 단정밀도, dp= 배정밀도

최대치를 측정한 것이므로 실제 애플리케이션 속도와는 차이가 있습니다. 자세한 것은 이곳을 참조하시기 바랍니다. 다음 페이지의 이론치 거의 그대로 나오는 경향을 보입니다.

배정밀도 테스트는 아직 개량의 여지가 있습니다. 스칼라에서 mul+add의 페어링을 측정하지 않으므로, 일부 CPU에서 점수가 좀 더 늘어나리라 생각됩니다.

Core i5 Ivy Bridge는 예상한 것 보다 높은 수치가 나왔는데, TurboBoost 효과로 더 높은 클럭으로 동작하는 것 같습니다. single-thread 시에는 3.0GHz, multi-thread 시에는 2.85GHz에 상당하는 결과가 나왔습니다.

실제 측정결과는 명령단위의 수치를 나타내므로, CPU 동작을 보다 자세하게 조사할 수 있습니다.

SSE2/AVX1에는 덧곱셈명령[각주:1]이 없습니다만, Intel CPU는 가산과 승산명령을 병렬로 실행할 수 있는 듯합니다. ↓를 보면 실제로 addps/mulps의 Interleave는 절반 시간으로 실행합니다.

Ivy Bridge Core i5-3210M
* SSE/AVX (single fp)                sec     MFLOPS     MFLOPS
AVX vmulps (32bit x8) n8      :    1.322    24205.7    24205.7
AVX vaddps (32bit x8) n8      :    1.319    24256.0    24256.0
AVX vmul+addps (32bit x8) n8  :    0.658    48604.4    48604.4

↓ Atom (Bonnell)의 경우는 조금 특수합니다. SSE 명령의 승산이 가산보다 2배의 시간이 걸립니다. 동작 클럭을 생각하면 SSE의 add가 128bit이고 mul를 64bit 폭으로 연산하고 있다고 생각됩니다.

Atom Z540 (Bonnell)
* SSE/AVX (single fp)                sec     MFLOPS     MFLOPS
SSE mulps (32bit x4) n8       :    4.307     3715.2     3715.2
SSE addps (32bit x4) n8       :    2.207     7248.1     7248.1
SSE mul+addps (32bit x4) n8   :    2.155     7424.2     7424.2

ARM NEON의 경우, 같은 SIMD라도 64bit 명령이 있습니다. 예를 들어 「vadd.f32 d0,d1,d2」는 단정밀도 32bit x2의 64bit 가산을 처리하므로, Cortex-A8/A9처럼 64bit 폭이라도 1cycle로 실행합니다. 128bit 명령 「vadd.f32 q0,q1,q1」의 경우에는 2cycle 걸립니다.

SSE는 항상 4요소 = 128bit 단위이므로 Pentium 3 등 64bit 폭의 SIMD Unit에서는 최소 2cycle이 걸리게 됩니다. 마찬가지로 Atom의 승산도 최소치는 2cycle입니다. 다만 mulps + addps의 Interleave라도 addps만 쓸 때와 같은 시간에 완료되므로, 가산과 승산은 비대칭이면서도 Overlap될 수 있는 듯 합니다.

Atom에는 HT가 있어 Multi-thread 시에 불필요한 빈틈을 메울 수 있습니다. 메인스레드에서 mulps + addps의 페어를 실행하고, 서브스레드에서 addps만 돌리면 아마도 128bit + 64bit의 비대칭 파이프라인이 메워질 것입니다.

mulps + addps + addps 조합을 2스레드 돌린 결과가 아래로, 점수가 늘어났음을 알 수 있습니다.

Atom Z540 (Bonnell)
* SSE/AVX (single fp) multi-thread   sec     MFLOPS     MFLOPS
SSE ml+ad+addps (32bit x4) n6 :    3.075    10926.6    10926.6

이 측정 결과를 통해 CPU의 개별 연산능력을 정리한 것이 아래의 표입니다. 배정밀도 값은 좀 더 변동될 가능성이 있습니다.

스칼라

                  단정밀도                    배정밀도
CPU               mul    add    mad   fma     mul    add    mad    fma
-----------------------------------------    -------------------------
ARM1176JZF-S      0.5    0.5      1    --     0.5    0.5      1     --
Cortex-A8        0.14   0.14   0.18    --     0.1    0.1    0.1     --
Cortex-A9           1      1      2    --     0.5      1      1     --
Cortex-A15          1      1    1.4     2       1      1    1.4    1.4
Scorpion            1      1      2    --     0.5      1      1     --
Krait 400           1      1      2     2       1      1    1.6      2
A6 Swift            1      1      1     1       1      1      1      1
A7 Cyclone arm7s    1      1      2     2       2      3      3      3
A7 Cyclone arm64    2      3     --     4       2      3     --    1.6
Atom Bonnell        1      1     --    --     0.5      1     --     --
Core2 Penryn        1      1     --    --       1      1     --     --
Core i5 Ivy Bridge  1      1     --    --       1      1     --     --

 * 수치는 1 cycle에 실행가능한 연산수
 * 값이 클수록 고속

ARM11의 mul은 0.5연산/cycle입니다. 다시 말해 단정밀도의 가산이나 승산은 2cycle 걸립니다.

mad/fma는 명령당 2연산이므로, 이 란이 2의 경우에는 1cycle로 실행할 수 있음을 의미합니다.

Cortex-A8의 최대 FLOPS는 NEON 덕분에 ARM11 보다 높지만, 위에 적은 대로 VFP의 스칼라 연산에서는 ARM11에 집니다.

A7 Cyclone (ARMv8A)은 AArch32 (32bit mode)와 AArch64 (64bit mode)에 상당한 차이가 있습니다. 단정밀도 연산은 64bit mode 쪽이 수배 빠르게 실행되는 것 같습니다. 아마도 VFP가 요구하는 사양이 NEON과 다르기 때문이라 생각됩니다. AArch64는 NEON으로 통일되었기에, NEON과 동등한 속도로 동작되는 것 같습니다. VFP가 발을 붙잡는 것처럼 보이는 경향은 Cortex-A15등 다른 ARMv7A CPU에서도 보입니다.

SIMD 단정밀도

                   SIMD2 (32bit x 2)         SIMD4 (32bit x4)
CPU                mul   add   mad   fma     mul   add   mad   fma  
----------------------------------------    ----------------------
ARM1176JZF-S        --    --    --    --      --    --    --    --
Cortex-A8            2     2     4    --       2     2     4    --
Cortex-A9            2     2     4    --       2     2     4    --
Cortex-A15           4     4     8     8       4     4     8     8 
Scorpion             2     2     4    --       4     4     8    -- 
Krait 400            2     2     4     4       4     4     8     8 
A6 Swift             2     2     4     4       4     4     8     8 
A7 Cyclone arm7s     4     6     8     8       8    12    16    16 
A7 Cyclone arm64     4     6    --     8       8    12    --    16
Atom Bonnell        --    --    --    --       2     4    (6)   --
Core2 Penryn        --    --    --    --       4     4    (8)   --
Core i5 Ivy Bridge  --    --    --    --       4     4    (8)   --

Cortex-A8/A9는 64bit 폭이라 SIMD2에서는 Scorpion/Krait/Swift와 차이가 없습니다. SIMD4에서는 128bit의 Scorpion/Krait/Swift의 절반이라는 것을 알 수 있습니다.

특이한 것은 Cortex-A15로, SIMD4에서는 같은 128bit인 Scorpion/Krait/Swift와 동등합니다만 SIMD2에서는 2배의 수치를 나타냅니다. Cortex-A15는 64bit폭 2pipe라서 2명령 동시실행이 가능하기 때문입니다. 스칼라에서는 단정밀도도 1명령/cycle이기 때문에, 절반밖에 쓰지 못한다고 해도 NEON 쪽이 빠릅니다.

Ivy Bridge는 AVX에 대응하므로, 위의 표에서는 생략되어 있지만 SIMD8이 있습니다. 아래 페이지에 SIMD8과 배정밀도 SIMD를 포함한 표를 정리했습니다.

제일 위쪽에 있는 GFLOPS 리스트에서는 Quad core 및 동작 클럭이 높은 Snapdragon 800 (MSM8974)가 상위였습니다. CPU의 cycle 단위 명령수를 내보면, 유일한 ARMv8 CPU이기도 한 A7 Cyclone이 발군의 고성능임을 알 수 있습니다.

계측결과를 보면 mul, mad/fma는 2명령, add는 3명령을 동시에 실행할 수 있는 듯 합니다. NEON의 경우에는 AArch32와 AArch64에 딱히 차이는 없었습니다.

A7 Cyclone의 설계는 DEC Alpha나 StrongARM 출신의 엔지니어가 관련되어있다고 합니다. (Wikipedia P.A.Semi)

Benchmark는 어디까지나 부동소수점 연산능력의 최대치를 실측하는 것이 목적이므로, 반드시 종합적인 우세와 일치하지 않음을 미리 양해바랍니다.

관련 글

  1. 積和의 의역. 두 수를 곱한 후 다른 수에 더하는 명령 [본문으로]

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

ARM CPU의 VFP Benchmark앱 부동소수점 연산속도 계측

(원문 : ARM CPU の VFP Benchmark アプリ 浮動小数点演算速度の計測)

지금까지 ARM CPU의 부동소수점 연산속도에 관해서 조사해왔는데, 그 계측 프로그램을 앱으로 만들어보았습니다.

지금까지의 계측결과를 정리한 결과는 아래와 같습니다.

VFP Benchmark 앱의 표시결과는 위의 표와 호환성이 있습니다. 거기에 FLOPS 표시, 배정밀도 부동소수점 연산의 계측, 멀티스레드 실행에 대응했습니다. 아래는 몇가지 단말의 결과(일부)입니다.

MSN8974 Krait 400 2.2GHz x4 quad
---------------------------------------
SingleT SP max : 16.619 GFLOPS
MultiT  SP max : 67.185 GFLOPS (이론치: 70.4 GFLOPS)
                               = 2(mad) x 4(simd) x 4(core) x 2.2(clock)


Tegra4 Cortex-A15 1.8GHz x4 quad
---------------------------------------
SingleT SP max: 13.371 GFLOPS
MultiT  SP max: 51.345 GFLOPS  (이론치: 57.6 GFLOPS)
                        = 2(mad) x 2(simd) x 2(unit) x 4(core) x 1.8(clock)


APQ8064 Krait 1.5GHz x4 quad
---------------------------------------
SingleT SP max: 11.947 GFLOPS
MultiT  SP max: 47.808 GFLOPS  (이론치: 48.0 GFLOPS)
                               = 2(mad) x 4(simd) x 4(core) x 1.5(clock)

Exynos5D Cortex-A15 1.7GHz x2 dual
---------------------------------------
SingleT SP max: 13.483 GFLOPS
MultiT  SP max: 26.724 GFLOPS  (이론치: 27.2 GFLOPS)
                        = 2(mad) x 2(simd) x 2(unit) x 2(core) x 1.7(clock)


Tegra3 Cortex-A9 1.2GHz x4 quad (TB1.3GHz)
---------------------------------------
SingleT SP max:  4.783 GFLOPS  (이론치:  5.2 GFLOPS
MultiT  SP max: 18.905 GFLOPS  (이론치: 19.2 GFLOPS)
                               = 2(mad) x 2(simd) x 4(core) x 1.2(clock)

K3V2 Cortex-A9 1.2GHz x4 quad
---------------------------------------
SingleT SP max:  4.694 GFLOPS
MultiT  SP max: 18.662 GFLOPS  (이론치: 19.2 GFLOPS)
                               = 2(mad) x 2(simd) x 4(core) x 1.2(clock)


MSN8260 Scorpion 1.2GHz x2 dual
---------------------------------------
SingleT SP max:  8.898 GFLOPS
MultiT  SP max: 16.560 GFLOPS  (이론치: 19.2 GFLOPS)
                               = 2(mad) x 4(simd) x 2(core) x 1.2(clock)


QSD8250 Scorpion 1.0GHz x1
---------------------------------------
SingleT SP max:  7.098 GFLOPS  (이론치:  8.0 GFLOPS)
                               = 2(mad) x 4(simd) x 1.0(clock)

Tegra 2 Cortex-A9 1.0GHz x2 dual
---------------------------------------
SingleT SP max:  1.973 GFLOPS
MultiT  SP max:  3.913 GFLOPS  (이론치:  4.0 GFLOPS)
                               = 2(mad) x 2(core) x 1.0(clock)

비교적 이론치에 가까운 수치를 내고 있습니다. 각 CPU의 이론치는 아래에 정리했습니다.

이 출력결과는 어디까지나 최대치에 의한 비교이므로, 실제 애플리케이션 실행속도와는 차이가 있습니다.

예를 들어 스칼라 VFP 연산에서 n8과 n1의 결과를 비교하면 Cortex-A9에서는 명령순에 따라 속도가 5배나 떨어지는 경우가 있습니다. 같은 조건에서 Krait/Cortex-A15은 거의 속도가 떨어지지 않으므로, 파이프라인의 실행효율이 향상되었다는 것을 알 수 있습니다.

따라서 실제 애플리케이션에서는 Cortex-A9과 Krait/Cortex-A15은 최대치보다도 훨씬 차이가 날 것이라는 것을 예상할 수 있습니다.

multi-thread는 같은 테스트를 CPU core의 수만큼 돌립니다. Tegra 3처럼 single thread 시에 동작 클럭이 올라가는 것도 있으므로, single-thread의 값을 core 수만큼 곱해도 바른 값이 나오지는 않기 때문입니다.

앱의 출력결과를 보면 Cortex-A15는 VFP의 스칼라 연산보다도 NEON의 64bit (float x2) 쪽이 2배 빠르게 실행된다는 것을 알 수 있습니다.

// Exynos 5 Dual Cortex-A15 1.7GHz dual (Nexus 10)

* VFP/NEON (single fp)         sec    MFLOPS    최대
----------------------------------------------------
VFP fmuls     (32bit x1) n8 :  2.675  1495.4  1555.9
VFP fadds     (32bit x1) n8 :  2.392  1672.1  1672.1
VFP fmacs     (32bit x1) n8 :  3.171  2523.2  2523.2
VFP vfma.f32  (32bit x1) n8 :  2.985  2679.9  2679.9
NEON vmul.f32 (32bit x2) n8 :  1.187  6740.5  6740.5  **
NEON vadd.f32 (32bit x2) n8 :  1.187  6740.7  6740.7  **
NEON vmla.f32 (32bit x2) n8 :  1.187 13480.8 13480.8  **
NEON vfma.f32 (32bit x2) n8 :  1.187 13480.3 13480.3  **
NEON vmul.f32 (32bit x4) n8 :  2.373  6741.8  6741.8
NEON vadd.f32 (32bit x4) n8 :  2.374  6740.7  6740.7
NEON vmla.f32 (32bit x4) n8 :  2.373 13482.7 13482.7
NEON vfma.f32 (32bit x4) n8 :  2.373 13482.3 13482.3

이전에 예상했듯이 아마도 NEON의 연산 unit은 64bit의 2pipe이지만, VFP는 1명령밖에 실행하지 못할 가능성이 있습니다. Cortex-A8에서 그랬듯이 VFP 명령을 NEON 연산으로 바꾸면 Cortex-A15에 최적화될지도 모릅니다.

관련글

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

OpenGL ES 2.0 Adreno 330, Tegra 4의 GPU 속도

(원문 : OpenGL ES 2.0 Adreno 330, Tegra 4 の GPU 速度)

벤치마크 결과를 갱신했습니다.

Android 4.1 이후 및 대응하는 디바이스에서는 SwapInterval을 0으로 변경해서 60fps 이상 나옵니다. (관련글)

GPU            SoC   CPU clock OS    Screen     fps       pix/sec
---------------------------------------------------------------------
Adreno 330     MSM8974 2.2GHz  A4.2  1920x1200  71.98fps   165.8M
Adreno 320(64) APQ8064 1.5GHz  A4.4  1920x1104  40.97fps    86.8M
Mali-T604     Exynos5D 1.7GHz  A4.4  2560x1504  20.73fps    79.8M
ULP GeForce(72) Tegra4 1.8GHz  A4.3   1126x800  44.58fps    43.4M
ULP GeForce(12) Tegra3 1.2GHz  A4.4   1280x752  15.70fps    15.0M (*1)

*1: Shadow Map 없음, 16bit depth

Adreno 330은 예상 이상으로 빨라서, Adreno 320과 비교해도 약 2배 정도의 속도를 냅니다. 드디어 가장 부하가 높은 설정에서도 Full HD(1920x1200)에서 60fps를 넘게 되었습니다.

그에 비해 Tegra 4는 그다지 속도가 늘지 않았습니다. 부하를 낮춰도 속도가 올라가지 않으므로, SwapInterval 설정이 효과가 없던지 뭔가 문제가 발생했을 가능성이 있습니다.

그 대신 Tegra 3에서 생략되었던 여러 extension을 지원하여 렌더링 결과가 다른 GPU와 거의 일치하게 되었습니다.

특히 GL_EXT_shadow_samplers는 그냥 Hardware ShadowMap이 아니라 PCF에 제대로 Bi-linear Filter도 걸립니다. GL_EXT_shadow_samplers는 OpenGL ES 3.0 이후의 디바이스는 전부 대응하고 있지만, 반드시 Filter가 걸리는 것은 아닌 듯 합니다. 아래는 몇가지 테스트한 결과입니다.

                               depth-tex sh-samplers PCF Filter
----------------------------------------------------------------
8064 Adreno 320 OpenGL ES 3.0      ◎        ◎      ◎   --
8064 Adreno 320 OpenGL ES 2.0      ◎        --      --   --
Mali-T604       OpenGL ES 3.0      ◎        ◎      ◎   ◎
Tegra 4         OpenGL ES 2.0      ◎        ◎      ◎   ◎
Tegra 3         OpenGL ES 2.0      --        --      --   --
iOS PVR 543MP3  OpenGL ES 2.0      ◎        ◎      ◎   ◎
Vivante GC4000  OpenGL ES 2.0      ◎        --      --   --
Mali-400MP4     OpenGL ES 2.0      ◎        --      --   --
PowerVR SGX540  OpenGL ES 2.0      ◎        --      --   --

이쪽에 관해서는 조금 더 자세하게 조사할 생각입니다. 또 Tegra4의 Extension 상세사항은 다음 페이지에 추가했습니다.

관련 페이지

※ 이 글은 impress watch 에 실린 컬럼을 번역한 것입니다. 사정에 따라 예고없이 삭제될 수 있으므로 양해부탁드립니다.

최근의 태블릿/스마트폰용 SoC 제 4회~괴롭지만 SoC 비즈니스에 매진하는 Intel과 NVIDIA

(원문 : 今どきのタブレット/スマートフォン向けSoC 第4回~苦しみながらもSoCビジネスに邁進するIntelとNVIDIA)

지금까지 소개해온대로, 스마트폰/태블릿 시장은 ARM 천하, 더 정확하게 말하면 ARM 생태계의 천하가 되었고, 그 이외의 플레이어가 들어오기에는 굉장히 어려운 상황이다. 그럼에도 여기에 적극적으로 진입을 시도하는 벤더가 둘 있다. 말할것도 없이 Intel과 NVIDIA이다. 마지막회가 되는 이번회에는 그 양사의 움직임을 소개할까 한다.

IA/x86으로 ARM 생태계와 싸우는 Intel


2003년에 발표된 「PXA800」

Intel은 휴대전화에 흥미가 없지는 않았다. 1997년, Intel은 구 DEC과의 특허소송의 화해조건으로써 「StrongARM」의 제품 포트폴리오를 얻는다. 당시 이 StrongARM은 COMPAQ의 「iPAQ」시리즈 등의 PDA에 이용되는 것을 시작으로 나름대로 수요를 얻게 되는데, 여기서 "배팅 금액을 두배로 올리는" 것이 인텔 스타일. StrongARM은 ARM v4 기반의 제품이었지만, 1999년에 ARM에게서 ARM v5의 아키텍처 라이선스를 입수. StrongARM을 기반으로 내부를 완전히 뜯어고친 「XScale」을 완성시킨다.

이 시점에서 Intel의 계획은 지금과는 조금 다른 것이었다. PDA 시장은 나름대로 성장하고 있었지만 새 아키텍처 제품 라인을 유지하기에 충분하다고는 할 수 없는 출하량이었다. 그래서 휴대폰 시장에도 XScale을 투입함으로써 셰어의 확대 + 장기적인 매상 확보를 노리는 것이 속마음이었을 것이다.

이를 목표로 2003년, GSM/GPRS에 대응한 「PXA800」이라는 칩을 화려하게 발표한다. CPU 코어는 XScale, 베이스밴드에 관한 부분은 ADI(Analog Devices Inc.)에서 라이선스를 받아 DSP를 입수, 이것을 「Intel MicroSignal Architecture」로 실장했다. 당시에는 아직 Intel 자신이 플래시 메모리 부분을 보유하지 않았기에 이것도 실장. 거기에 SRAM을 4.5Mbit나 실장하는, 130nm 공정으로는 사치스럽다고 해야할지 욕심을 잔뜩 부린 사양의 SoC였다. 또 PXA800의 발표 이전에 발매한 「PXA210」도 피처폰용으로 투입할 계획이었다.

이미 알고 있겠지만 PXA210이나 PXA800을 채용한 휴대폰 메이커는 단 한곳도 없었고, PXA800의 후계인 「PXA900」이 RIM의 「Blackberry 7800」등 몇 기종에 채용되는 정도였으며, 그 수량도 그렇게 많지는 않았다. 그 결과, Intel은 XScale 아키텍처 자체를 포함한 PXA의 제품 라인을, 여기에 관련된 인원까지 통채로 Marvell에 매각해버린다. 여기서 한번 휴대폰용 비즈니스는 완전히 좌절되었다.


PXA800의 상세


피처폰용 「PXA210」

이런 뼈아픈 경험에도 불구하고 Intel이 다시 휴대폰 시장에 참가한 이유는, 이것도 알고 있겠지만 PC 시장의 축소경향 때문이다. 현시점에서 Intel의 경쟁력의 원천은 자사의 Fab에 의한 우수한 공정기술이다. 하지만 이 우수한 공정기술을 유지하기 위해서는 막대한 비용이 들어간다. 이는 단순히 공정을 개발하는 것만이 아니라, 양산을 위한 설비 비용도 점점 올라가고 있기 때문이다. 지금까지는 판매가격이 높은 PC용 프로세서를 대량으로 출하하는 형태로 커버할 수 있었다. 하지만 PC용 프로세서의 출하수량 자체가 쇠퇴경향을 보이는 현재로는

  • 차세대 공정 노드용 개발에 필요한 비용이 상승하여 프로세서 1개당 차지하는 개발/설비 비용도 상승. 반면 판매가격은 오히려 내려가고 있는지라 점점 이익이 줄어들어간다.
  • 순수하게 출하수량이 줄면 그만큼 Fab의 가동률이 내려가게 된다. 특히 Intel의 경우, 「Copy Exactly」라 불리는 복수 Fab에서 양산하는 방식을 전제로 생산라인의 개발이나 기기 발주를 하는데다, 애초에 자사 제품만을 생산하므로 소품종/다량이라는 형태의 양산이 된다. 그러므로 PC용 프로세서의 출하량이 줄어들었을때 다른 제품으로 메우기가 어려우며, 그대로 가동률 저하로 이어진다.

는 문제를 노출하게 된다.


PC 시장과 스마트폰/태블릿 시장의 역전 (JEDEC의 자료에서)

사실 Intel은 비교적 조기에 이런 문제를 알고 있었다. 애초에 2008년에 투입된 Atom은 당초부터 스마트폰용으로 투입될 것을 상정하고 있었고, 이를 위해 「Moorestown」플랫폼도 빠른 시기에 발표되었다. 그렇지만 이 Moorestown이 투입된 것은 2년 늦은 2010년이었다. 이유는 두가지다.

하나는 CPU측(Lincroft)가 재설계된 코어였다는 것이다. Lincroft의 기반이 된 Silverthorne은 순수하게 CPU만 있는 다이였지만, 스마트폰등을 대상으로 하려면 역시 GPU 통합이 필요하다. 최종적으로는 「Intel GMA 600」이라는 GPU를 통합했지만, 사실 이것은 Imagination의 「PowerVR SGX」였으며, 통합작업에 1년 이상을 요하게 되었다. 일반적으로는 Silverthorne의 개발과 병행하여 Lincroft의 개발작업이 진행되었으리라 생각하지만, 당시 Intel은 Atom을 이용하여 광범위한 제품 라인업을 제공할 예정이었으며, 필자는 개발측의 리소스가 부족한 게 원인아니었을까 생각한다.

또 하나는 45nm 세대의 SoC 공정 구축에 사실상 실패한 것이다. 고속 로직 대상 45nm 공정인 「P1266」은 2007년에 제공을 개시하고, 이 뒤를 이어 SoC 대상인 「P1267」을 2008년에 출시할 예정이었다. 당초 Lincroft는 이 P1267을 사용하여 제공할 예정이었다고 한다. 실제로 저전력을 추구한다면 고속 로직 대상인 P1266보다 P1267 쪽이 맞다. 하지만 Intel은 이 P1267의 개발에 사실상 실패. 이것을 채용한 것은 정말 극히 일부 제품에 머무르며, Lincroft만이 아니라 같은 SoC 공정을 사용하는 PC용 칩셋도 전부 32nm SoC용 「P1269」가 나올때까지 기다리는 처지가 되었다. 그 결과, Lincroft는 2010년에 투입되었음에도 동작주파수는 1GHz 전후(하이엔드인 Z625도 간신히 1.9GHz)밖에 되지 않았다. 2010년이라고 하면 40nm에 2GHz로 구동하는 Dual/Quad Cortex-A9 기반의 SoC가 나오고 있던 시기이며, 상품경쟁력이 전무하다고는 할 수 없어도 상당히 낮다고는 할 수 있다.



Atom 시리즈 발표 당시부터 Moorestown으로 스마트폰 시장을 상정하고 있었다.

다만, 45nm SoC에서 오랫동안 트러블을 경험한만큼 32nm의 P1269나 22nm의 「P1271」에서는 비교적 스무스하게 개발이 진행된듯, 2012년에는 기본적인 구성은 크게 바꾸지 않은 채 P1269를 사용한 「Medfield」가 등장, 거기에 2014년에는 CPU 코어의 마이크로아키텍처를 쇄신하고 P1271를 탑재한 「Merrifield」가 투입될 예정이다.

Medfield/Merrifield 모두 기본적인 아키텍처는 태블릿용인 「Clover Trail」이나 「Bay Trail」과 마찬가지로, 동작주파수나 소비전력을 스마트폰용으로 맞춘 정도의 물건이다. 참고로 Merrifield의 존재 자체는 2013년 6월의 COMPUTEX에서 소개되었지만, 제품 레벨의 상세 내용은 2014년 2월의 MWC로 미루어져, 공식으로는 아직 발표되지 않았다. 하지만 기본적으로는 Bay Trail과 같기에, 이미 제품은 스마트폰 벤더에게 넘겨져 실장이 어느 정도 끝나있을 것인지라, MWC가 열리는 타이밍에는 탑재제품도 발표되지 않을까 한다.


Medfield의 블럭 다이어그램


차기 스마트폰용 SoC 「Merrifield」

자, 예전에 앞으로의 로드맵을 나타낸 것이 다음 그림이다. 원래 베이스가 되는 Atom 코어 자체가 현재 22nm인 「Silvermont」에서 14nm 세대인 「Airmont」(Silvermont의 14nm공정 슈링크판)으로 바뀌는 것에 대응하여, 이 코어를 탑재한 「Moorefield」가 투입된다는 이야기는 예전에도 있었지만, 2013년 11월의 Investor Meeting에도 좀 더 이후의 이야기가 나왔다.


Intel이 예전부터 공표한 로드맵

먼저 2014년을 보면 전반에 Merrifield, 후반에 Moorefield가 투입되는 것은 기정사항이다. 하지만 이와는 별도로 「SoFIA」라 불리는 새로운 코어가 로우엔드용으로 투입된다. 이 SoFIA는 3G 모뎀을 내장한 제품이지만, 2015년에는 하이엔드로(Airmont의 후계로 기능을 강화한) 「Goldmont」코어를 내장한 「Boxton」, 로우엔드로는 내장 모뎀을 LTE 대응으로 바꾼 「SoFIA LTE」가 각자 투입되게 된다. 이 결과, 2015년에는 라인업이 매우 충실해진다.


11월 Investor Metting에서 공개된 로드맵. 2014년 후반에 「SoFIA」라 불리는 로우엔드용 코어가 제공된다.


2015년에는 「Boxton」, 「SoFIA LTE」도 투입


2015년의 태블릿용 라인업

재미있는 것은 이 SoFIA가 Intel 사내에서 제조하는 것이 아니라는 것이다. 명확히 표시되지는 않았지만 지금까지의 경위를 생각하면 TSMC에서 20nm 공정 혹은 16nm FinFET 공정으로 제조될 것 같다(필자는 전자의 가능성이 높다고 생각한다). 이러한 움직임은 처음 설명한 「Fab의 가동률을 높이는 것」과 정면으로 대립되는 것이지만, 이에 관해서 CEO인 Brian Krzanich 씨는 「우리는 현실적으로 생각해야한다」고 이야기했다. Intel의 Fab은 확실히 높은 기술을 자랑하지만, 그 반면 생산에 요하는 코스트도 높다. 즉 판매가격을 높게 잡을 수 있는 Boxton은 그렇다치고, 저가격제품용인 SoFIA까지 제조하면 비용을 맞추지 못하게 된다. 그렇기에 SoFIA는 외부 파운드리를 쓰기로 했다,는 말이리라.

이 배경도 역시 Investor Meeting에서 밝혀졌다. PC나 데이터서버 부문에서는 나름 흑자를 내고 있고 소프트웨어/서비스도 적자는 아니었지만, 그에 반하여 태블릿이나 스마트폰 부문은 명확한 적자였기 때문이다. 매상이 40억 달러인데 반해 영업이익은 25억달러 적자. 이렇게 되면 아무리 종합적으로는 흑자액이 많다고는 해도 부문 존속을 위해서는 뭔가 수를 써야 한다. 그 방법론의 하나로, 원가율을 낮추기 위해 제조를 외부위탁할 수 밖에 없었던 것이다.


「그 외 IA 제품」, 즉 스마트폰이나 태블릿 부문이 적자가 되어있다.

그럼, 여기서 손을 쓰면 Intel의 스마트폰용 SoC는 안녕할 것인가?하면 상당히 의심스럽다는 것이 솔직한 마음이다. 2회의 Qualcomm 항목에서도 설명했듯, 일단 스마트폰 시장에 들어가려는데 모뎀이 없으면 가격경쟁력이 현저하게 떨어진다. 그래서 힘내서 모뎀을 내장했다. 하지만 이미 그것만으로는 차별화 요인이 되지 못한다. 3회에서도 소개했듯, Spreadtrum이나 HiSilicon의 저가격 SoC들조차 모뎀을 내장하고 있으며, 이들과 호각으로 승부하려 한다면 상당히 힘든 싸움이 된다. Intel이 주로 Atom 기반 SoC의 높은 성능을 어필하는 것은, 그쪽으로밖에 승부할 수 밖에 없기 때문이라는 이면도 있다.

더 심각한 문제는, 이렇게까지해도 Intel의 SoC에는 매력이 그다지 없다는 점이다. 이 문제는 스마트폰용에서 특히 현저해진다. 이는 ARM 대 Intel의 대립이란 실제로는 성능이나 명령어셋이 아니라 생태계의 대립이며, 휴대폰용 메이커에 있어서 Intel의 생태계는 매력적이지 않다,는 점에서 이야기는 끝난다.

Intel의 생태계란, 딱잘라 적자면 Intel(과 Microsoft)의 단독 승리가 예정된 생태계다. 이는 오랜 시간에 걸쳐 Intel과 Microsoft가 높은 영업이익률을 매년 유지해온 반면, PC 벤더의 영업이익률은 몇 %에 그마저 앞부분은 저공비행했던 걸 생각해보면 이해하기 쉬울거라 생각한다. 그에 반해 ARM 생태계의 경우에는 이익의 태반은 기기 벤더의 손에 들어간다. 일단 SoC의 원가율은 대략 5% 정도,라고 생각하면 이것도 이해하기 쉬울거라 생각한다. 휴대폰 벤더에 있어 어느쪽 비즈니스가 바람직한지는 말할 필요도 없다.

하는 김에 적어두자면, 실은 성능면에서의 차이라는 건 기기 메이커에 있어 그렇게 중요한 부분은 아니다. 이 부분은 실장 방식에 따라 최종적으로 어떻게든 변하기 때문이다. 물론 10배나 100배 정도되는 성능차가 있으면 이야기는 달라지겠지만, 수십% 차이는 실제로는 최종제품에서는 큰 차이가 되지 않는다. 제품기획을 위해 독자적인 상주 소프트를 넣거나 하는 것만으로도 배터리 수명이나 성능에 영향을 끼치기 때문이다.

또, SoC의 경우 일단 정격 스펙은 있지만 실제로는 기기 벤더가 동작주파수나 구성을 자유롭게 고칠 수 있고, 실제로 상품기획에 맞춰 세세하게 변경되므로 레퍼런스 성능 그대로 나오는 일은 일단 없다. 물론 최종적으로는 성능이 엔드 유저의 조작감이라는 형태로 영향을 미치겠지만, 일반적으로 사람의 감각은 대수에 비례하는지라 10배의 성능이 나오면 대충 「2배정도 빠르다」는 감각. 수십%의 성능차라면 거의 인식하지 못하는 게 현실이다. 이런 상황에서 Intel SoC의 장점으로 드는 「높은 성능」은 그다지 차별화를 위한 무기는 되지 못하는 것이다.

물론 태블릿용으로는 나름대로 셰어를 확보하고 있지만, 이것은 「Windows 8/8.1이 움직이는 것은 현실문제로 x86밖에 없다」는 사정에 의한 것이다. Windows RT의 보급이 진행되지 않아 Windows 계의 태블릿에서는 다른 선택지가 없어져버렸다. 반대로 Android를 움직이는데 x86일 필요는 없다는 상황에는 아무런 타격을 주지 못하고 있는 것이 현실로, Windows의 힘이 미치지 않는 스마트폰 분야에서의 존재감은 여전히 굉장히 희미하다. 기댈 대상이던 Microsoft도 또 Windows Phone 부진으로 고민, 게다가 대응 플랫폼은 ARM 뿐. 기사회생책이어야했던 Tizen은 계속 늦어지고 있다. 전해듣는 말로는 2014년 2월의 MWC에서 첫 Tizen 탑재 스마트폰이 등장할 것"같다"지만, 과연 이것이 어떤 기폭제가 될 수 있을지 현시점에서는 판단하기 힘들다.

Intel이 스마트폰 분야에서 어느 정도의 셰어를 획득하기 위해서는, 우선 생태계(비즈니스 모델) 방식을 고쳐야 할 것이다. 설령 거기까지는 했다고 해도, 앞서 이야기한 Fab의 가동률 저하나 전체적인 이익률 저하라는 근본적인 문제의 해결로는 이어지기 힘들다. 그렇다고 여기서 손을 떼버린다면 추락하는 것밖에 남지않는, 굉장히 고통스러운 방향전환을 강제받는 것이 현재 Intel의 스마트폰용 SoC 비즈니스인 것이다.

x86에서 ARM으로 축을 옮긴 NVIDIA

이어서 NVIDIA다. NVIDIA가 이용하는 CPU 코어는 ARM 기반이므로, 정확하게는 기사 앞머리에 이야기한 「ARM 생태계 이외의 플레이어」라는 표현은 약간 맞지 않는다. 하지만, ARM 생태계에서는 CPU에 중심을 두는 것에 반해 NVIDIA는 GPU를 중핵에 놓고 있다는 점이 다른 생태계 파트너와 다른 점이다.

그 NVIDIA의 휴대폰/PDA용 솔루션 최초의 물건은 2003년에 발표한 「GoForce 2150」이다. 원래 이 제품은 2003년 8월에 매수한 MediaQ라는 벤더가 개발하던 휴대폰용 2D Graphics + 카메라 인터페이스의 SoC인 「MQ2100」을 기반으로 한 것으로, 아직 NVIDIA의 독자적인 색깔은 아직 없었다.

이를 이어 동사는 3D 렌더링 기술을 탑재한 「GoForce 4500/4800/5300/5500」같은 제품을 내놓는다. 이 3D 렌더링 기법은 타일 기반이라는 것 이상의 자세한 내용은 알 수 없다. NVIDIA는 2000년에 3dfx를 매수하였는데, 이 3dfx는 같은 2000년에 GigaPixel이라는 메이커를 매수한다. 이 곳은 휴대폰 등에 맞는 타일기반의 렌더링 엔진을 개발하였고, 1999년에는 MFP(MicroProcessor Forum) 회장에서 「Quake 2」의 동작 데모가 움직일 정도의 완성도였다. 최종적으로 이 GigaPixel의 기술이 어느 정도나 NVIDIA에서 이용되었는지는 알 수 없지만, GoForce 4500 등의 내부가 이것을 기반으로 했다고 해도 그다지 신기한 일은 아니다.

2003년에 발표된 GoForce 2150을 탑재한 PDA와 휴대폰


GoForce 4500 등은 타일기반의 3D 기법을 채용했다


3dfx가 매수한 GigaPixel은 타일기반의 렌더링 기법으로 Quake 2의 동작까지 실현했다.

이렇게 계속 GoForce를 제공해온 NVIDIA지만, 휴대폰에서 GPU를 외장하는 구성은 실장면적에서 불리하다는 건 말할 필요도 없다. 그래서 GoForce의 최종제품인 「GoForce 6100」에서는 애플리케이션 프로세서로 ARM 1176JZ-S 코어를 탑재하고, 나머지는 모뎀만 접속하면 스마트폰 완성,이라는 부분까지 집적도를 높였다. 이 GoForce 6100이 발표된 것은 2007년 2월의 MWC 회장이지만, 그 4개월 후에는 400MHz로 동작하는 ARM11을 탑재한 iPhone이 투입된다. 아무래도 성능면에서 나름 체감성능차가 있기도 해서, 채용사례는 그리 많지 않았다.

자, 이 무렵부터 NVIDIA를 둘러싼 환경이 조금씩 변해온다. 이 무렵에 NVIDIA는 GPU 카드 사업만이 아니라 칩셋 비즈니스에도 힘을 쏟고 있었다. GPU 카드를 사용하려면 성능이 좋은 칩셋이 필요하고, 특히 SLI 구성이라도 하게 되면 PCI Express 슬롯을 2개 쓰게 되므로, 이쪽을 타겟으로 한 칩셋은 나름 잘 팔렸다. 또 당시의 CPU는 GPU를 내장하지 않았으므로, 성능이 좋은 GPU 통합칩셋에 대한 수요도 꽤 있었다.

하지만, 여기서 흐름이 이상하게 된다. 우선 Intel과의 사이에서 버스 라이선스에 관한 교섭에 난항을 겪게 되고, 겨우 P4 버스의 라이선스를 얻어 출하할 수 있게 되자 중요한 Intel이 QPI & DMI로 CPU 인터페이스를 변경해버리고, 거기에 Intel은 이런 인터페이스의 라이선스 계약을 단호하게 거절함으로써 최신 CPU용 칩셋을 제공할 수 없게 되어버린다. 덤으로 Intel은 GPU를 CPU측에 통합하기 시작해, GPU 카드의 수요자체도 줄고 있었다.

더 극단적인 것은 AMD용으로, 마켓 셰어를 반영해서 원래 Intel용 정도의 수량을 내지 않았던데다가 2006년에 AMD가 ATI Technologies를 매수. ATI가 제공하던 칩셋을 AMD 자신이 제공하게 됨으로써, NVIDIA의 셰어는 크게 줄어들게 된다. AMD도 역시 CPU를 GPU에 통합하는 방향성을 확실히 하였기에, NVIDIA의 칩셋 사업의 앞날은 점점 알수 없게 된다. 이런 동향에 따라 NVIDIA는 2010년에 최종적으로 칩셋 사업에서 철수하게 되지만, 그 이전 타이밍에 플랫폼을 종래의 x86에서 ARM으로 전환하기로 결단한다. x86 베이스로는 출하수량이 점점 작아지리라는 것은 명백했고, 새로운 시장을 얻기 위해 ARM으로 전환하기로 결단을 내린 것이다.

이에 따라 2008년에 첫 「Tegra」를 출시한다. 원래 이 Tegra는 말하자면 GoForce 6100의 연장선상에 있는 제품으로 성능면에서 충분하다고는 할 수 없었다. 그래서 CPU 코어를 Cortex-A9으로 전환함과 동시에 듀얼코어화한 「Tegra 2」를 2010년에 투입한다. 이쪽은 Google의 Honeycomb의 레퍼런스가 되어 많은 태블릿에 채용되고, 괜찮은 출발이 되었다.

하지만 2011년 11월에 발표된 「Tegra 3」는 Google의 리드 디바이스인 「Nexus 7(2012)」에 채용되는 등 처음 평판은 나쁘지 않았지만, 점점 속도를 잃게 된다. 그 최대 이유는 CPU를 강화했음에도 GPU 코어의 성능개선이 충분하지 않았기 때문이다. 확실히 Tegra 2와 비교하면 성능은 개선되었지만, 이 무렵에는 경합하는 SoC 모두가 GPU 성능을 강화했으며, 결과적으로 GPU의 성능은 어드밴티지가 되지 않았다. 또, 태블릿에서는 어느 정도 채용예를 획득했지만, 스마트폰용의 채용예는 그리 많지 않았다. 실제로 이 당시 Tegra 3, 혹은 Texas Instruments의 「OMAP 4」를 스마트폰에 채용한 메이커의 다수가 「실은 Snapdragon을 채용하고 싶었지만 Qualcomm의 공급이 부족해서 어쩔수 없이 Snapdragon 이외를 검토할 수 밖에 없었다」는 소극적인 이유에 의한 것으로, Snapdragon의 공급이 회복되자 급속도로 쪼그라든 것은 무리도 아니었다.

또, NVIDIA도 모뎀이 없으면 이야기가 안된다는 것은 Tegra 2 세대에 이미 인식하고 있었던 듯 하지만, 당시에는 아쉽게도 모뎀 관계 기술의 축적은 전무했다. 결국 동사는 2011년에 영국의 Icera라는 베이스밴드 모뎀을 제조하는 회사를 매수. 이것을 기반으로 「Tegra 4」 세대에 겨우 모뎀을 제공할 수 있게 되었다. 그 Tegra 4는 2013년에 발표되었지만, 현재 채용사례는 동사의 레퍼런스 디자인인 Phoenix나 중국 Xiaomi 등, 극히 일부밖에 없는 상황이다. OEM 메이커에 대한 출하는 이미 개시되었기에 2014년의 MWC에서는 다른 회사에서도 나올 가능성이 있지만, 현시점에서는 상당히 난항을 겪고 있다. 이 역시 이유는 명백하여, NVIDIA 모뎀의 캐리어 인증이 전혀 끝나지 않았기 때문이다. 이 점에서 통신기기 메이커와 얽혀있는 HiSilicon이나 애초에 통신관계 비즈니스 역사가 길고, 거기에 자본력을 살린 역량으로 인증을 진행하고 있는 Intel과 달리, NVIDIA에게는 그런 경험의 축적도 엔지니어도 없고, 캐리어 인증에 그만큼 비용을 들일 수도 없다.


Tegra 4와 스마트폰용인 Tegra 4i의 개요

여기부터는 필자의 주관이지만, NVIDIA가 「Shield」나 「Tegra Note 7」같은 제품을 연이어 내놓는 것은, 일단 캐리어 인증을 따낼 때까지 스마트폰용 출하를 기대할 수 없고 스마트폰 이외의 Tegra 4의 채용사례를 늘려놓지 않으면 이도저도 못한다,는 상황에 빠졌기 때문이 아닐까 한다. 적어도 현재로서는 NVIDIA의 SoC 비즈니스가 순조로운가 묻는다면 고개를 가로저을 수 밖에 없다.

포스트 PC 시대를 향해 ARM 생태계 안에서 GPU를 판다,는 비즈니스의 큰 틀은 틀리지 않았다고 생각하지만, 거기서 IP를 파는 것이 아니라 실리콘(반도체)를 파는 것을 골랐기에 고생하게 된 것이 NVIDIA의 현재 모습이다. 그렇다면 NVIDIA도 IP판매에 매진했어야 했는가 묻는다면, ARM의 Mali나 Imagination의 PowerVR을 밀어내고 채용을 획득할만한 생태계 구축에도 역시 그만한 비용과 수고가 드는지라 어느쪽이든 가시밭길이었으리라. 지금은 괴로워하면서도 경험을 쌓아나가는 단계, 라는 것이 바른 인식일지도 모른다.

참고로 NVIDIA가 이 시장에서 철수할 기척은 없으며, 차세대 코어로 「Logan」, 차차세대 코어로 「Parker」를 각자 개발중이다. 특히 「Parker」는 동사가 ARM v8의 라이선스를 받아 자사에서 아키텍처부터 설계한 「Denver」코어를 기반으로 하고 있는 모양이다. 과제는 마찬가지로 ARM v8 아키텍처 라이선스를 받은 Broadcom이나 APM, Apple같은 기업과 달리, 자사에서 CPU 아키텍처를 설계한 적도 없으며 공식적으로 그런 회사를 매수하지도 않았다는 것이다. 소문으로는 2009년 쯤에 실리콘 밸리에서 CPU 설계자를 널리 채용하여, x86 설계팀 1개팀 분을 손에 넣었다는 보도가 흐른 적은 있다. 이것이 사실이라면 개발 리소스는 있다고 할 수 있지만, 이 부분은 명확하지 않다. NVIDIA의 SoC 비즈니스도 Intel과 마찬가지로 괴로워하면서도 계속하고 있다고 하는 것이 정확한 표현이 아닐까.


NVIDIA SoC의 로드맵

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

Android Qualcomm Snapdragon 800 MSM8974 Krait 400의 속도

(원문 : Android Qualcomm Snapdragon 800 MSM8974 Krait 400 の速度)

CPU 벤치에 Snapdragon 800 MSM8974 Krait 400의 결과를 추가했습니다.

부동소수점 연산명령별 실행속도

                (1)      (2)      (3)      (4)       (5)      (6)      (7)
               Nexus7   iPad4    HTL21   Nexus10  iPhone5s iPhone5s KindleHDX7
              Cortex-A9 Swift    Krait  Cortex-A15 Cyclone  Cyclone   Krait4
               Tegra3    A6X    APQ8064  Exynos5D   A7 32    A7 64   MSM8974
               1.2GHz   1.4GHz   1.5GHz   1.7GHz    1.3GHz   1.3GHz   2.2GHz
------------------------------------------------------------------------------
a:m44 vmla_AQ  3.959    1.204    1.337    0.619     0.700    -----    0.661
b:m44 vmla_BQ  2.002    1.266    0.931    0.569     0.670    -----    0.542
c:m44 vmla_AD  3.980    1.554    1.889    0.557     0.649    -----    0.888
d:m44 vmla_BD  2.003    1.238    1.532    0.568     0.745    -----    0.768
A:m44 vfma_AQ  -----    1.519    1.882    0.746     0.707    0.692    1.178
B:m44 vfma_BQ  -----    1.484    0.695    0.840     0.699    0.696    0.463
e:fadds     A  3.343    2.878    2.774    2.383     3.551    1.043    1.864
f:fmuls     A  3.337    2.953    2.747    2.369     3.475    1.548    1.867
g:fmacs     A  3.337    5.757    5.574    2.956     3.480    -----    2.052
h:vfma.f32  A  -----    5.756    2.747    2.957     3.480    3.185    1.864
i:vadd.f32 DA  3.426    2.877    2.762    1.183     1.031    1.031    1.866
j:vmul.f32 DA  3.421    2.950    2.746    1.478     1.545    1.545    1.864
k:vmla.f32 DA  3.792    2.951    5.604    1.480     1.567    -----    2.051
o:vfma.f32 DA  -----    2.494    2.833    1.479     1.574    1.753    1.871
l:vadd.f32 QA  6.688    2.878    2.801    2.365     1.031    1.039    1.872
m:vmul.f32 QA  6.681    2.952    2.761    2.364     1.548    1.548    1.879
n:vmla.f32 QA  6.681    2.950    5.606    2.367     1.574    -----    2.059
N:vfma.f32 QA  -----    -----    -----    -----     -----    1.696    -----
p:fadds     B  3.347    5.756    3.467    2.956     6.953    3.663    -----
q:fmuls     B  4.195    5.756    3.556    3.558     6.652    3.296    -----
r:fmacs     B  6.688   11.514    6.298    5.912     9.867    -----    -----
s:vfma.f32  B  -----   11.513    3.430    5.910     9.859    3.292    -----
t:vadd.f32 DB  3.421    2.881    3.529    2.958     3.663    3.643    1.865
u:vmul.f32 DB  3.422    2.949    3.447    2.364     3.114    3.289    2.339
v:vmla.f32 DB  7.561    5.755    6.293    4.728     6.185    -----    3.773
z:vfma.f32 DB  -----    5.755    3.437    4.730     6.188    6.237    2.340
w:vadd.f32 QB  6.705    2.879    3.457    2.961     3.659    3.641    1.875
x:vmul.f32 QB  6.683    2.950    3.428    2.363     3.101    3.276    2.340
y:vmla.f32 QB  7.532    5.759    6.372    4.729     6.199    -----    3.746
Y:vfma.f32 QB  -----    -----    -----    -----     -----    6.226    -----

・↑수치는 실행시간(초). 수치가 작을수록 고속. single thread
・모두 단정밀도 32bit float 연산입니다.

Krait 400은 동작 clock이 높은 것도 있고 해서 상당히 빠릅니다. 위 결과에서는 같은 ARMv7A VFPv4 세대인 Cortex-A15에 필적하며, 실행효율의 차를 동작 클럭이 충분히 보충해주고 있음을 알 수 있습니다.

또 여기서 Quad core는 Cortex-A9, Krait, Krait 400 뿐이므로, 종합적인 퍼포먼스로는 고클럭이자 Quad core인 Krait 400이 가장 점수가 높으리란 것을 예상할 수 있습니다.

NEON 명령은 64bit와 128bit의 차이가 없으며, Cortex-A15과 달리 128bit 단위입니다.

vfma (FMA)보다도 vmla가 2배 느렸던 그냥 Krait (3)과 비교하여, Krait 400 (7)에서는 vmla도 vfma에 가까운 속도를 내고 있습니다. 같은 Krait라도 다른 경향을 보여주며, 여러가지로 개량된 듯 합니다.

동시에 A7 Cyclone의 core 1개의 성능이 굉장히 높다는 것을 새삼 느끼게 됩니다. A7 Cyclone의 결과는 2개 있는데, (5)는 ARMv8 AArch32 (armv7) 32bit 모드의 결과고, (6)는 ARMv8 AArch64 (arm64) 64bit 모드에서의 결과입니다.

이하는 테스트 단말에 대한 자세한 사양입니다.

device                     OS   SoC      CPU core     clock  Arch        VFP
----------------------------------------------------------------------------
(1)ASUS Nexus 7 (2012)     A4.2 Tegra 3  Cortex-A9 x4 1.2GHz ARMv7A 32bit v3
(2)Apple iPad 4            i6.1 A6X      Swift     x2 1.4GHz ARMv7A 32bit v4
(3)HTC J butterfly HTL21   A4.1 APQ8064  Krait     x4 1.5GHz ARMv7A 32bit v4
(4)Samsung Nexus 10        A4.2 Exynos5D Cortex-A15x2 1.7GHz ARMv7A 32bit v4
(5)Apple iPhone 5s         i7.0 A7       Cyclone   x2 1.3GHz ARMv8A 32bit v4
(6)Apple iPhone 5s         i7.0 A7       Cyclone   x2 1.3GHz ARMv8A 64bit Ad
(7)Amazon Kindle Fire HDX7 A4.2 MSM8974  Krait 400 x4 2.2GHz ARMv7A 32bit v4

아래는 또 하나의 CPU 벤치 결과입니다.

  SoC CPU              clock  compiler  arch   time  MB/s   MBS/GHz
-------------------------------------------------------------------
1.A7 Cyclone + AES     1.3GHz clang 5.0 arm64  0.129 837.54  644.26
2.A7 Cyclone           1.3GHz clang 5.0 arm64  1.04  104.27   80.21
3.A7 Cyclone           1.3GHz clang 5.0 armv7  1.16   93.04   71.57
4.MSM8974 Krait 400    2.2GHz gcc 4.8   armv7  1.41   76.67   34.85
5.Exynos 5D Cortex-A15 1.7GHz gcc 4.6   armv7  1.49   72.61   42.71
6.A6X Swift            1.4GHz clang 4.2 armv7  1.75   61.82   44.16
7.APQ8064 Krait        1.5GHz gcc 4.6   armv7  2.28   47.64   31.82
8.Tegra3 Cortex-A9     1.3GHz gcc 4.4.3 armv7  3.00   36.15   25.82

・time 단위는 초
・MB/s 가 클수록 고속
・MBS/GHz = 1GHz당 처리속도

전용명령을 사용하는 1.이 자릿수가 하나 높을 정도로 빠른 것은 당연합니다만, 64bit 아키텍터의 A7도 충분히 빠릅니다. 신 core + 클럭수가 가장 빠른 Krait 400은 그 뒤를 잇습니다. 상세한 테스트 내용은 이쪽을 참조하시길.

테스트에 사용한 Kindle Fire HDX 7의 데이터는 아래에도 추가했습니다.

관련 글

+ Recent posts