ヒープに割り当てられたオブジェクトを指定して、主メモリへの呼び出しを減らす

The OP here mentions in the final post (4th or so para from bottom):

"これについて私にいつも迷惑をかけることの1つは、すべて子供   ポインタチェック。通常、多くのヌルポインタがあります。   メモリアクセスを待って、ゼロでキャッシュを満たすように見える   愚か。時間の経過とともに、1または0を含むバイトを追加してif   各ポインタはNULLです。最初はこれでキャッシュが減少しました   無駄。しかし、私は9つの距離比較、8ポインタ   ビット、および3つの方向ビットがすべていくつかのテーブルおよびロジックを介して   ケースをスキップするための単一のスイッチ変数を生成する   ポインタのチェックを行い、関連する子を直接呼び出します。それは   実際には上記よりも速いですが、そうでない場合は説明するのがずっと難しくなります   このバージョンを見ました」。

彼はリアルタイムボリュームレンダリングのためのデータ構造としてoctreesを参照しています。これらは、そのサイズのためにヒープに割り当てられます。私が把握しようとしているのは、

(a) Are his assumptions in terms of waiting on memory access, valid? My understanding is that he's referring to waiting on a full run out to main memory to fetch data, since he's assuming it won't be found in the cache due to generally not-too-good locality of reference when using dynamically-allocated octrees (common for this data structure in this sort of application).

(b) Should (a) prove to be true, I am trying to figure out how this workaround

時間の経過とともに、1または0を含むバイトを追加して、それぞれの   ポインタはNULLです。

ヒープを使用してまだ実装されていないので、オクツリーノードに格納する必要があると仮定しているので、同じオーバヘッドが発生します。

1
この質問は本当に答えにくいですか?私は、少なくとも(b)は、ここの周りの一人が光を当てるのは簡単だろうと思っていたでしょう。
追加された 著者 Arcane Engineer,

1 答え

(a) Yes, his concerns about memory wait time are valid. In this case, he seems to be worried about the size of the node itself in memory; just the children take up 8 pointers, which is 64 bytes on a 64-bit architecture, or one cache line just for the children.

(b) That bitfield is stored in the node itself, but now takes up only 1 byte (1 bit for 8 pointers). It's not clear to me that this is an advantage though, as the line(s) containing the children will get loaded anyway when they are searched. However, he's apparently doing some bit tricks that allow him to determine which children to search with very few branches, which may increase performance. I wish he had some benchmarks that would show the benefit.

0
追加された