ОП здесь упоминается в последнем посте (4-й пункт снизу):
"Теперь одна вещь, которая всегда беспокоила меня об этом, это все ребенок
проверка указателя Обычно есть много нулевых указателей, и
ожидание доступа к памяти для заполнения кеша нулями просто кажется
глупый. Со временем я добавил байт, который содержит 1 или 0, чтобы сказать, если
каждый из указателей равен NULL. Сначала это просто уменьшило кеш
отходы. Тем не менее, мне удалось сравнять 9 расстояний, 8 указателей
биты и 3 бита направления через все таблицы и логику для
генерировать одну переменную переключателя, которая позволяет случаям пропускать
проверяет указатель и вызывает только соответствующих детей напрямую. Он находится в
факт быстрее, чем выше, но гораздо сложнее объяснить, если у вас нет
видел эту версию. "
Он обращается к октодам как к структуре данных для объемного рендеринга в реальном времени. Они будут размещены в куче, из-за их размера. То, что я пытаюсь выяснить, это:
(a) Являются ли его предположения относительно ожидания доступа к памяти действительными? Насколько я понимаю, он имеет в виду ожидание полного выхода в основную память для извлечения данных, поскольку он предполагает, что он не будет найден в кэше из-за, как правило, не слишком хорошей локализации ссылок при использовании динамически распределенных октодеревьев ( общий для этой структуры данных в такого рода приложениях).
(б) Если (а) окажется правдой, я пытаюсь выяснить, как этот обходной путь
Со временем я добавил байт, который содержит 1 или 0, чтобы сказать, является ли каждый из
указатели NULL.
будет реализован без все еще с использованием кучи и, таким образом, по-прежнему нести такие же накладные расходы, поскольку я предполагаю, что его необходимо будет сохранить в узле octree.