•  03-07-2019
  •  | 
  •  

質問

BOOLデータ型が事前定義されていない場合は常に、次の定義を使用してブール値を使用していました

typedef unsigned char BOOL;

（メモリ使用量のため）。

パフォーマンス上の理由から、ネイティブのバス幅を使用する方が良い場合があることに気付きました。たとえば、32ビットプロセッサの場合、

typedef unsigned int BOOL;

今、ネイティブバス幅にBOOLを定義したい場合、64ビットプロセッサで何が起こるか。

役に立ちましたか？

解決

少なくともx86とARMは、ペナルティなしで32ビットレジスタとの間でバイトをロードおよび格納できるため、charを使用してもパフォーマンスへの影響はありません。完全にはわかりませんが、x86-64にもそのような指示があると思います。 （もちろん、x86およびx86-64はレジスタ内で8ビット値を直接処理することもできます。）

したがって、唯一の懸念事項はメモリレイアウトに関するものです。もちろん、コンパイラはすべてを調整するため、ほとんどの場合、構造体のchar値は互いに隣接していない限りパディングされます。実際に数バイトのスペースを節約し、キャッシュパフォーマンスをわずかに向上させることができます。 BOOLの巨大な配列があり、メモリが問題になる場合は、とにかくそれらをビットパックする必要があります。

いずれにしても、それは問題ではありません。両方の方法でコンパイルされたプログラムを実行してみて、パフォーマンスまたはメモリ使用量に大きな影響があるかどうかを確認してみてください。あるとわかったら、自分でビールを買って、私からのふりをすることができます。

他のヒント

ネイティブバス幅については、効率的な幅ほど心配する必要はありません（それが目標でした）。ほぼすべてのマシンで、適切なcコンパイラは unsigned int を合理的に効率的な幅にコンパイルするので、準備はいいです。

パフォーマンスを推測しないで、測定。測定することで、何が優れているかについて最終的な答えが得られます。これは、コンパイラの新しいバージョン、システムのアップグレードごとに変わる可能性があることを忘れないでください...

また、ある日ブール値の配列が必要になる場合があります。その場合、ブールにプロセッサワードを使用することは最良の解決策ではありません。

stdbool.h でブール型を使用しませんか？

プリプロセッサを使用することをお勧めします。

 #ifndef BOOL 
   #ifdef ILP32
     #define BOOL uint32_t
   #endif
   #ifdef LP64
     #define BOOL uint64_t
   #endif
 #endif

ほとんどのプラットフォームに最適

typedef列挙 { FALSE = 0、 TRUE = 1 } BOOL;

まあ、いつでもtypedefを long long か何かに定義できますが、実際にはこれが何らかの理由で人々がすることだとは思いません。 （おそらくsizeof（int *）またはそのようなものに基づいて条件付き定義を行うこともできます）。

charの使用は、整数の使用よりも遅い場合があります。

stdint.hの

int_fast8_t は適切なはずです。選択肢

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top