Если нет многопоточного доступа и не обращаешься через SSE>=3 и AVX, то ничего выравнивать не надо, с выравниванием только памяти больше съешь.

Но если хочется поиграться, то:

AlekseySQLВася УткинЕсли нет многопоточного доступа и не обращаешься через SSE>=3 и AVX, то ничего выравнивать не надо, с выравниванием только памяти больше съешь.

1. Честно говоря, не понял при чем тут многопоточный доступ. Разве что предположить, что по выровненным данным работа идет быстрее и взаимные ожидания потоков будут меньше. Но тогда не понятно: если скорость быстрее, то почему не применить это ускорение для однопоточного доступа?
2. Насколько я понял SSE и AVX критичны к выравниванию в регистрах процессора (с помощью которых производятся векторные операции). Другими словами, в случае векторных операций у нас два места хранения данных: память и регистры процессора, и ключевое значение для скорости векторных операций имеет выровненность в регистрах (а выровненность в памяти влияет также как и при обычных невекторных операциях).

Спасибо, за пример!
1. При многопоточном доступе код оптимизируют, чтобы потоки работали с разными элементами массива, а чтобы эта оптимизация сработала, нужна ещё одна оптимизация - эти разные элементы массива должны быть в разных кэш-линиях, чтобы избежать false-sharing.
2. На данных не выравненных в памяти инструкции SSE/AVX сохраняющие или загружающие данные из памяти: некоторые будут работать медленно, некоторые быстро, а некоторые совсем откажутся работать :
https://software.intel.com/en-us/forums/intel-isa-extensions/topic/752392 Load 256-bits (composed of 4 packed double-precision (64-bit) floating-point elements) from memory into dst. mem_addr must be aligned on a 32-byte boundary or a general-protection exception may be generated .
https://en.wikipedia.org/wiki/SSE4 With SSE4a the misaligned SSE feature was also introduced which meant unaligned load instructions were as fast as aligned versions on aligned addresses. It also allowed disabling the alignment check on non-load SSE operations accessing memory.[4] Intel later introduced similar speed improvements to unaligned SSE in their Nehalem processors, but did not introduce misaligned access by non-load SSE instructions until AVX.[5]


Вот сколько инструкций загружающих данные из памяти: https://software.intel.com/sites/landingpage/IntrinsicsGuide/#techs=SSE,SSE2,SSE3,SSSE3,SSE4_1,AVX,AVX2,AVX_512,KNC&expand=3585&cats=Load

rdb_devDima T, ты, конечно же, в DOS'е замеры делал? ;) Потому что, если ты делал замеры в операционной системе с вытесняющей многозадачностью не создавая тестирующего драйвера режима ядра с маскированием прерываний, то все эти расчёты, ровным счётом, ничего не значат.
Во всех Intel CPU за последние 12 лет как минимум начиная с Intel Pentium 4 и заканчивая последним SkyLake X размер кэш-линии 64 B/line : http://www.7-cpu.com/ и даже на Intel Itanium 2.
А до этого было 32 B/line на Intel Pentium MMX

Для замера проседания скорости при попадании в false-sharing не требуется отключать вытесняющую многозадачность если используется число не превышающее количество ядер, т.к. квант времени на поток на современных ОС (Win/Linux) относительно огромен - более 1 мс, а оверхед на переключение контекста менее ~1 мкс - это в 1000 раз меньше, т.е. менее 0.1%. И не требуется отключать(маскировать) прерывания если параллельно с вашим тестом не работает высоко-нагруженное приложение постоянно взаимодействующее с устройствами.
И даже если бы было потоков больше, чем ядер, и шел шквал прерываний, то это испортило бы только величину проседания при false-sharing, но не испортило бы понимание где начинается false-sharing и где он заканчивается, т.е. размер кэш-линии в любом случае статистически виден четко, т.к. в хорошем тесте замер происходит сотни тысяч раз и усредняется.