istreamC ++のファミリread()またはCのいずれかを使用してファイル（または任意の入力ストリーム）から生データを読み取る場合fread()は、バッファと、読み取るデータの数を指定する必要があります。私が見たほとんどのプログラムは、512から4096の間で2の累乗を任意に選択したようです。
編集
ほとんどの答えは、コンパイル時に決定できないということのようです。実行時にそれを見つけても大丈夫です。
出典：
FileInputStreamを使用する場合、理想的なバッファサイズをどのように決定しますか？
最適なバッファサイズは、ファイルシステムのブロックサイズ、CPUキャッシュサイズ、キャッシュレイテンシなどの多くの要素に関連しています。
ほとんどのファイルシステムは、4096または8192のブロックサイズを使用するように構成されています。理論的には、ディスクブロックよりも数バイト多く読み取るようにバッファーサイズを構成すると、ファイルシステムでの操作が非常に非効率になる可能性があります。一度に4100バイトを読み取るようにバッファーを構成しました。各読み取りには、ファイルシステムによる2ブロックの読み取りが必要です）。ブロックがすでにキャッシュにある場合は、RAM-> L3/L2キャッシュレイテンシの代償を払うことになります。運が悪く、ブロックがまだキャッシュにない場合は、ディスク->RAMレイテンシの代償も支払います。
これが、ほとんどのバッファのサイズが2の累乗であり、通常はディスクブロックサイズよりも大きい（または等しい）と見なされる理由です。つまり、ストリーム読み取りの1つで複数のディスクブロック読み取りが発生する可能性がありますが、これらの読み取りは常に完全なブロックを使用します。無駄な読み取りはありません。
これを保証すると、通常、読み取りと後続の処理の両方に影響を与える他のパフォーマンスに適したパラメーター（データバス幅の調整、DMA調整、メモリキャッシュラインの調整、仮想メモリページの整数）が発生します。
考えられる理由の1つは、ディスクセクターのサイズが通常512バイトであるため、すべてのハードウェアレイヤーとキャッシュによって低レベルのコードが実際にこの事実を効率的に使用できると仮定すると、その倍数を読み取る方が効率的です。これは、デバイスドライバーを作成するか、バッファーなしの読み取りを実行しない限り、おそらく不可能です。
それが2の累乗でなければならないことを私が知っている理由はありません。バッファサイズが最大内にある必要があるという制約がありますsize_tが、これが問題になる可能性はほとんどありません。
明らかにバッファが大きいほど良いですが、これは明らかにスケーラブルではないため、コンパイル時またはできれば実行時にシステムリソースの考慮事項を考慮する必要があります。
1。2の累乗でなければならない/すべきである理由はありますか、それともこれは2の累乗に対するプログラマーの自然な傾向ですか？
あまり。おそらく、メモリコピーを簡素化するために、データバス幅のサイズでも同じになるはずです。したがって、16に分割するものはすべて、現在のテクノロジで問題ありません。2の累乗を使用すると、将来のテクノロジーでうまく機能する可能性が高くなります。
2。「理想的な」数は何でしょうか？「理想的」とは、それが最速であることを意味します。
最速は可能な限りです。ただし、数キロバイトを超えると、使用するメモリの量と比較してパフォーマンスの違いはごくわずかになります。
基盤となるデバイスのバッファサイズの倍数である必要があると思いますか？または、基になるストリームオブジェクトのバッファの可能性がありますか？とにかく、これらのバッファのサイズをどのように判断しますか？
基になるバッファのサイズを実際に知ることはできません。または、それらが同じままであることに依存することもできません。
そして、私がそうしたら、それの倍数を使用すると、正確なサイズを使用するよりも速度が向上しますか？
いくつかありますが、ごくわずかです。
バッファの理想的なサイズは、ハードドライブ内の1ブロックのサイズであると思います。そのため、ハードドライブからデータを保存またはフェッチするときに、バッファと適切にマッピングできます。