FC2ブログ

鈴の音情報局blog

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

現状のスマホで64bitプロセッサは必要か?

iPhone 5sがA7 64bitプロセッサを積んできた事で、今まで全くと言っていい程
話題に上がらなかった、スマホ上での64bitプロセッサの議論が話題として
上がるようになってきました。

技術の正常進化と言えばそれまでなのですが、現状のスマートホンで64bitプロセッサ
を搭載する事の意義なども含めて考えていきたいと思います。


32bitプロセッサと64bitプロセッサがスマホ上で動く場合の最大のメリットは、
メモリ空間の広さ。本当にこれに尽きると思います。
少なくとも私は現状でほぼ唯一と言っていいメリットが、このメモリ空間の
広さだと考えています。


■iPhoneの発表を受けて

私がアップルの発表に対して違和感を覚えたのは「64bitだから速い」という
ような発表の仕方をしていた事。その発表を受けて「違うだろ!なんだ
その詐欺的な発言は」って感じてしまいました。

64bitプロセッサを搭載するという事を発表する事は技術的には非常に興味深く
興奮する出来事です。しかしその発表の仕方次第では懐疑的な視点を
向けざるを得なくもなります。それが今回のアップルの発表の仕方でした。

メモリ空間の事を押すのではなく、動作速度の事を押してきましたからね。
それでは勘違いを生むのみです。


■Androidではどうなる?

ではAndroidではどうか。

そもそもAppleはプロセッサ界が描いていたロードマップを大いに無視した
タイミングで64bitの発表をしたので、Android勢は不意打ちを食らった形になり、
全く準備は整っていません。

恐らく64bit化は予定では来年の後半だったと思われますので、メモリや周辺
デバイス、そしてSoC自体も全て来年後半に向けての計画を今前倒しに練って
いる所だと思います。

これが足並みが揃ってAndroid端末に載りました。
さあAndroidはどうなるでしょう?

どうにもなりません。
だってDalvik VM上で動いている仮想マシンなので、物理プロセッサと
仮想マシンは完全に切り離されています。

つまり、32bitプロセッサ上で64bit仮想マシンを動作させる事も可能です。
Googleがその気なら、今の32bit CPUの端末も全て64bit Androidマシンに
変える事が出来るのです。

仮にAndroid 5.0が64bit Dalvik VMの載せて登場するとしましょう。
するとAndroid 5.0が動く全てのAndroid端末は64bit化した端末になると
いう事です。例えCPUが32bitでも、16bitでも、仮想マシンが動く限り、
どんなCPUの上で動作していても64bitのアプリケーションを動作させる
事が出来ます。これが仮想マシンで動いているAndroid OSの特徴です。

iPhoneならば32bitと64bitに対応するアプリはそれぞれのコードをアプリに
入れておく必要が有ります。アプリがハードに合わせる感じ。

Androidは逆です。アプリにハードウエアが適応していく。
だからアプリ側はハードウエアの変化を気にする必要が有りません。

ではAndroid 5.0のDalvik VMは64bitに対応するのか?
私はしないと思います。
というかその必要性を感じません。

仮想マシンを64bit化させると確実にアプリの実行速度が落ちます。
理由はコードの読み込み・実行が全て64bit単位で読み込まれ、同じキャッシュ
容量・メモリ転送速度では32bitの倍以上の時間がかかることになります。

しかも0と1の1bitしか使わないフラグでも常に64bitの読み書きが起こり、
1~10しか使わないような4bitで間に合う数値領域でも常に64bitの読み書き
がやはり強制的に行われ、動作の99%以上がこうした「無駄」に費やされる
事になります。

私がこれを強く言えるし、気にしているのは、元々アセンブラを書きまくって
いた人間だからです。8~32bitまで、様々なプログラムを書いて来ました。

演算自体では8bitでは手狭。
16bitで大半の演算が間に合うようになるも、メモリ空間がやはり手狭。
32bitでメモリ空間に不満は無くなりました。
単品アプリレベルでは。

今はもうアセンブラは組みませんが、今でもそれ程大きく状況に変化はないでしょう。
OSで1GBを食い、1つのアプリで1GBを食い、アプリが4つ5つマルチタスクで走ると
いう環境を想定した場合、アプリは32bitのまま物理CPUは64bit化するという
道が考えられます。私はそれがAndroidでは一番効率のいいOSの進化だと思います。

ほとんど使われない仮想環境の拡張をするのではなく、複数の仮想環境を実行させる
物理環境の増強する。一番無駄のない形ですね。

但しAndroid NDKでJNI等というネイティブコード系の処理も有るので、単純に
そこだけで収まる話でもないので、実際にはもうちょっとややこしい話になるの
ですけどね。突っ込みだすとややこしいことはみな割愛。


将来、Dalvik VMが64bit化することは有るのか?
いずれは有るかも知れませんね。
でも余りメリットが無いんですよね。
32bit空間で足りないアプリが登場するって所が余り想像できないんですよ。
なのでAndroid 7.xや8.x等の時代にならないとDalvik VMは64bitに置き換わらないかも?
それぐらい、一つのアプリ単位では32bitという単位はバランスがよく、
それ以上の環境もまず必要にならないレベルのいい環境と言えます。


