2

G++ でコンパイルできるように、C コードベースにいくつかの変更を加えました。いくつかの煩わしさとのハックで、動作しているようです-fpermissive -fshort-wchar。

好奇心-O2から、変更前の GCC ビルドの実行可能ファイルと、変更後の G++ ビルドの実行可能ファイルの削除されたサイズを比較しました。「後」は 32 バイト大きくなりました (500K っぽいバイナリで)。私はそれが非常に近いことにうれしい驚きを覚えましたが、オプティマイザがそれほど一貫しているのに、なぜ100% 一貫していないのでしょうか? しかし、strchrにそのオーバーロードを追加することで何かが発生したのかもしれません。

私が心配するほど重要ではありません。しかし、その後、C++ との互換性の変更を考慮して、GCC で C をビルドすることにしました。その削除された-O2実行可能ファイルは、変更前の C ビルドよりも4096 バイト大きかった。

なぜこれらの 3 つのサイズがこのようになるのか、またなぜこのような「丸めた」数値になるのかについて、直感を持っている人はいますか? C++ の変更は、基本的に、C であれ C++ であれ、最適化されるべきすべてのものでした。基本的：

  • 以前インターフェースで void* を取るものとして定義された関数が一貫して名前をマングルするように、不透明な型付けの導入。適切な内部型のローカルへの不透明な型のマクロを介して、ローカルへのいくつかのキャスト割り当てを導入しました

  • 古いスタイルの C 関数ヘッダー定義のいくつかのインスタンスの削除

  • 以前にリンケージを指定していなかったいくつかのグローバル定数のリンケージを「extern」に変更し、ヘッダーに割り当てを保持することを一時的に許容しますが、それに対して反論することを望んでいます

  • 一部の signed char を unsigned char に変更し、一部の unsigned long を unsigned int に変更します (ただし、その逆はありません)。

誰かがこの最適化のケースについて優れた直感を持っている場合は、関連する変更の各セットを個別にバックアウトして、それらがサイズにどのように影響するかを確認する時間を節約できます...!

4

1 に答える 1

1

覚えておいてください: C++ プログラムは本質的に C プログラムよりも大きくはありません。コンパイルにはもっと時間がかかるかもしれませんが、本質的に C++ プログラムを大きくするものは何もありません。

そして実際には...より厳密な形式主義と未定義の動作のために残された小刻みに動く余地のために、C++コンパイラはCコンパイラよりもCコードベースでより多くの最適化を行うことができるかもしれません.

あなた（別名私）が説明している違いは小さいです。また、@rodrigo と @MelNicholson が指摘しているように、ブロック サイズの丸めによって、わずかな違いでも誇張される可能性があります。したがって、実際の 1 バイトの違いは、4096 バイトのファイル サイズの違いにつながる可能性があります。

C コンパイラのリグレッション テストをまとめて取得し、C と C++ としてビルドして、実行可能ファイルのサイズに顕著な違いがあるかどうかを確認し、それらの違いの原因のパターンを探すのは興味深いかもしれません。あなた（別名私）に時間があれば。コンパイラが改善できる場所にフィードバックするためのデータを提供する場合があります。しかし、基本的に、500K の実行可能ファイルでこのサイズの単一インスタンスの違いから学ぶことはまったくありません。

于 2014-05-08T23:35:08.657 に答える