FC2ブログ

鈴の音情報局blog

携帯関連の将来や最新の技術情報や業界の行く末などを適当に綴るblogです。 内容の信憑性は?余り信じない方がいいと思います。
本家の鈴の音情報局はこちら→http://suzunone.0g0.jp:8800/
スマホ・携帯端末アクセス[ランキング][アクセスシェア(グラフ)] (毎年10/1にログをクリア)

Google I/O 2014を6月25日~26日に開催 &勢いに任せて書くARMアーキテクチャ関連

「Google I/O 2014」を6月25日~26日に開催─新OSや新Nexusを発表か ~ リンゲルブルーメン
Google I/O 2014の開催日程が6月25日~26日の2日間に決定したとGoogleのAndroid部門リーダーのサンダーピチャイ氏が明らかにしました。

今年のGoogle I/Oは6月25日~26日に開催されると発表されました。

アップルの場合はWWDCで新iOSを発表しますが、Googleの場合はこの
Google I/Oでその年に出る新しいものを発表します。
もしかするとAndroid 5.xの発表が有るかもしれません。
次は"L"で始まるスイーツの名前が予想されていますが、
何になるのかはまだ不明です。

前回Key Lime Pieがお流れになったので、Keyを外して「Lime Pie」
がAndroid 5.xのコードネームになる可能性が高そうに私は予想して
いますが・・・。他に何か"L"で始まるものって有りますかね?

5.xは恐らくART VMの本格的な採用が有り、アプリの高速化に乗り出す
と思われます。


リンゲルブルーメン氏の所で紹介されていたDalvikとARTの比較動画を参考にしてみたいと思います。

Google Nexus 5 - Dalvik vs ART


この動画の最後にGeekbench 3でベンチマークを取っています。
その画面をキャプチャして、グラフの比率が合うように細工してみました。


その数字がDalvikが9703、ARTが12700です。
詳細はグラフを目読みしてみました。(かなりいい加減です)
青=CPU  Dalvik:4000 /ART:7800 [1.95倍]
赤=メモリ Dalvik:3500 /ART:2500 [0.71倍]
緑=I/O  Dalvik:1800 /ART:2000 [1.11倍]
黄=グラフ Dalvik:400/ART:400 [1.00倍]

画面が歪んでるし、適当な目読みなのでかなり不正確ですが、
ほぼCPU以外は速くならないという結果に。
しかしCPUは倍近い速度になっているという事のようです。
Geekbench 3の方ではほとんど実行結果が同じ数字なので、何とも言い難い
部分もありますが、グラフを載せているQuadrantの方は、CPUの速度が倍に
なっているので、やはり特定の状況ではかなりの高速化が期待できると思います。
ARTの方がメモリの速度が落ちているのは、恐らくJITとの最適化の手法の違い
など、まだARTの最適化がこなれていない部分が有るのでしょう。
徐々にARTの最適化が進められるので、この項目も速度アップがなされると思います。

私はこの辺りの事まで全てを含んだ新Androidの発表が、次のGoogle I/Oで
されると考えており、とても期待しています。


β版のARTでもDalvikのほぼ倍の実行速度を実現できており、正式版では更に
最適化が進められるのではと期待がかかります。

Googleは以前高速化関連の会社を買収していましたが、もしかすると、このARTの
心臓部の最適化をそのチームに託している可能性も考えられます。
ARTのように事前コンパイルが許される場合、より強力な最適化をする事が
可能になります。



偶然ツイッターで32bitと64bitの談義が有ったので拾っておきます。


このやり取りの中で行われていた討論で以下の記事が紹介されていました。
【年末特別座談会】後藤、笠原、山田のライター3氏が今年のあれやこれを本音で斬る ~ PC Watch
【司会】さきほど64bitの話も出ましたが、現時点でその恩恵はあります?
後藤弘茂氏
【後藤】みんなすごい誤解していて、ARMの64bitがほかのCPUの64bitと違うって事を全然考えてない。ARMはともかく32bitの出来がひどい。何がひどいか? RISCなのに汎用レジスタが16本しかない、その内の3本はプログラム関連で使っちゃうので、汎用に使えるのはたった13本。これで、ロード/ストアアーキテクチャのハンドリングをしなきゃならない。そうするとコンパイラが効率的なコードを吐けない。ので、コードステップが非常に長くなる。一方64bitになると汎用レジスタが31本、SIMDメディアレジスタが32本だから、コンパイラがものすごく効率的なコードを吐けるようになる。

【山田】つまり今のARMの32bitはひどいと。

【後藤】ひどい。だって、僕の知り合いでネイティブARM 32bitに触れた人は皆「変態命令セット」って言ってるし(笑)。