■64bit化した時の内部的な動作を考える

64bit化されたプロセッサはどう動作するのか、考えてみましょう。
今迄メモリから32bit単位で一命令をフェッチ(読み込み)して解析・理解・
実行をしていました。それが64bit単位になるので、命令コードの読み込み量が
クロック単位で倍になり、同じキャッシュ容量なら、キャッシュテーブルの
数が半減する事になります。(=実行コードのキャッシュのミスヒットの
確率が極端に増える)

またキャッシュテーブルを同じだけ用意しようと思えば倍のキャッシュ容量が
必要になり、キャッシュとメインRAM間の転送速度が倍になった場合、
始めて32bitと同じ性能となることになります。

この命令コードの読み込みやキャッシュヒット率は非常にパフォーマンスに
影響します。プロセッサのアーキテクチャが32bitから64bit化する事の
デメリットはまずここから始まることになります。

他にも追いかければ同様の問題が幾らでも見えてきます。
例えばレースカーでは、ある程度の排気量以上のエンジンを搭載しても
有利になるとは言えないラインが出てきます。重量や大きさと、
パフォーマンスのバランス、ボディーサイズや重量バランスの問題が有り、
直線だけなら有利ですが、コーナーの多いサーキットではその重さや大きさ
で有利になるとは限らない場面が出てくるのです。それと似ています。


Android端末がそう簡単に64bit化しないのは、キャッシュやメモリの転送バス
辺りの環境が64bitプロセッサを待たせずに満足に動作させられる程、完璧に
揃い切っていないので業界全体がプロセッサ周辺のバランスが崩れる事を
恐れているからだと思います。

実績のある32bit環境なら、多少の無茶は利きますし、多少の無茶も出来る
ぐらい各ベンダーも実績と経験を積んでいるでしょう。

ARMから64bitのコアが去年に発表されましたが、今の段階でも争って登場
しないのはこの辺りのバランスにまだ不安が有る事。32bitの熟成が余りに
進んでいて、完成度が高いことが理由として有ると思います。


ではそれらのように64bitによる実行環境を整えることの困難さを押しても
なお64bit化をして、メモリ空間の拡張以外に得られるメリットは何が
有るかを考えていきます。

64bit化をする事で、クロックあたりの計算が速くなることは有りません。
その代りクロック単位に計算できる桁数が飛躍的に増えます。
2^32(2の32乗)で約43億という数字まで最短1クロックでに計算が出来ます。
これが2^64(2の64乗)で約43億の32乗という、もう訳の分からない数字まで
計算が出来る事になります。

貴方の身の回りや、各種計算で43億以上の結果を必要とするようなも
のって有りますでしょうか?少なくとも私はすぐには思いつきません。

つまり通常の計算で43億以上の計算結果を必要とするものを高速化する
64bit化は殆ど必要とされておらず、また1アプリで4GB以上のメモリも
必要とされるケースは相当特殊です。

Dalvik VMを64bit化する意味は近近にはほとんどないと私が主張する理由に
なっています。iPhoneも同様です。

64bit化してすぐにメリットが有るとすれば科学技術計算の分野です。
浮動小数点の演算の場合、桁数がどれだけ大きいかという事は、
小数点以下の精度が上げられるという事になり、高い精度は非常に
メリットが大きいです。

しかし、これは逆の意味で時代錯誤で、浮動小数点の科学技術計算の世界では
64bitはとうの昔から当たり前のものです。64bitが倍精度としてもてはやされて
いたのはもう20年以上前の話で、CPUが16bitが主流で、32bitが出るかどうかの頃
から80bitの拡張倍精度で浮動小数演算が行われるプロセッサも有ったぐらいです。

浮動小数の演算は、精度の関係で昔からビット幅が必須だったのです。
64bitの倍精度は当たり前でアップルがもしそれを売りにしようとして
いるのならば「何をいまさら」と思いますし、今販売されているAndroidの大半と、
A6を積むiPhone 5も対応しているものを新たに売りにするのもおかしな話です。
ちなみに今は128bitという四倍精度というものも存在します。

では重い画像処理だとbit幅やバス幅の広さは意味が有るのではないでしょうか。
これは正しいと思います。限定された条件に於いてですが。
画像処理は8bitや16bit、32bitという単位で扱う事がよく有り、特に32bitの
VRAM構成を行っているフレームバッファが今は一番多いと思います。

これに対して64bitレジスタなら1アクセスで2ドット分のアクセスを一気にこなせます。
しかし処理をする場合1ドット単位でしかできない事もよく有るので、
メモリから2ドット分読みだして、わざわざ1ドット単位に分割して
処理をする事も珍しくありません。

単純に読みだして処理をせずに別の場所に書き込む(つまり単純な転送)だと
64bit化の威力は抜群に効き目が有ります。「限られた」というのはそういう事
なんですよね。しかもこれはメインRAM内での転送に限られます。

