Dima T1. Честно говоря, не понял при чем тут многопоточный доступ. Разве что предположить, что по выровненным данным работа идет быстрее и взаимные ожидания потоков будут меньше. Но тогда не понятно: если скорость быстрее, то почему не применить это ускорение для однопоточного доступа?
Это не ускорение, а замедление многопоточной работы.

Процессор обменивается с памятью кэш-линиями. Кэш-линия - это 64 байта выровненные по 64, т.е. адрес кратен 64-м. Если один поток (ядро) меняет хоть один байт в кэш-линии, то другой поток (точнее другое ядро) при обращении к этой же кэш-линии будет вынужден дождаться когда первое ядро скинет кэш-линию в общий кэш и перечитает ее оттуда.
Причем разные потоки могут работать с разными частями кэш-линии, но это все-равно заставит ее постоянно перечитывать.

Например: в твоей структуре один поток постоянно меняет a1, второй a2. В итоге будет тормоз, т.к. эти два потока будут мешать друг-другу.[/quot]

У меня нет многопоточной работы с общим массивом. Каждый поток имеет свой массив и работает только с ним. Но за информацию спасибо.

Вася Уткин, спасибо за инфу по SSE и AVX!

Насколько я понял современные AVX инструкции также работают с невыровненными данными, только слегка просаживаются по производительности.

rdb_devAlekseySQL, ты не видел громоздких конструкций, потому что в этих программах используется выравнивание по умолчанию. Помнится, даже в древнейшем Borland C++ Builder, при создании проекта (32 разрядного, естественно), устанавливалось выравнивание по умолчанию на границу 8 байт. Особенность работы процессоров Intel с оперативной памятью такова, что эти процессоры действительно быстрее работают с выравненными данными, так как если, скажем, процессор читает невыравненное двойное слово, то ему придется дважды выполнить инструкцию чтения из памяти, даже если это двойное слово находится полностью в кэше (два раза обратится к кэшу), а уж если невыравненное двойное слово попадёт на границу линии кеша и одной из линий не окажется в кэше, то возникнет "промах", будет захвачена системная шина и произведена медленная операция чтения из оперативной памяти, при этом, также, могут быть попутно выполнены отложенные инструкции чтения/записи в оперативную память, что приведет к одномоментному резкому снижению производительности.

Для 64-разрядных приложений, естественно, выравнивание должно выполняться по адресам, кратным 8 байтам.

Я как раз и пытаюсь докопаться до информации о выравнивании по- умолчанию. Откуда у вас эта информация?

Например, в опциях компилятора я не нашел подобных настроек. Ведь если компилятор это делает выравнивание по- умолчанию, то должен быть ключ отключения этой возможности. А такого ключа нету...

Функция malloc и переменные в стеке также по- умолчанию невыровнены, иначе не нужны были бы надстройки с выравниванием.

Кто выравнивает данные по- умолчанию?

rdb_devНапример, Using the GNU Compiler Collection , стр. 475


rdb_devТакой ключ есть и не один! Есть даже отдельно ключ для выравнивания по умолчанию членов структур.

Что это за ключи, которыми можно попросить выровнять данные ("you can leave out the alignment factor and just ask the compiler to align a variable or field to the default alignment")?

В опциях О1, О2, О3 есть только выравнивания для инструкций, и нет опций выравнивания данных:


Спасибо, за подсказки, я потихоньку продвигаюсь к решению вопроса (осталось только чудо- ключи найти).

Нашел ключи для платформы х86:


И для диалекта С++:


Так что насколько я понимаю ситуация такая: если не хочешь зависеть от компилятора, то выравнивай сам с помощью: void* _mm_malloc(int size, int base) и alignas.

rdb_devAlekseySQL, дополнительно смотри директиву компилятора #pragma pack

Спасибо, уже изучил на Хабре .

Решил я сделать все по- умному и начать пользоваться выравниванием для своих больших массивов (а на мелкие переменный забить). Но не тут- то было! Нет аналога функции realloc с выравниванием, только для malloc... Засада какая- то :-(