【山田】じゃ、なんでここまではやったんだろう?

【後藤】しょうがないから(笑)。そういうひどいことがなくなるのが64bitのARMv8。だから、コーディングも最適化も楽になるし、コンパイラも速くなるし、全体的に高速化できる。

【山田】で、今までのノウハウは活かせると?

【後藤】ただ、デコーダが違う。

【山田】そこはコンパイラが面倒見るんでしょ?

【後藤】そう。だけど、開発者が最適化のために苦労しなくて良くなる。例えばARM 32bitの場合は、シフト・演算と並べると速くなるとか、変な最適化がいっぱいある。後は割り算命令使っちゃダメだとか。だってCortex-A9までは割り算演算器がなかったから。何それ!? 一体いつのCPU? って感じでしょ?(笑)。

「(ARMの32bitだと)汎用に使えるのはたった13本」という事をいっていますが、
例えばインテルアーキテクチャの32bitではEAX,EBX,ECX,EDX,ESI,EDI,EBP,ESPで8本、
しかし実際にはEBPやESPはスタックやスタックフレーム等に使うので、実際に自由に
使えるのは6本。

幾ら86系はCISCだと言ってもちょっとした作業のプログラムを書くと、レジスタ
だけで完結する事は余りない。結局ESIやEDIレジスタでソースとレスティネーションを
指定したり、汎用レジスタなどでアドレッシングモードを駆使してメモリ参照の計算
を書くのが普通です。

それが13本になればかなり楽になりますし、ARMv7の32bitアーキテクチャは、RISC CPUと
しては豊富なアドレッシングモードを持っており、13本のレジスタでもそうそう困る
ような事はないと思います。

86系の汎用レジスタは、32bitが実質6本、64bit系が14本である事を考えると、ARMv7の
13本は少なすぎて変態すぎるなんて事は有りません。そりゃ科学技術計算とか、
複雑な演算の専用機にするなら別でしょう、しかし私がアセンブラで組んできた経験から
すれば、それだけあれば「とんでもなく非効率なコードしか吐けない」なんてのは
言語道断の発言です。(変態で言ったら86系の方がよっぽど変態じゃ!!)

複雑な科学技術的な計算とかを行うならそれでも足りないって事は多々あると思います。
またゲームで3Dの演算や重力計算を行うと足りないって事も有るでしょう。
でも最近はそういう事はGPUにさせる方向ですからね。しかもマルチコアでしょ。
レジスタ数をやみくもに増やすよりもレジスタ数を減らしてその分コア数を稼いだ方が
速いって考え方もあると思いますよ。

そういうひどいことがなくなるのが64bitのARMv8。だから、コーディングも最適化も楽になるし、コンパイラも速くなるし、全体的に高速化できる。

これって嘘だとは言いませんが、実際のコードはレジスタは余りまくっています。
下手にレジスタが増えると、メソッドやプロパティーを呼び出し時にレジスタを
全退避(push/pop)したり、スレッド切り替えが走ってもレジスタの全退避、(つまり
メモリアクセス)がかかるので、逆にオーバーヘッドが大きくなり、
遅くなる可能性も十分あります。

元々この辺りの余分なものをとことん削って簡素化して高速化したものがRISCなわけで、
より複雑化、肥大化したものはRISCの範疇から逸脱しているのですよ。

例えばARM 32bitの場合は、シフト・演算と並べると速くなるとか、変な最適化がいっぱいある。後は割り算命令使っちゃダメだとか。だってCortex-A9までは割り算演算器がなかったから。何それ!? 一体いつのCPU? って感じでしょ?(笑)。

すみませんね、「変な最適化」で。
やってましたよ、2倍にするにはshl eax,1とか、4で割るにはshr edx,2とか。
Z80なんかだと最速のレジスタの0クリアはxor aですからね。

割り算が二事にも突っ込んでいますが、勿論昔のZ80にも割り算は有りませんでした。
それをループ構造で、割り算を作るのは普通のプログラミングの作業で、私も
自前の汎用の16bit割り算ルーチンを持っていました。

例えばMSXturboRにZ80カスタムのR800なんてプロセッサが乗りましたが、
これには16bit割り算の命令が有りました。
R800を認識して割り算命令を自動で使うようにしましたが、実際には
全くその効果を体感できませんでした。よっぽど高速ループ内でそういった
ものを恐ろしい程の回数使わないと差が出ないものなんですよ。

CPUクロックが4MHzや8MHzの時代ですらそうだったのですから、今だったら
もっと差が分からなくなっていますよ。



関係ないCPU語りをしましたが、今の64bitやARMv8信仰の厚さにかなり疑問を
持っていたので、そのストレスを関係のないGoogle I/Oの記事で発散させて
頂きました。