フレームバッファ内だとGPUにお任せしてしまうので、一旦表に
出した画像を扱う分には64bit化はあまり意味が無いんです。


しかしアップルは64bitプロセッサのA7で速度が2倍になったと言っています。
上記のように、64bitプロセッサになったからと言って特に高速化することは
有りません。この言葉をしっかり分解して理解する必要が有ります。

「64bitプロセッサになったA7は、64bitになった事とは関係なく、
 プロセッサ内部の最適化等、様々な工夫をしたりして2倍の速度を実現した」

が正しい理解ではないかなと私は思っています。
ARMv8アーキテクチャのサポートとというのは単なるニーモニック命令セットが
64bit対応されただけの話であり、ARMv7だと遅い、ARMv8だと速いということ
にはなりません。

64bit化をしたならば、64bitのフェッチ・デコード・実行を滞りなく進められる
環境を32bitプロセッサ並に可能になるように整えた上で、様々な高速化を
倍のバス幅で可能にする必要が有ります。

これはものすごく大変な事ですが、それを32bitプロセッサに同じだけの力を
費やしていれば、もっといいものが出来ていた可能性は否めません。


■まとめ

上記のようにAndroidとiPhoneでそれぞれ64bit環境という事に対する立場が
変わるのですが、どちらでも変わらないのは

・64bit化の最大のメリットはメモリ空間が広がる事
・1つのアプリで32bitのメモリ空間を超えるなんて通常はまず有り得ない
・64bit化自体のみで速度が速くなることはまず有り得ない。
・64bitプロセッサを高速に動かすにはキャッシュやバス・メモリ環境が整う必要が有る。
・43億以上の計算結果を得る演算以外では32bit以上のCPUは特に高速になるわけではない。
・浮動小数点の計算では64bit(倍精度)は既にポピュラーなものになっている。

こういう事じゃないかと私は考えています。

浮動小数点の演算では64bitの倍精度がポピュラーということですが、これは
ARMアーキテクチャのVFPv4が既にサポートしており、Cortex-A5, A7, A15,
Snapdragon Krait等で既にサポート済みだったので、新たにA7プロセッサの
強みとなるわけでは有りません。それどころか、倍精度はA6プロセッサでも
既に対応済みで、VFPv4が新たにサポートされたわけでもなく、以前から
64bit倍精度の浮動小数点演算はハードウエアでサポートされていました。


なので、この微妙に周辺の環境が整い切っていない環境で、iPhone5sに64bit
プロセッサをわざわざ載せたのは「速度的にはほぼメリットは無いけれど、
話題作りには有効だと判断をして、実効性能的には特に有利ではない64bit
プロセッサを売りにする為に載せた。」と判断しています。


私はハード屋ではないので、ハードのもっと細かい所にまで突っ込めないのは
悔しい所ですが、アセンブラや機械語レベルなら手と脳みそに16進コードや2bitの
模様が体の奥底まで染込んでいるのでこのレベルなら幾らでも突っ込めます。

その人間の目から見ても、今回のiPhone5sの64bit化は、「4GB以上RAMが載って
いないならば意味の無いこと」であり、仮にキャッシュメモリや転送バスが
倍の速度になっていないならば、「ケースによってはiPhone5/5cよりも
iPhone5sが遅い場面が有ってもおかしくない」と考えています。

例えば10000ccのエンジンを積んでいると言ってもダンプカーが僅か1300ccの
ビッツよりも速いとかいう人はいないですよね。適材適所、合う合わないが
用途によって必ず有るので、そこをきっちり見ていかないと、数字に騙されて
しまう事になってしまいます。
関連記事
  1. 2013/09/17(火) 19:55:21|
  2. 携帯
  3. | トラックバック:0
  4. | コメント:23
<<ドコモはiPhoneを売りたがっていない?意外なディスプレイの謎 | ホーム | 中国電信、iPhoneの販売補助金を削減>>

コメント

誤変換の指摘

5sへの64ビットプロセッサ搭載は確かに違和感がありますね。

誤入力・誤変換に気づきましたのでお伝えします。

> 少なくとも私はほぼ有意何時と言っていいメリット…

↑冒頭の3段落目です。
「ほぼ唯一」ではないか、と。

あと、↓もう1箇所。中盤から後半にかけての一文。

> 層とは言えない状況に…
  1. URL |
  2. 2013/09/17(火) 21:26:24 |
  3. tnakam #-
  4. [ 編集]

>tnakamさん
将来性の為に64bitプロセッサを搭載する事自体はいいとして、
それを誤った売りにしてしまうのはどうかなと思うんですよね。
単なる足枷か、メリットになるかは今後明らかになるメモリの搭載量と
内蔵されているキャッシュの量次第でしょうね。

入力ミス、教えていただき有難うございます。
修正したしました。
  1. URL |
  2. 2013/09/17(火) 21:45:13 |
  3. 鈴 #GpEwlVdw
  4. [ 編集]

