2

2 のべき乗がキャッシュの競合に与える影響について読んだ後、午後はプロセッサ キャッシュについて調べました。今度は、この新しい知識をマルチスレッド プログラムのメモリ アロケータに適用したいと考えています。しかし、私はまだそれを完全に理解していません。

私はプロセッサが 2 のべき乗を好むという印象を受けていたので、私のアロケーターは要求されたサイズを次の 2 のべき乗に丸め、ページをこのサイズの倍数にスライスして配布します。ページがいっぱいになると、新しいページがマップされ、同じようにスライスされます。これにより、ページへの非常に類似した予測可能なオフセットが発生します。

この問題を回避するには、アロケーターをどの程度適応させる必要がありますか? たとえば、アドレスを少しランダム化する必要がありますか?それとも、そもそも 2 のべき乗を使用することにうんざりしているのでしょうか?

ありがとう！

4

1 に答える 1

0

これがパフォーマンスにとって重要であるという議論の余地のない証拠が得られるまでは、そのままにしておいてください。余分な複雑さは、おそらくそれだけの価値はありません。

誰もが Bentley の「効率的なプログラムの作成」を読む (そして理解する!) 必要があります (残念なことに現在は絶版になっています。彼の「Programming Pearls」には要約が含まれており、これも読む価値があります)。

  • コードの最適化に着手する前に、その価値があるかどうかを確認してください。パフォーマンスが適切であれば、時間をより有効に活用できます。はい、最初に測定する必要があります。
  • コストがどこに費やされているかを測定します。プログラマーは、コストがどこにあるかを推測するのが苦手なことで有名です
  • 最もパフォーマンスが向上するのは、問題を再定義することです (場合によっては、より速く解決できる問題を解決するだけで十分です)。次に、システムの全体的な構成、次に優れたアルゴリズム/データ構造です。そして最後に、ここで検討したような細部の最適化を行います。
  • あなたの親しみやすいコンパイラーは、「良いコードを生成する」という方向に少し突っ込むと、同様の (フル機能スケールの) タスクを与えられた場合、経験豊富なアセンブリー言語プログラマーよりもはるかに優れたコードを生成します。「パフォーマンスのための」ほとんどのローカルソースコードの再編成は、意味のないもの (コンパイラーが独自に行ったであろう) か、有害なものです (コンパイラーは通常のコードシーケンスを認識して書き換えます。異常なコードは、混乱して何もしないか、悪いコードを生成する可能性があります)。 .
  • プログラマーの時間 (書き込み、デバッグ、保守) は、非常に異常な状況を除いて、あちこちで数マイクロ秒のコンピューター時間よりもはるかに価値があります。仕事をする最も単純なコードを書き、経験がそれが価値があることを示した場合にのみ書き直してください。
于 2013-02-16T21:39:08.320 に答える