Я так и знал что ты пропадал так и эдак задрачивая godbolt и
компиляторы. =) Тут у нас обсуждаемый момент сдвинулся в новые
области. Я не говорил и не считаю что подобное streamed хранение
данных якобы всегда проблемно. Совсем нет, и в копьютерной графике
например (GPU), хранение текстур/буферов в виде rrrrr bbbbb gggg
wwww довольно часто встречается (или floating point застримленных
по частям) или даже выкушенных и сохраненных рядом битов из байт
(т.е. транспонированных
байтовых массивов) всегда имело/имеет свои бенефиты, один из которых - эффективная паковка. Скажем, пакованое AY музло так пакуется ясное дело куда круче чем при interleaved. А паковка, если грамотно ее готовить == скорость.
Речь выше шла только о _обязательной_ единовременной выборке сразу нескольких полей, поскольку топикстартеру очевидно надо было обращаться ко всем полям одновременно. Ну и архитектурно, просто невыровненный доступ решать надо иначе. Я только про это. И не сверх того.
А вот случаи типа описанных тобой это ясное дело, уже другие задачи. Алгоритмы работают иначе - хэш на то и хэш, что сначала "щупает" (probing) легковесные хэш-части, а потом уже выгребает тяжеловесную data. И терять bandwidth на выгребании просто сопровождающих данных это глупо, конечно там надо ре-арранжить данные секвентально. В этом я абсолютно согласен. Кроме того, эта задача по-идее, сводится вообще, к spatial partitioning. Транспонирование, которым мы занимались выше - это я считаю частный случай partitioning. Более совершенной формой этой игры являются иерархические структуры: таблицы таблиц и под-таблицы, деревья.
RxTx (01.06.2020 23:54, просмотров: 219) ответил fk0 на Да, захардкодить смещение между массивами. С чистым C язык не
позволяет, нужно полагаться на сообразительность компилятора (по
ссылке в районе 104 строки видно, что она есть -- разные члены
структуры-массива адресуются путём прибавления большого смещения).
В C++ всё можно сделать, в смысл объяснить детали компилятору и
заставить его делать именно так.