Appleは、MACのARM化を考えているのではないかと疑っています。
MACとiPhoneを合わせた開発費の圧縮や自社プロセッサ採用による利益率の
向上などを狙いとすると、64bit化は筋の通った判断に思えるのです。

  1. URL |
  2. 2013/09/17(火) 22:20:54 |
  3. ue #-
  4. [ 編集]

自社プロセッサにして本当に利益率が上がるでしょうか?
自社で開発費を投資しない方が良いと判断されて今のIntel Macになっていると思うんですが。

物理設計だけでなく、コントロール用ソフトウェア開発もしないといけませんし、ファウンダリに乗せるための製造プロセスの設計もしないといけません。
設計だけでもかなり大変です。

その上開発費を回収しようとすると、次期製品が出るまでの間に相当な数を売らなければなりません。
IntelやQualcommのように半導体で食っていて世界中に莫大な数を出荷しているならのならともかく、自社製品に載るだけならば相当苦しいと思いますし、パフォーマンスから考えてもiPhoneとMacのプロセッサを統一することは、iPhone用プロセッサの性能が少なくとも現行のCoreiシリーズくらいになるまでは無理かと思います。

IntelのCoreiシリーズと、モバイル用ARM系プロセッサではパフォーマンスに差がありすぎます。
iPhoneとMacのプロセッサ統一はやろうと思えばできるかもしれませんが、今の段階ではiPadに毛が生えた程度のMacしかできず、PCならではの大型コンテンツ作成用途には向かないMacになってしまいます。
それでは意味がありませんので、MacをARM化しようとしても、やはりMac用ARMプロセッサを別途開発しなければならないことになります。
  1. URL |
  2. 2013/09/17(火) 23:24:51 |
  3. GMS #3XH2/Kw.
  4. [ 編集]

さすがに無いでしょ

MacをARMで動かすのはさすがに無いと思いますよ。
さすがにCoreシリーズとでは力の差がありすぎです。
まだXserveがあったなら分かるんですが。

今回の64bit化はARMv8を使ったから自然となっちゃったってのが落ちだと思いますけど。
xnuはすでに32→64bit化を経験してますし、アプリもユニバーサルバイナリで簡単に対応できますから。
ついでだからマーケティングの材料に使ってしまおうといったところでしょ。
  1. URL |
  2. 2013/09/18(水) 00:20:06 |
  3. Tekram #LOj0rHf6
  4. [ 編集]

疑問に思っているんですが、本当に64bitで動作させるんですかね?

スナドラだって、ハードウェアの実装は128bitで、32bit4分割或いは64bit2分割で動作したとおもうんですが、A7プロセッサも同様に32bit2分割で動作させて高速化させるつもりなんじゃないかと思うんですが、どうなんでしょう。

余談ですが、64bit化のメリットとして、メモリ空間を上げる話をよく見かけますが、PlayStation2がメインメモリ32MBしかないのに128bitCPUだった事について余りふれられて居ませんね。
ゲームプログラマの友人が、CPUのビットは浮動小数点計算の為に多ければ多いほどよい。PlayStaion3が64bitCPUだなんて、なぜ性能を下げるんだと憤慨していたのを思い出します。
  1. URL |
  2. 2013/09/18(水) 01:44:22 |
  3. b #FUfi/TkY
  4. [ 編集]

bさん

CELLは128bitの浮動小数点演算ユニットを実装していますので、別にゲームを実行する上での性能が下がったわけではないと思いますよ(汗)

浮動小数点演算だけなら演算ユニットの問題なので、64bitOSに対応している必要はなく、演算ユニットの数やビット長を増やすなどすれば演算性能は向上します。
たとえば、HaswellではAVX2で256bitまで拡張されましたので、64bit×4や32bit×8とかもできるようです。

浮動小数点演算ユニットが扱えるデータ長の話ならば、とっくの昔から128bitとか256bitとか言ってるはずなので、いわゆる64bitCPUとは整数演算ユニットやメモリアドレッシングが関係しているのでは?
  1. URL |
  2. 2013/09/18(水) 09:42:19 |
  3. GMS #3XH2/Kw.
  4. [ 編集]

http://rbmen.blogspot.jp/2013/09/android-44-kitkat64bit.html

この記事もうチェックされてますか?
  1. URL |
  2. 2013/09/18(水) 11:07:27 |
  3. yokohamas #-
  4. [ 編集]

いろいろ間違っとる

>だってDalvik VM上で動いている仮想マシンなので、物理プロセッサと
>仮想マシンは完全に切り離されています。

VM=仮想マシン。仮想マシン自体はハードウェア依存です。その上で動作する
Javaアプリケーションだけが切り離されてます。

>つまり、32bitプロセッサ上で64bit仮想マシンを動作させる事も可能です。

不可能だから。本当にアセンブラやってたんですか?
64bitコードを32bit CPUで動かす技術なんて見たことありません。

>どんなCPUの上で動作していても64bitのアプリケーションを動作させる
>事が出来ます。これが仮想マシンで動いているAndroid OSの特徴です。