はっきり言って、命令セットやアドレッシングモード、レジスタの少なさで
安易に有利不利を論じるのはバカげていると私は感じています。
当時一番汚いデザインでクソミソに言われた86系のCPUが結局何十年と
生き残り、しかもARMプロセッサと比べても高速とされていますが、
32bitでは8本、ユーザーレベルでは6本しか使えませんし、数十年前から
レジスタは少ないからクソと言われてきました。

Z80なんてA B C D H L と6つの8bitのレジスタが有るだけですよ。
これで16bitどこか、32bitの演算もこなしていました。

ファミコンに採用された6502なんて、A X Yの3つの8bitレジスタしかないの
ですよ。それでもグラディウスはぐわんぐわん気持ち良く動きましたし、
マリオは所狭しと駆け巡りました。

アウトプットの出来栄えはCPUのアーキテクチャではなく、プログラマの腕
といまだに信じている人なので、こういったハードウエア本意で全てを
語ろうとする論調には猛反発する私がいます。

昔は、特にファミコンの6502CPUでは「プログラマの腕が02の性能」と言われた
だけあって、作り手によって本当に大きな差が出ました。


実はiPhone 5sでA7が64bit化された時、1GBしかメモリを積まれなかった事が
ものすごく64bitを愚弄された気になって憤慨したものです。上記の対談で後藤氏が
命令セットに関して踏み込んでいますが、そんなもの効き目が出る所なんて、相当
特殊な事をするか、ベンチマークでループさせまくるかしないと差が見えない所です。

端末の速い遅いを決める9割5分はメモリアクセスを含む多種多様なIOが握って
います。そんな状況で命令セットが優れていたら速いですよと理論値の話を
体感レベルに思える語り方をしていたのがとても残念です。
彼の記事は今までもとても参考になっていて、これからもお世話になる事が
多いと思っているだけに。


Google I/Oの記事なのに完全に趣味に走った内容になりました。
これがこのブログの味です。

多分(笑)
関連記事
  1. 2014/02/20(木) 19:51:09|
  2. 携帯
  3. | トラックバック:0
  4. | コメント:2
<<色々有るんだけどソチ・フィギュア女子SPの採点について | ホーム | GalaxyS5は安く値段を設定?GalaxyGear2はTIZEN版も有り?KitKatアップは14機種のGalaxyに>>

コメント

比較対象

x86-64系は一応CSICだってのをわすれてませんか?
ARM系は一応RISCだってのをわすれてませんか?

64bitのRISCをARMから出てきたので
比較対象は旧DECのalphaとかMIPSとかIBMのPowerとか
なのでしょう

変態命令セットでもなんとかなるのはintelとAMDが証明しています…
でも素直な命令セットのほうが最適化が楽なのも、あっていると思う
  1. URL |
  2. 2014/02/21(金) 16:04:22 |
  3. 姫 #Qgp/yXvw
  4. [ 編集]

RISCの意義

RISCの意義は
メモリアクセスと演算の分離にあるので
予め必要なデータをレジスタにどんどん読み込んでおいて
読み込みの終わってるレジスタで速く演算して
後からメモリに書き戻す
というレジスタを贅沢に使うことで
アウトオブオーダー型処理で速く演算しよう
というものだと思うのですけど…

x86だって内部ではRISC的に命令変換してたくさんの内部レジスタを使ってるわけで
スレッド切り替えでレジスタ全退避なんて(内部的には)今ではしてない気もします…

ということはARMv7がx86みたいな内部変換をしていない頃にv8が出てくれば高速化したのかもしれません
しかし、内部変換しているのなら、v8になってもあまり高速化しないでしょうね、
それはx86-64になってもあまり高速化してないのと同じということで…

なので
ARMにしてもx86にしても
64bit化の効果はメモリサイズの拡大にあると
あたしはおもています
  1. URL |
  2. 2014/02/21(金) 16:28:37 |
  3. 姫 #Qgp/yXvw
  4. [ 編集]

コメントの投稿(投稿時には必ず何らかの名前を付けてください)


管理者にだけ表示を許可する

(名前を入れないとクリックできません)

トラックバック

トラックバックURLはこちら
http://suzunonejh.blog15.fc2.com/tb.php/4498-494df2c8
この記事にトラックバックする(FC2ブログユーザー)

最近の記事

機能リンク

最近のコメント

カテゴリー

ブログ内検索

ブログリンク

RSSフィード

QRコード

QR

月別アーカイブ



メールフォーム

お問い合わせ・ご質問はこちらから。

名前:
メール:
件名:
本文:

suzunone.m(あっと)gmail.com に
直メでもOKです。