выравнивание в x86_64

ну я так понял: флоаты выравниваются на 4 байта. шорты на 2 байта.

Сперва идет шорт. Потом дырка 2 байта чтобы выравнять флоат. Потом 3 флоата. Потом еще дырка 2 байта, для того чтобы следующая структура была выровнена по флоату.

s/выравнять/выровнять/

Вообще-то, про выравнивания вопросы больше к компилятору и уровню оптимизации, чем к процу...

> Сперва идет шорт. Потом дырка 2 байта чтобы выравнять флоат. Потом 3 флоата. Потом еще дырка 2 байта, для того чтобы следующая структура была выровнена по флоату.

ой, я что то не то написал.

Сперва идет шорт. Потом дырка 2 байта чтобы выравнять флоат. Потом флоат. Потом 3 шорта. Потом еще дырка 2 байта, для того чтобы следующая структура была выровнена по флоату (потому что структура выравнивается по общему кратному выравнивания ее членов).

Используй pragma pack() и у тебя не будет ни дыр, ни разрывов под
любой архитектурой

$ cat test1.cc
#include <iostream>

#pragma pack(1)

class first {
    short pole1;
};

class second : public first {
    float pole2;
    short pole3;
    short pole4;
    short pole5;
};

main ()
{
    std::cout << sizeof(first)  << std::endl
              << sizeof(second) << std::endl;
    return 0;
}

$ g++ test1.cc  -o test1
$ ./test1 
2
12
$ uname -a
Linux worker.lan 2.6.24-18-generic #1 SMP Wed May 28 19:28:38 UTC 2008 x86_64 GNU/Linux

> Используй pragma pack() и у тебя не будет ни дыр, ни разрывов под любой архитектурой

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

> А потом программу решат собрать под архитектурой, где доступ к невыровненным данным очень медленный (реализуется битовыми сдвигами)

битовые сдвиги это еще хорошо. А могут делать это в обработчике прерывания по невыровненному доступу.

> А потом программу решат собрать под архитектурой, где доступ к невыровненным данным очень медленный

Спарки мертвы.

> Используй pragma pack() и у тебя не будет ни дыр, ни разрывов под любой архитектурой

Щедевръ!

Начнем с того, что за такие советы обычно сразу дают 10 лет расстрела вонючими пулями. Это не ИМХО, это -- констатация факта.

Употребление pragma pack ПО МЕНЬШЕЙ МЕРЕ СПОРНО _вообще_. А уж рекомендация использования в качестве панацеи (я правильно понял совет?), несомненно, признак непрофессионализма. Это примерно сравнимо с рекомендацией администратору всегда работать под рутом.

И как мне это чудо зажать? знаете когда таких структурок 100000000 то как-то впадло иметь дыр на 400 мегов... Чем светит этот pragma pack() в красках? прога не системная и для других архитектур в обозримом будущем не планируется...

> И как мне это чудо зажать?

ЗАЧЕМ?

> знаете когда таких структурок 100000000 то как-то впадло иметь дыр на 400 мегов..

Удивительно, но -- не факт! Хотя обычно -- да, и в подобных случаях _думать_ приходится...

> Чем светит этот pragma pack() в красках? прога не системная и для других архитектур в обозримом будущем не планируется...

Всего лишь -- директива "pragma" вообще не переносима. А в остальном -- Ни малейших проблем! Если понимать под "обозримом будущем" следующие пару лет -- вперед!!

( Мое дело, конечно, но я подобных перцев считаю _личными_врагами_!:-) -- мне приходилось разгребать ваши программы через пару лет после того, как вы нашли себе места потеплее :-) -- шутка )

> Всего лишь -- директива "pragma" вообще не переносима. А в остальном -- Ни малейших проблем! Если понимать под "обозримом будущем" следующие пару лет -- вперед!!

Этой песне уже лет двадцать.

> И как мне это чудо зажать?

Может просто переупорядочить элементы в структуре?

HTH

Ой умный, уж как я их там не переупорядочивал только... все равно дыры)

> Этой песне уже лет двадцать.

К счастью, только 10.

Именно последния лет десять появились такие Умники, и начались Проблемы (каждые 2 года). До этого -- да, лет 20 их не было (ни Умников, ни проблем...)

:-)

> Ой умный, уж как я их там не переупорядочивал только... все равно дыры)

К сожалению не могу протестировать на x86_64, но на 32-битной системе
проблема решается перестановкой двух полей:

~/tmp $ cat t.cpp

#include <stdio.h>

class first {
    short pole1;
}; 

class tho_1 : public first {
    float pole2;
    short pole3; 
    short pole4; 
    short pole5; 
};

class tho_2 : public first {
    short pole3; 
    float pole2;
    short pole4; 
    short pole5; 
};

int main()
{
    printf("Before reordering: %d\n", sizeof(tho_1));
    printf("After reordering:  %d\n", sizeof(tho_2));

}

~/tmp $ make t
g++     t.cpp   -o t
~/tmp $ ./t
Before reordering: 16
After reordering:  12
~/tmp $ 

Конечно не всегда можно добится отсутствия полного отсутствия "дыр"
и padding'а, но обычно их можно свести к минимуму.

HTH

>> Спарки мертвы.

На x86/amd64 доступ к невыровненным данным тоже медленней, чем к выровненным. Не смертельно конечно, но всё же не очень хорошо. А в случае использования SSE для доступа к выровненным и невыровненным данным вообще разные инструкции процессора используются. И разница в скорости там не маленькая.

> Употребление pragma pack ПО МЕНЬШЕЙ МЕРЕ СПОРНО _вообще_. А уж рекомендация использования в качестве панацеи (я правильно понял совет?), несомненно, признак непрофессионализма.

Не стоит так уж краски сгущать. И расстреливать за это тоже не нужно. Страшного ничего не произойдёт. При использовании
pragma pack - выигрыш в объёме используемой памяти и проигрыш по скорости доступа к невыровненному адресу.

>> Употребление pragma pack ПО МЕНЬШЕЙ МЕРЕ СПОРНО _вообще_. . . .

> Страшного ничего не произойдёт.

Ну, произойдет _страшная_ непереносимость! Ок, давайте ради экономии 5% делать вставки на наитивном ассемблере, или интринсики...

Ладно, если просто между платформами непереносимость -- нет, все гораздо хуже! ГЦЦ нынче пишет такая же пыонерия, и сие чудо каждые пару лет само с собой не совместимо...