Android OSは、元々Linuxですよ。その上でDalvik VMが動作し、
さらにその上でJavaアプリケーションが動作します。
Javaアプリは、VMが64bit版なら64bitで動作するだけです。
  1. URL |
  2. 2013/09/18(水) 11:29:48 |
  3. 玉ねぎ #-
  4. [ 編集]

スマートフォンでは

フルHDでの処理考えると64bit化は楽になる面も多いです。まあ、普通にスマートフォン使う分には過剰な性能で端末価格の底上げにしかならないんですけどね(笑)

iPhoneというか、iPadとMacの開発環境考えると64bit化によるエコシステムは理解出来るので、Androidとは少し考え方が違いますね。
プレゼンの二倍高速化はとってつけた嘘ですよ。
それよりも、iOSには他の日本語入力環境の受け入れして欲しいですね。
  1. URL |
  2. 2013/09/18(水) 13:35:51 |
  3. MP #-
  4. [ 編集]

こういうことらしいです

http://pc.watch.impress.co.jp/docs/column/kaigai/20130918_615784.html
  1. URL |
  2. 2013/09/18(水) 15:04:38 |
  3. GMS #3XH2/Kw.
  4. [ 編集]

iPhone 5s は 1.3GHz 駆動、メモリは 1GB だそうです。
http://buzzap.jp/news/20130918-iphone5s-a7-1gb/

これで、マルチタスクの制限が緩和されるって言うのだから、ちょっと苦しいかも。
  1. URL |
  2. 2013/09/18(水) 15:30:39 |
  3. 生ぴーまん #bnistvpo
  4. [ 編集]

気になったのでチョイと。
VMは別にハード(CPUも含む)依存ってわけじゃないですよね。
そんなことを言っていたら開発用のエミュなんて存在できなくなっちゃいます...
既存のVMにハード依存しているものが多いのは用途・コストの関係です。
動作させる環境のハードを使いたい時もハード依存になりますが(^_^;)
  1. URL |
  2. 2013/09/18(水) 18:39:07 |
  3. YASU #eAb5nx9M
  4. [ 編集]

>ueさん
>Appleは、MACのARM化を考えている
それっぽい話がアップルからも有ったように思います。
ただどこまで本気の話だって微妙な気もしますけど。
その記事を書いた人の希望的観測の恐れもありますし。
その為の64bit化となると、確かに有り得ない事も無いですが、
だからと言って今64bit化するメリットを考えると微妙な気もします。
そもそもARM 32bitコードもどっちにしてもサポートを続けて
いかなくてはなりませんし。5や5cが長期に残っていくと思われますし。

>GMSさん
内製にするメリットって確かに感じられませんよね。
PCの95%のシェアを占めていて、十分開発費コストを他でペイして
貰えるインテルCPUを使うメリットは大きいですよね。
ただiPhone用にAプロセッサを開発し続けている限り、使いまわす
という意味では新たな開発費はかからないので意味の無いことでは
無いとは思いますが、色んなリスクを一つに集中させてしまう可能性も
大きいのでAプロセッサの開発が躓けば、即アップルが終わりって
事にもなり得ますよね。もしアップルが考えているなら、リスク分散の
観点からやめといた方がいいと思うのですけど・・・。
やっぱりコントロールチップの開発等も考えるとMacの販売数じゃペイ
しない可能性も有りますよね。MacOSしか動かないPCになって
しまったら魅力を感じないと思う人も出てくるでしょうし。
なんだかPowerPCの二の舞になりそうな気がします。

それと記事、有難うございます。
やっぱり一番危惧されていた落ち着くべき所に落ち着いてしまいましたね。

>Tekramさん
確かにCore-iシリーズとのパフォーマンス差も大きいですし、
モバイル向けでのIntel Bay Trailとの圧倒的なパフォーマンス差を見ても、
今インテルから離れることにメリットを感じませんよね。

>bさん
>疑問に思っているんですが、本当に64bitで動作させるんですかね?
実際にコードを書いて逆汗してコードを見ない限り、アップルの発言を信じるしかありませんから。
OS自体が64bitネイティブコード化されていると発表されたなら間違いないと思いますけど。

>GMSさん
浮動小数点演算の高精度化よりもベクトル化の方がゲームの高速化には効くかもしれませんね。
ゲームでは上流処理だけ精度を守り、案外下流処理だけわざと精度を落として高速化とかも
やっていたりしますしね。
昔から浮動小数点演算は特別扱いで多bit化は速いって事を今は余りメジャーな事では無い
のかも知れませんね。80x87等のコプロが盛んだった頃は多くの方が知っていたのですけどね。

>yokohamasさん
情報有難うございます。
この記事で書かれている64bit化ってどっちの意味でしょうね。
サムスンが記事に登場している辺り、どうもプロセッサとカーネル側の話で、
Dalvik VMの64bit化には感じられないですけど、この書き方だと
両方同時にやる可能性も無きにしも非ずですし・・・。

