OSDev

Кэш линейка давно уже 128 байт.

Ну вот, на 128 байт никто же пока не догадался выравнивать? Предположим, я сделаю в компиляторе опцию выравнивания на 128 байт. Ну, типа, хрен с ней, с памятью, она нынче дешевая... Какие профиты и/или головняки это даст? Или пшик один, только расход памяти?

_________________
Путь успеха Циолковского — правильно умереть

Сишные компиляторы выравнивают как и положено, согласно размеру типов.

А как положено-то? Определенное значение выравнивания всё равно или задается, или берется из умолчаний. Вот, посмотрел про pack в Visual Studio:

Не отличается от Delphi, стало быть. В чем магия числа 8? Почему не 4? 32-битная платформа ведь. Там дальше еще про SetErrorMode(SEM_NOALIGNMENTFAULTEXCEPT) говорится, но она вроде только для Itanium.

_________________
Путь успеха Циолковского — правильно умереть

Вот что пишет Intel по поводу 8-мёрки. Думаю что выравнивание в структурах данных нужно только для store to load forwarding. Но насколько это эффективно не нашел нигде.

Восьмёрка - компромисная величина? А хардкор тогда будет 128?

Согласно размеру типов. Это значит адрес выравнивания должен быть кратен размеру переменной. Для char=1, считай без выравнивания, для int=4 и т.д. Размещение структур и массивов выравниваются на значение параметра pack. Тоесть char не будет выравненным на 8, а char[2] будет. И struc{char a; char b;} c; будет на 8. Значение параметра pack не означает выравнивание каждой переменной, а определяет максимально разрешённое выравнивание. Если задать pack 4, то char и short по прежнему будут выравниваться на 1 и 2, но зато __int64 будет выравнен не на 8, а на 4, и структуры тоже.
Магия числа pack=8 в том, что это размер самого большого типа в процессоре.

А, к этому надо привыкать. Крайне забавно выглядит когда ты спрашиваешь что то человека а он зависает. Особенно забавно наблюдать это ИРЛ. Какое то психическое отклонение. Причём если начинаешь переспрашивать, обижаются, думают что ты их за идиотов держишь.

По теме уже многое сказали. Выскажу своё имхо ещё раз. Во первых, выравнивание в делфи есть, так что опцию на сколько байт выравнивать сделать не составляет труда, вопрос в самой константе.
Если платформа 32-битная, то логично выбрать 4 байта, что и сделано в старых компиляторах. Однако развитие идёт к 64-битной платформе. Даже на 32-битных процессорах, если меня не ввели в заблуждение, обмен с ОЗУ 64-битный. Начиная с этого момента, выравнивание на 64-бит уже даёт свои преимущества. Нельзя также исключать legacy 32-битный режим на 64-битных процессорах. Далее, возможно борландовцам проще было оставить одну константу на все режимы компляции, неизвестно же как там компилятор устроен (а может на рантайм завязка, на менеджер памяти). Забавная история с выравниванием полей в записях, когда они перечислены через запятую и через точку с запятой. Delphi7 обрабатывал объявления через запятую как packed-кортеж, сейчас всё обрабатывается однотипно. Т.е. не всё там у них прозрачно видимо. В документации написано что выравнивание на 8 байт быстрее, чем на 4, без более подробных сведений. Чтож, я им верю.

Вообще раз уж есть такая тема, то заинтересованным лицам предлагаю сделать замеры, на сколько % выравнивание на 8 байт быстрее чем на 4 байта, и на каких системах соответственно. Это был бы нормальный, объективный критерий, а не растекание мыслью по дереву. Мы тут флудим уже дольше чем такой тест написать и прогнать. Замерять, наверное, надо только 8-байтовые поля, т.е. int64 или float64, т.к. меньшие на 8 байт и не должны выравниваться.


Ну очевидно же: из другого. Какой проект подразумевал автор поста - хз. Но это может быть, например, fpc, или interbase, или gcc.

Магия числа 8 в 64-разрядной шине. 32-битная не платформа а код.

А в каких процессорах оно появилось? В интернетах видел ссылки на Intel Core. А ведь Delphi 6 выпущен 12 лет назад, когда был только Pentium 4.


Спасибо за разъяснение. Я как-то так и представлял, но в таком изложении стало еще понятней. Теперь буду думать, как разрулить это в Канторе.


Объективный тест не так просто придумать. Без знания теории точно не получится.

О 64-битной шине памяти я и сам думал. Тогда получается, что выравнивание рассчитывает на плохой случай -- когда данных нет в кэше. Когда же они попадают в кэш, то занимают больше места, чем теоретически могли бы занимать, не будь выравнивания. Получается игра в рулетку. Или для кэша тоже важно выравнивание?

_________________
Путь успеха Циолковского — правильно умереть