私は誰かがiPhone3GSでのARM対Thumbコードのパフォーマンスについて何か難しい数字を持っているのだろうかと思っていました。特に非浮動小数点（VFPまたはNEON）コードの場合-Thumbモードでの浮動小数点のパフォーマンスの問題を認識しています。
より大きなARM命令の余分なコードサイズがパフォーマンスの危険になるポイントはありますか？言い換えると、実行可能コードが使用可能なメモリと比較して比較的小さい場合、Thumbモードをオンにすることで測定されたパフォーマンスの違いはありますか？
私が尋ねる理由は、「-marm」オプションを使用してXcodeのNEON固有のソースファイルに対してARMを有効にできますが、GCCがx86をビルドしているため、これによりシミュレーターのビルドが中断されるためです。「親指でコンパイル」をオフにして、それで済ませるべきかどうか疑問に思いました。
私は iPhone については知りませんが、親指は ARM よりも遅いという一律の声明はまったく正しくありません。32 ビット幅のゼロ待機状態メモリを指定すると、thumb は少し遅くなり、5% または 10% のような数値になります。それが別の話であるthumb2であれば、thumb2はより速く実行できると言われています.iPhoneが何を持っているかはわかりませんが、それはthumb2ではないという私の推測です.
ゼロ待機状態の 32 ビット メモリが不足していない場合、結果はさまざまです。大きなことの 1 つは、32 ビット幅のメモリです。GameBoy Advance ファミリのような 16 ビット幅のバスで実行していて、そのメモリまたは ROM にいくつかの待機状態がある場合、thumb は、同じタスクを実行するためにより多くの Thumb 命令が必要であっても、ARM のパフォーマンスを容易に凌ぐことができます。
コードをテストしてください！興味があるかどうかにかかわらず、結果を提供するテストを発明することは難しくありません。親指が腕を吹き飛ばすように、腕が親指を吹き飛ばすのは簡単です。drystone が何であるかは誰が気にしますか? 重要なのは、今日あなたのコードをどれだけ速く実行できるかです。
何年にもわたって ARM のコード パフォーマンスをテストしてわかったことは、コードとコンパイラが大きな要因であるということです。したがって、thumb は同じタスクを実行するために数パーセント多くの命令を使用するため、理論的には数パーセント遅くなります。しかし、あなたのお気に入りのコンパイラは恐ろしいものであり、単にコンパイラを切り替えるだけで数倍高速に実行できることをご存知ですか (gcc はそのカテゴリに分類されます)。または、同じコンパイラを使用して最適化オプションを混同します。どちらの方法でも、ツールを賢く使用することで、腕と親指の違いを隠すことができます。あなたはおそらくこれを知っていますが、コードをコンパイルする方法を知っている唯一の方法であり、より良いパフォーマンスを得る唯一の方法は、より多くのメモリまたは他のハードウェアを問題に投入することであると考えている人の数を知って驚くでしょう.
iPhone を使用している場合、それらの人々は LLVM を使用していると聞きましたか? 私はさまざまな点で llvm の概念が好きで、成熟したら毎日のドライバーとして使用したいと思っていますが、実行していた特定のタスクで 10 ～ 20% (またはそれ以上) 遅いコードを生成することがわかりました。私は腕モードで、親指モードを試していませんでした。l1 と l2 キャッシュをオンにしていました。サムとアームを実際に比較するためにキャッシュなしでテストした場合、おそらくサムが数パーセント遅くなることがわかりますが、考えてみると（当時は興味がありませんでした）、アームコードよりも2倍のサムコードをキャッシュできます。タスクの全体的なコードが数パーセント増えたとしても、それを大幅に多くキャッシュし、平均フェッチ時間を短縮することで、大幅に高速化できる可能性があることを暗示している可能性があります。私はそれを試してみる必要があるかもしれません。
llvm を使用している場合、複数の場所で最適化を実行するという別の問題があります。C から最適化可能なバイトコードに移行すると、バイトコード自体を最適化できます。次に、すべてのバイトコードをマージして全体として最適化できます。次に、バイトコードからアセンブラーに移行するときに最適化できます。ソース ファイルが 3 つしかなく、機会ごとに 2 つの最適化レベル (最適化しないか最適化するか) しかないと仮定した場合、gcc では 8 つの組み合わせをテストする必要があり、llvm では実験の数がほぼ 1 桁多くなります。 . 数百から数千まで、実際に実行できる範囲を超えています。私が実行していた1つのテストでは、Cからバイトコードへのステップで最適化するのではなく、バイトコードを個別に最適化するのではなく、バイトコードファイルを1つの大きな（ger）ファイルにマージした後に最適化します。
要するに...テスト、テスト、テスト。
編集：
私はバイトコードという言葉を使ってきましたが、LLVM の世界では正しい用語はビットコードだと思います。.bc ファイルのコードは、私が意味するものです...
LLVM を使用して C から ARM に移行する場合、中間にビットコード (bc) があります。C to bc ステップで最適化するためのコマンド ライン オプションがあります。bc を実行すると、bc から bc へ、ファイルごとに最適化できます。選択した場合は、2 つ以上の bc ファイルをより大きな bc ファイルにマージするか、すべてのファイルを 1 つの大きな bc ファイルに変換することができます。次に、これらの結合された各ファイルも最適化できます。
私の理論では、これまでのところいくつかのテストケースしかありませんが、プログラム/プロジェクト全体を1つの大きなbcファイルにするまで最適化を行わない場合、オプティマイザーは最大量のif情報を持っているということです。その仕事をします。つまり、最適化なしで C から bc に移行するということです。次に、すべての bc ファイルを 1 つの大きな bc ファイルにマージします。すべてを 1 つの大きな bc ファイルとして取得したら、オプティマイザーに最適化ステップを実行させ、情報とできれば最適化の品質を最大化します。次に、最適化された bc ファイルから ARM アセンブラーに移動します。llc のデフォルト設定は最適化がオンになっています。ターゲットを最適化する方法を知っている唯一のステップであるため、最適化を許可する必要があります。bc から bc への最適化は一般的なものであり、ターゲット固有ではありません (AFAIK)。
まだテスト、テスト、テストしなければなりません。ステップ間の最適化を試して、プログラムの実行が速くなったり遅くなったりするかどうかを確認してください。
パフォーマンス/コード サイズ/消費電力のトレードオフについては、ARM/Thumb のこの PDF を参照してください。
ARM 命令と Thumb 命令のプロファイル ガイド付き選択
- アリゾナ大学コンピュータ サイエンス学部 Rajiv Gupta 著
Thumb コードは、本質的に常に同等の ARM よりも遅くなります。Thumb コードがパフォーマンスを大きく向上させる 1 つのケースは、コードがオンチップ メモリまたはキャッシュに適合するかどうかに違いが生じる場合です。
コードの実際の動作に完全に依存するため、パフォーマンスの違いを正確に示すことは困難です。
XCode でアーキテクチャごとのコンパイラ フラグを設定できます。これにより、シミュレータのビルドが中断されるのを回避できます。XCode ビルド設定のドキュメントを参照してください。