>玉ねぎさん
間違っていません、断じて間違っておりません。
間違っているのは貴方の指摘の方です。
ただし、私の書き方が悪く、読み手が勘違いを起こしてもおかしくないという
指摘でしたら甘んじて受け入れますが。
VMと物理プロセッサは完全に切り離されています。
極端な話、8bitや16bitプロセッサで32や64bitプロセッサもエミュレートできます。
極端に遅くなるしメモリの問題も大いにあるので作るメリットが無いのでそういう
ケースは余りありませんけどね。
大半はファミコンやPS等の古いゲーム機、古いPC等の資産を引き継ぐ為の
エミュレータという形で存在する事が多いです。それらは完全にクロス環境で、
物理CPUとVMのCPUのbit数なんて全く関係なく動作していますよ。

>不可能だから。本当にアセンブラやってたんですか?
ええ、8bit時代からそれで飯食ってましたが。
>64bitコードを32bit CPUで動かす技術なんて見たことありません。
そんなの技術っていうのですかね。
どうせターゲットCPUの中のマイクロコードやワイヤードで埋め込まれて
いる事をエミュすればいいだけの、特に難しくない事ですよ。
それと見た事が無いなら貴方の周りが贅沢な環境が揃っているだけでしょう。
割と贅沢な環境しか知らない世代の方の意見のようにしか思えませんね。
クロス環境での不可能はメモリの限界や速度の限界以外では、
開発のマンパワーと開発費の限界位しかないです。
無意味だから余り作られない事と、技術的に不可能を混同しないでください。

>Android OSは、元々Linuxですよ。その上でDalvik VMが動作し、
>さらにその上でJavaアプリケーションが動作します。
ターゲットマシン様々なコスト的にLinuxが選ばれているだけで、
極端な話DalvikVMをWindows上で動かす事も不可能ではないのですよ。
メリットが無いから行われていないだけで。
>Javaアプリは、VMが64bit版なら64bitで動作するだけです。
当り前の話です。私もそう書いていますけどね。
VMのCPU側のインターフェイスのbit数とアプリ側のbit数は自由に
設計できるんですよ。単純な事です。
私の国語力が追いついていないようで伝わらないようでしたら申し訳ない。

>MPさん
ただそのメリットが出るにはやはりメモリが有る程度欲しい所なんですよね。
浮動小数点かスカラ演算か、どの部分に多bit化が要求されるかを考えると
圧倒的に浮動小数点の多bit化が要求される事が多いので、既にそれが
行われているわけで、わざわざスカラ部分の多bit化をした今回の
64bit化って本当に効き目あるの?って思っているんです。

>生ぴーまんさん
なんだか「あちゃーっ」って感じですね。
大方の噂通りになってしまったって感じで、私の危惧がそのままビンゴして
しまっててちょっとアレです。

>YASUさん
まあ開発エミュはそれなりの実行速度が欲しいですし、あんまり無茶な
組わせはないですもんね。速度とメモリ的な理由で現実的な所でターゲットマシンの
方がプアである事の方が圧倒的に多いですし。

思うに中途半端に動作マシンとターゲットマシンのコードで依存が有るケースって
有るんですか?私が実際に動かしたり、作成したものは依存関係が無いもの
ばかりでしたけど。
  1. URL |
  2. 2013/09/18(水) 21:47:03 |
  3. 鈴 #GpEwlVdw
  4. [ 編集]

ちなみに以前紹介した、うちの知り合いが開発している旧PCのエミュ集です。
懐かしい気分に浸りたい方はどうぞ。

http://homepage3.nifty.com/takeda-toshiya/list.html
  1. URL |
  2. 2013/09/18(水) 21:49:57 |
  3. 鈴 #GpEwlVdw
  4. [ 編集]

>鈴さん

「既存の」ってのは表現が悪かったですね。
「普通の人が接する機会が多い物」って言い換えます。
普通の人が接するVM関連ってVirtualPC、VMWare、VirtalBOX等のx86仮想化環境が多いものでこれらを含めちゃうと...
クロス開発環境だと当てはまらないと思ってます。
ま、VMって言葉は適用範囲が広いので解釈は色々有るということで(^_^;)
  1. URL |
  2. 2013/09/18(水) 22:36:02 |
  3. YASU #eAb5nx9M
  4. [ 編集]

