アカウント名:
パスワード:
ARMの32bit命令セットから64bit命令セットに切り替えることで、利用できる汎用レジスタが倍増します。さらに、命令デコーダの仕様上、64bit命令のほうが32bit命令より速く処理できるとみられています。
詳しくは、後藤弘茂氏の記事をお読みください。http://pc.watch.impress.co.jp/docs/column/kaigai/20130918_615784.html [impress.co.jp]
という訳で、Appleは最新のiPhone/iPadに本来の性能を発揮させるため、64bit対応をデベロッパに要求しているのでしょう。
iPhone6や6Plusは、OSやプリインストールアプリは当然64bitのバイナリだと思うんだけど、どんな感じ？速くなった？
5sの時点で64bit化されて、2倍近く速くなってた。今年は5sと比べるとそこまでの差はない。
根拠となるベンチマークはこちらhttp://www.anandtech.com/show/7335/the-iphone-5s-review/5 [anandtech.com]http://www.anandtech.com/show/8559/iphone-6-and-iphone-6-plus-prelimin... [anandtech.com]
5sの時点で64bit化されて、2倍近く速くなってた。
iPhone 5のApple A6からiPhone 5sのApple A7で変わっているところは64bit対応だけじゃないので、じっさい64bit化がどの程度パフォーマンス向上に寄与してるかはこの比較ではなんもわからんですね。
わずか数年前、Thumbモードでコンパイルして必死にバイナリサイズ減らしてたのに…。
# 年は取りたくないもんだ
今日現在もThumbモードでコンパイルしてます。遅いうえに狭いバス幅にしてケチっているので、漫然とARMモードにしちゃうと逆にメモリサイクルのペナルティのほうが大きかったです。で、ARM命令を使うメリットがある関数に絞ってモードを切り換えると。
ARMってそういう小技がある意味無駄にたくさんあるから最適化に時間とられますね。趣味でやるなら楽しいんだけど、仕事的にはどうかなという気がする。
でも個々のアプリのメモリ使用量が増える。
単位時間あたりにアクセスするメモリ量が増え、キャッシュが圧迫されるというデメリットも隣り合わせ。
そんな思いっきり1か0かの主観的コメント出されても…。一般的なアプリでは使用メモリの多くはコードではなくデータ領域だろうから、64bit化でメモリ使用量が増えるかといえば「殆ど変わらん」のが実態でしょう。
データ領域は0の書かれるところが増えて使用量が増えるんじゃないの？
大きなデータはほとんどが配列として格納されてるでしょ。だったら配列の最後に1/2の確率で32bit増える程度の問題でしかない。
ごめん、全然わからない。
配列の最後だけ32bitが64bitになるって、どういう状況？
アラインメントを揃えるためのパディングのことを言っていると思われる（32bitは4で、64bitは8で割り切れるアドレスにデータを置いた方が効率的）。
そこまで知っている人が、ポインタサイズが2倍になる事実を無視しているのは謎だが。
なるほど。
64bit対応といっても、アプリで使っている32bit整数の変数は1つも64bit整数にならないという場合ね。まあ、普通のスマホアプリで64bit整数が必要なものって考えにくいのは確かだが。
# 64bit整数を使いたいのは21億円以上の計算を速くしたい電卓くらいか
？よく解らんけど、レジスタも32bitから64bit化されるんでしょ？そしたら、１００００個の整数の配列を管理しようとしたら、単純に倍になるんじゃないの？
IAアーキテクチャもx64になってレジスタいっぱい増えたけど、早くなったという話はあまり聞かないなあ。
# IEが早くなったんだっけか？
レジスタ増加に伴いコンテキストスイッチでレジスタ退避にかかる時間も倍になったりします。64bit化で命令内のアドレス指定が4バイトから8バイトになり命令キャッシュサイズを倍にするなどしないとキャッシュミスが多発するようになったり…。
64bit化で命令内のアドレス指定が4バイトから8バイトになり
アドレス指定なんて繰り返し実行されるもんでもないのでパフォーマンスに響く部分ではないね。
Vista出る前の話ですが XPx64用に自作の画像処理プログラムをx64コンパイルして試したときはC++関数の変数渡しがスタック渡しからレジスタ渡しに変わって40%くらい速くなって感動した記憶があります。
VC++のx64コンパイラも出始め練れてなかったのか、部分的にオプチマイズ禁止にしないといけなかったり、プログラムのバイナリサイズが激増だったりしたけど。
C++関数の変数渡しがスタック渡しからレジスタ渡しに変わって40%くらい速くなって感動した記憶があります。
そういうとこは32bitでもインライン関数で効率化図れるとこですね。
「32bitでもインライン関数で効率化図れるとこ」なので、64bitでも同様です。関数の中身より呼び出しにコストが掛かる部分についてはインライン関数化で単純に効率化が図れますよ。
その後藤弘茂氏って、「ARMはともかく32bitの出来がひどい。何がひどいか? RISCなのに汎用レジスタが16本しかない、その内の3本はプログラム関連で使っちゃうので、汎用に使えるのはたった13本。これで、ロード/ストアアーキテクチャのハンドリングをしなきゃならない。そうするとコンパイラが効率的なコードを吐けない。ので、コードステップが非常に長くなる。」 [impress.co.jp]て言ってた頭おかしい人?
こういう人の言うこと鵜呑みにして他人に吹聴したら恥掻くよ。
たぶん、根拠の提示もなく頭おかしいといっても、見た人はwwwWWWww乙くらいしか返せないと思う。
今のスラドなら確かにそうかも。
長ったらしい引用なんてしてないで、どこがおかしいか書けばいいのにね。それができなければ、「ARM32bitはクズ、理由は自明、そんなこともわからないのか？」っていう人と同レベル。こういう人が一番恥ずかしいと思う。
32bit ARMについての話題は既出 [srad.jp]
【山田】つまり今のARMの32bitはひどいと。【後藤】ひどい。だって、僕の知り合いでネイティブARM 32bitに触れた人は皆「変態命令セット」って言ってるし(笑)。
僕のお友達が言ってるんだもんというこの人のレベルはどの辺りですか?
全部合ってるよ。今時のコンパイラは、レジスタ数無限の仮想アセンブリを生成して、ターゲットCPUのアセンブリに変換するので、レジスタ数が少ないとレジスタ割り当てが効率良く出来ない。常に効率的なレジスタ割り当てアルゴリズムは存在しないので、余裕が有るほうはコンパイラには優しい。
いまどきのコンパイラはよく使われるデータを優先してレジスタを使用するので、レジスタは何個ぐらいあればまあ適当ってセンはある。その辺分かってない奴は多ければ多いほど良いみたいな勘違いをする。
で、レジスタの数が13個では「ひどい」という根拠はまだですか?
ある程度分かってる人は後藤弘茂の記事なんて読んでないだろうし。昔から記事の質はかなりアレだからな。
32ビットサポートしたくないだけでしょ。互換性軽視だけど、そういう商売の仕方なのでいいんじゃないかな。
将来的には32ビットを切るんだとしても、一時的にでも32ビットと64ビットの両方サポートしなきゃいけなくなるんだから、「～したくないだけ」って理屈はない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
目的は高速化 (スコア:3)
ARMの32bit命令セットから64bit命令セットに切り替えることで、利用できる汎用レジスタが倍増します。
さらに、命令デコーダの仕様上、64bit命令のほうが32bit命令より速く処理できるとみられています。
詳しくは、後藤弘茂氏の記事をお読みください。
http://pc.watch.impress.co.jp/docs/column/kaigai/20130918_615784.html [impress.co.jp]
という訳で、Appleは最新のiPhone/iPadに本来の性能を発揮させるため、64bit対応をデベロッパに要求しているのでしょう。
Re: (スコア:0)
iPhone6や6Plusは、OSやプリインストールアプリは当然64bitのバイナリだと思うんだけど、どんな感じ？速くなった？
Re: (スコア:0)
5sの時点で64bit化されて、2倍近く速くなってた。
今年は5sと比べるとそこまでの差はない。
根拠となるベンチマークはこちら
http://www.anandtech.com/show/7335/the-iphone-5s-review/5 [anandtech.com]
http://www.anandtech.com/show/8559/iphone-6-and-iphone-6-plus-prelimin... [anandtech.com]
Re: (スコア:0)
5sの時点で64bit化されて、2倍近く速くなってた。
iPhone 5のApple A6からiPhone 5sのApple A7で変わっているところは64bit対応だけじゃないので、じっさい64bit化がどの程度パフォーマンス向上に寄与してるかはこの比較ではなんもわからんですね。
Re: (スコア:0)
わずか数年前、Thumbモードでコンパイルして必死にバイナリサイズ減らしてたのに…。
# 年は取りたくないもんだ
Re: (スコア:0)
今日現在もThumbモードでコンパイルしてます。遅いうえに狭いバス幅にしてケチっているので、漫然とARMモードにしちゃうと逆にメモリサイクルのペナルティのほうが大きかったです。で、ARM命令を使うメリットがある関数に絞ってモードを切り換えると。
Re: (スコア:0)
ARMってそういう小技がある意味無駄にたくさんあるから
最適化に時間とられますね。
趣味でやるなら楽しいんだけど、仕事的にはどうかなという気がする。
Re: (スコア:0)
でも個々のアプリのメモリ使用量が増える。
Re: (スコア:0)
単位時間あたりにアクセスするメモリ量が増え、キャッシュが圧迫されるというデメリットも隣り合わせ。
Re: (スコア:0)
そんな思いっきり1か0かの主観的コメント出されても…。
一般的なアプリでは使用メモリの多くはコードではなくデータ領域だろうから、
64bit化でメモリ使用量が増えるかといえば「殆ど変わらん」のが実態でしょう。
Re: (スコア:0)
データ領域は0の書かれるところが増えて使用量が増えるんじゃないの？
Re: (スコア:0)
大きなデータはほとんどが配列として格納されてるでしょ。だったら配列の最後に1/2の確率で32bit増える程度の問題でしかない。
Re: (スコア:0)
ごめん、全然わからない。
配列の最後だけ32bitが64bitになるって、どういう状況？
Re: (スコア:0)
アラインメントを揃えるためのパディングのことを言っていると思われる（32bitは4で、64bitは8で割り切れるアドレスにデータを置いた方が効率的）。
そこまで知っている人が、ポインタサイズが2倍になる事実を無視しているのは謎だが。
Re: (スコア:0)
なるほど。
64bit対応といっても、アプリで使っている32bit整数の変数は1つも64bit整数にならないという場合ね。
まあ、普通のスマホアプリで64bit整数が必要なものって考えにくいのは確かだが。
# 64bit整数を使いたいのは21億円以上の計算を速くしたい電卓くらいか
Re: (スコア:0)
？
よく解らんけど、レジスタも32bitから64bit化されるんでしょ？
そしたら、１００００個の整数の配列を管理しようとしたら、単純に倍になるんじゃないの？
Re: (スコア:0)
IAアーキテクチャもx64になってレジスタいっぱい増えたけど、早くなったという話はあまり聞かないなあ。
# IEが早くなったんだっけか？
Re: (スコア:0)
レジスタ増加に伴いコンテキストスイッチでレジスタ退避にかかる時間も倍になったりします。64bit化で命令内のアドレス指定が4バイトから8バイトになり命令キャッシュサイズを倍にするなどしないとキャッシュミスが多発するようになったり…。
Re: (スコア:0)
64bit化で命令内のアドレス指定が4バイトから8バイトになり
アドレス指定なんて繰り返し実行されるもんでもないのでパフォーマンスに響く部分ではないね。
Re: (スコア:0)
Vista出る前の話ですが XPx64用に自作の画像処理プログラムをx64コンパイルして試したときは
C++関数の変数渡しがスタック渡しからレジスタ渡しに変わって40%くらい速くなって感動した記憶があります。
VC++のx64コンパイラも出始め練れてなかったのか、部分的にオプチマイズ禁止にしないといけなかったり、
プログラムのバイナリサイズが激増だったりしたけど。
Re: (スコア:0)
C++関数の変数渡しがスタック渡しからレジスタ渡しに変わって40%くらい速くなって感動した記憶があります。
そういうとこは32bitでもインライン関数で効率化図れるとこですね。
Re:目的は高速化 (スコア:1)
Re: (スコア:0)
「32bitでもインライン関数で効率化図れるとこ」なので、64bitでも同様です。関数の中身より呼び出しにコストが掛かる部分についてはインライン関数化で単純に効率化が図れますよ。
Re: (スコア:0)
その後藤弘茂氏って、「ARMはともかく32bitの出来がひどい。何がひどいか? RISCなのに汎用レジスタが16本しかない、その内の3本はプログラム関連で使っちゃうので、汎用に使えるのはたった13本。これで、ロード/ストアアーキテクチャのハンドリングをしなきゃならない。そうするとコンパイラが効率的なコードを吐けない。ので、コードステップが非常に長くなる。」 [impress.co.jp]て言ってた頭おかしい人?
こういう人の言うこと鵜呑みにして他人に吹聴したら恥掻くよ。
Re: (スコア:0)
たぶん、根拠の提示もなく頭おかしいといっても、見た人はwwwWWWww乙くらいしか返せないと思う。
Re:目的は高速化 (スコア:1)
今のスラドなら確かにそうかも。
Re: (スコア:0)
長ったらしい引用なんてしてないで、どこがおかしいか書けばいいのにね。
それができなければ、「ARM32bitはクズ、理由は自明、そんなこともわからないのか？」っていう人と同レベル。
こういう人が一番恥ずかしいと思う。
Re: (スコア:0)
32bit ARMについての話題は既出 [srad.jp]
Re: (スコア:0)
僕のお友達が言ってるんだもんというこの人のレベルはどの辺りですか?
Re: (スコア:0)
全部合ってるよ。
今時のコンパイラは、レジスタ数無限の仮想アセンブリを生成して、ターゲットCPUのアセンブリに変換するので、
レジスタ数が少ないとレジスタ割り当てが効率良く出来ない。
常に効率的なレジスタ割り当てアルゴリズムは存在しないので、余裕が有るほうはコンパイラには優しい。
Re: (スコア:0)
いまどきのコンパイラはよく使われるデータを優先してレジスタを使用するので、レジスタは何個ぐらいあればまあ適当ってセンはある。
その辺分かってない奴は多ければ多いほど良いみたいな勘違いをする。
Re: (スコア:0)
で、レジスタの数が13個では「ひどい」という根拠はまだですか?
Re: (スコア:0)
ある程度分かってる人は後藤弘茂の記事なんて読んでないだろうし。
昔から記事の質はかなりアレだからな。
Re: (スコア:0)
32ビットサポートしたくないだけでしょ。
互換性軽視だけど、そういう商売の仕方なのでいいんじゃないかな。
Re: (スコア:0)
将来的には32ビットを切るんだとしても、一時的にでも32ビットと64ビットの両方サポートしなきゃいけなくなるんだから、「～したくないだけ」って理屈はない。