>GMSさん
GMSさんの話で思い出した事があります。
当時、PS3のコプロは128bitみたいだという話を彼にした記憶があるのですが、彼曰く、メインプロセッサが128bitでないと意味が無い、他のレジスタと同様に扱えなければ意味が無いというような主旨の話をされた記憶があります。
私には、彼の話がさっぱり理解出来なかったので、上手く説明出来ないのですが(汗
  1. URL |
  2. 2013/09/19(木) 01:18:29 |
  3. b #FUfi/TkY
  4. [ 編集]

bさん

プログラムが組みにくくなったという意味なんでしょうか?
私もソフトウェアのことはさっぱりなので(汗)

確かに、PS3はプログラマーから苦言が出ていた記憶しています。
逆に、PS4はx86互換CPUとGDDR5 8GBメモリが歓迎されているようですが。
  1. URL |
  2. 2013/09/19(木) 09:06:15 |
  3. GMS #3XH2/Kw.
  4. [ 編集]

鈴さん
>ただそのメリットが出るにはやはりメモリが有る程度欲しい所なんですよね。
命令セットの更新、レジスタの増加はメリットだと思いますがね。
ARMv8使えるならば64bit化をすすめるのは妥当だと思います。
コンパイラ次第の要素はありますが、レガシー(32bit)のみ使うよりは、無視できない程度には性能改善に寄与すると推察します。x86の64bit化もそうでしたし。
  1. URL |
  2. 2013/09/22(日) 23:47:50 |
  3. Thiotimoline #-
  4. [ 編集]

>YASUさん
ああいう事を書いていながらも、おおよそ言いたいことは分かっていましたのでご心配なく。
私はどっちかというとPCシミュレータよりも専用マシン系のエミュの方が接していた機会が多かったです。
例えば某専用機の開発環境で、デバッグ向けテスト用のメモリを製品よりも増やしたものと、PC上での
完全エミュレータの二段構えでのクロス開発環境とか。

なので割とCPUが違うものばかり扱ってきた方の人だったので、ついああいうことを書いてしまったんです。
ややこしい突込みして申し訳ない。

>bさん
PSやPS2の頃の開発ツールは触れた事は有りますのでなんとなく分かりますが、PSシリーズって
とんでもない作りしてますよね。汎用機を目指していたセガのハードとは対照的に、徹底的に
ポリゴンマシンを追及していたPSのシリーズは3Dだけを作るなら良かったんですけどね。
CGを表示するにもポリゴンにテクスチャとして貼り付けて表示とか、結構気が狂った仕様
だったように思います。
バスの構成からしても、演算よりもデータ転送命みたいなハードウエアで、そのせいでレジスタ幅が
広かったという事も有るかも。まあ浮動小数演算も結構頑張ればできるハードでしたけど。

>GMSさん
僕も直接PSシリーズは組んだことはないのですが、結構癖が強くて、組み難いハードですよ。
PS3はハードの中身すら知りませんが、少なくともそれより前までの延長線上なら、
相当おかしな作りになっていて、まあ慣れれば何とかなるって感じになっています。
PS4はそんなに豪勢な中身になるんですか・・・なんかもうPCライクに組めそうな位、
余裕の有るハードになってしまいましたね。

>Thiotimolineさん
確かに汎用レジスタセットが15個から31個に増えるメリットは大きいと言えますね。
ただ、4個が8個とか、8個が16個になったようなインパクトはその変化からは余り出ないんですよ。
32bit幅が64bit幅になった事よりは、レジスタの数が増える事は遥かに意味の有る事なんですが、
殆どの処理ではレジスタの数がそこまで多くても、生かし切れない事が多く、最内ループ内で
結局メモリへのアクセスが起きてしまえばそれなりの重さが出てしまうんですよね。
31個の汎用レジスタは確かに意味は持ちますが、鬼に金棒的なレベルでもないって事も
また事実なんですよ。まあ今時のオプティマイザにかかれば私の想像よりも生かしてくれる
可能性は有りますけど。私の脳みそオプティマイズじゃ精々8~16個で限界なので。
  1. URL |
  2. 2013/09/23(月) 02:59:59 |
  3. 鈴 #GpEwlVdw
  4. [ 編集]

64bitならメモリー欲しいですよね

>初めまして
armv8発表されてますね。
いよいよ、スマホも64ビットですね
appleの発表の意図は理解に苦しみますね。
64ビットなら最低メモリー16GB位欲しいですね。
Xpedia Z4が4GBだそうだから
Z4の次が64ビットなんでしょうね
こんなに小さいのに64ビットってなんか凄いなぁって思ってしまいます。
何年か先には、armv8系が主流になるかもしれませんね
パソコンが8、16、32と歩んできた道を
スマホやタブレットは、32から64へと進化するんですね
となると、パソコンは立場が無くなっちゃいますね
現状では、UNIXはSPARC、PCはINTEL、って図式ですけど
技術が進むと、データバスをバースト時128ビットってのも有りになって来ますね
これからの人はパソコンを知らない(要らない)って人も増えてくる様な気がします
自分は、昔からやってるんで、過去遺産をどうするか悩んでいます。
急にでは無いでしょうけど、ここに来て一気に64ビットが進みそうな気配です。
技術の進歩って凄いですね
  1. URL |
  2. 2015/03/20(金) 03:56:52 |
  3. ozaki #-
  4. [ 編集]

PC(Win系)がBit数移行に苦しんでいるのは、アプリが物理的なメディアとしてインストールを選べること。
そして業務利用としてbit数が変わると非対応になってしまうオリジナルアプリがあるのが背景として大きいと思います。
実際に業務利用でxp32bitから動かせない業務アプリもまだまだあります。(しかも予算やソフトベンダーの関係で最新版を作れない)
おまけにRS-232Cポート前提で作られているシステムもまだあるし、入れ替えもままならない茨の道。これが旧Mac前提だったら茨の道どころか煉獄同然な状態でしょう。
Macに至ってはいまだOS9.xを使ってるところもありますし、かといって最新版対応の予算が組めずに現状維持という「このMac壊れないでくれよ」と祈り続けてる会社もあります。

物理的なメディアを持たず、OSはバージョン指定どころかダウングレード不可であることが、特に大きな摩擦も無く移行が進んでる原因と思います。
ただその中でもMacはダウングレードを認めず、ハードリリースの初期バージョン未満にする行為自体をサポートしない一方通行であることが、早々に64bit化を終えた要因でしょう。(ダウングレード用のドライバもありませんし)

Windowsはリリース時点で存在しない未来バージョンも、延長サポート期間中は各社がドライバを提供していますし
ハードリリース時点で延長サポートフェイズに突入した非メインストリームバージョンも各社がドライバを提供しています。
犬(MS)と猫(Apple、Google)を同じに見て、猫に「犬になれよ」や犬に対して「猫になれよ」と言うのが無意味な話であるように、
バージョンを自由に選択できるPC-Windowsと、選択の幅が出荷~現在(または出荷以上現在未満)に縛られるMacや
新型ハード+過去バージョンをそもそもサポートしないMac、Android、iOS機をWin機と同列に見るのは無意味です。
(企業がMac導入を躊躇するのはこの辺の事情でしょうね。そもそもMacが導入も維持もはるかに割高だからシステム担当および社長がよほどの信者でもない限り会社が許可をおろさないし、MSはActiveDirectoryが強みになっているから導入を許さない)

PCが一般に売れたのはインターネットありきのことであり、誰しもがPhotoshopで画像編集やC#アプリ開発を目的にしたものではないということです。
タブレットやスマートフォンという選択肢が、一般PCユーザーのライトユースなニーズ(インターネット利用、ゲームなど)に合致したから一方的に食われ続けてるだけです。
PCほどのものは必要ないけど、上位にも下位にも互換品が無かったため、仕方なくPCを選んだユーザーが移行を始めて、ゆり戻しが進んでいる。
落ち着くところに落ち着いているということであり、それ以上でもそれ未満でもない。
それでも一部企業では過去遺産が現役稼動していて移行もままならない現状は変わりませんが。

Bit数移行に苦しんでるのはサポートが幅広いMS(+Intel)くらいであり、過去互換を切り捨ててしまえば移行は楽なものです。
  1. URL |
  2. 2015/03/20(金) 06:30:59 |
  3. 7SUXEN #22s72cIM
  4. [ 編集]

arm社は良く勉強してると思います

早速のコメント有り難うございます。
今回のarmの64ビット化はarmも良く勉強していると思います。
32bitCPUと64bitCPUを疎結合にするのは、とても良いアイデアだと思います。
こうすれば、32bitCPUをいつでも切り離せるし、64bitCPUも命令に上位互換性を持たせたまま、次世代への移行が容易だからです。
自分としては、64ビットに対して可能性を感じます。
と言いますのは、
1990年頃、人工知能の研究が盛んに行われました。しかし、どれも実用には、なりませんでした。
有用性は、認められていたのですけど、膨大なデータベースが必要で、直ぐにメモリーオーバーするからです。
その様な、知識ベースのアルゴリズムが64ビットになると、実用化してくると思います。
コード自体が4GBを超えることは、まず無い点に関しては、自分も同じ意見です。
しかし、データベースは別の問題です。これは、確実に4GBを超えます。
64ビット時代になると、この様な知識ベースのアプリが遠からず登場して来ます。
そんな、アプリ自分で簡単に作れる分け有りません。
自分もプログラマCOBOLからobjective-c、turbo-assemblerまで組めますが、自分が片手間の時間にそんなアプリを作れるとは、考えていません。
ズバリ、64ビット時代のアプリは、買う時代です。
64ビットのアプリなんて、専門家でなければ、開発出来ません。
日本は、ソフトの分からない人に限ってソフトを買いません。
これは、おかしいと思います。コンピューターは専門の私が見ても難しいです。こんな、難しいもの素人が簡単に操作出来る訳無いと思います。
コンピュータはソフトが無ければ、役に立ちません。自分で作れないなら、買うしか有りません。
これからの時代のコンピュター活用は、使える人と使えない人の両者に極端に別れると考えています。64ビット時代は、ゲームばかりしてる人は使えない人に入る。それ位、64ビットって凄いんです。
armv8(第1世代)が市場で成功して、ペイして、第2世代の開発に繋がる事を願っています。
  1. URL |
  2. 2015/03/20(金) 23:24:51 |
  3. ozaki #-
  4. [ 編集]

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


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

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

トラックバック

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

最近の記事

機能リンク

最近のコメント

カテゴリー

ブログ内検索

ブログリンク

RSSフィード

QRコード

QR

月別アーカイブ



メールフォーム

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

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

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