[C/C++] Выравнивание структур. Надо ли париться?

> Проводится ли автоматическая оптимизация порядка данных

нет

> Или использовать pragma pack в критичных классах/структурах?

wtf are «критичные классы/структуры»?

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

> LiseElement
Что такое Lise?

> Что такое Lise?

Это копипаста из другой части интернетов. Без понятия.

wtf are «критичные классы/структуры»?

Те, для которых критична скорость обращения к которым и/или занимаемая ими память.

Что значит «оптимизация порядка данных»? Чтобы компактнее чтоли выходило? Дурь какая. А для оптимизации по производительности как раз они и выравниваются с паддингом.
Для передачи по сети/маршалинга в любом случае надо поэлементно упаковывать.

Не только компактнее.

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

>Проводится ли популярными компиляторами (gcc, майкрософтовский компилятор) автоматическая оптимизация порядка данных в структурах, или же это лучше делать вручную?
У вас pod структуры, а в них компилятор не имеет права менять порядок мемберов. Так что делайте вручную.

а где можно почитать спецификацию на требования к выравниванию? это ведь архитектурно-зависимые вещи. ISO-IEC-9899:1999 описывает это очень в общих чертах при беглом осмотре.

Упаковка структур снижает скорость работы с некоторыми полями. Лучше сгруппировать поля структур правильно.

что подразумевается под правильностью?

В порядке убывания размера поля.

Париться стоит только тогда, когда передаешь данные по сети или сохраняешь в файл.

обязательно ли это делать вручную? это ухудшит читаемость хедеров, ведь там всё объявлено в логическом порядке.

может, можно как-нибудь компилятор попросить самого это проделать?

> Париться стоит только тогда, когда передаешь данные по сети или сохраняешь в файл.

У меня МНОГО объектов и важна скорость работы с ними.

да и сохраняется всё будет средствами Qt, там своя сериализация, крутая.

Присоединяюсь к вопросу ТСа.

Париться стоит только тогда, когда передаешь данные по сети или сохраняешь в файл.

Ууу как все запущено. Под msdos все еще программируешь?

>что подразумевается под правильностью?

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

и я это должен головой придумывать, или же есть какая-нибудь прагма или прочее указание компилятору, чтобы оно само всё хорошо сделало?

ХЗ, я головой продумывал когда надо было. В чём проблема-то - арфиметику забыл?

>> Париться стоит только тогда, когда передаешь данные по сети или сохраняешь в файл.

У меня МНОГО объектов

МНОГО - это очень точное определение %)

и важна скорость работы с ними.

Premature optimization и всё такое. Тасовать порядок можно, если хочешь красиво разложить данные по строкам кэша, но... для этого надо знать паттерны обращения к полям.

>> Париться стоит только тогда, когда передаешь данные по сети или сохраняешь в файл.

Ууу как все запущено

Ну не молчи уже, расскажи, как надо.

Думаю оно имело ввиду, что записиориентированные файлы - это пережиток досевой эпохи. Типа сейчас рулят xml и ковровое бомбометание.

что за ковровое бомбометание? там сейчас рулят xml и всякие сериализации (я использую QDataStream), смотря что именно надо писать и в каком количестве.

нашёл только это http://insidecpp.ru/antipatterns/premature_optimization/

как именно это относится к проекту, не понял

> Думаю оно имело ввиду, что записиориентированные файлы - это пережиток досевой эпохи.

Ы. Ну да, сейчас модно всё подряд сериализвать в XML.

> как именно это относится к проекту, не понял

make it run; make it right; make it fast. Думать о выравнивании структур, которые живут только внутри программы, нужно на третьей стадии. Ты до нее уже дошел?

пока что нет, но этот момент близится.

но неужели нет каких-нибудь способов завставить компилятор самому справиться с этой задачей? хотя бы конкретно в случае gcc.

>но неужели нет каких-нибудь способов завставить компилятор самому справиться с этой задачей? хотя бы конкретно в случае gcc.
Читай мой первый пост, пока не поймёшь.

я понял. но ведь может же быть какая-нибудь pragma всё равно

Ну сделай выравнивание в байт. Вообще как правило pod структуры не объявляются как попало. Тот же майкрософт всегда объявляет поля по убыванию размера.

> но неужели нет каких-нибудь способов завставить компилятор самому справиться с этой задачей?

С какой - упаковать поля оптимально? Нет такого способа. Просто потому, что «оптимальность» зависит от конкретного режима использования, да и вообще Си не тот язык, где компилятору позволяются такие вольности.

Перед тем как пихать данные в структуру нужно подумать, сколько шин она будет занимать. Структуры с кратным размеру шины объёмом хороши, ещё лучше - если обьем кратен размеру шины с множителем 2^n.

В таких случаях о переупорядочивании можно не думать. В остальном - компиляторо-зависимо.

>Перед тем как пихать данные в структуру нужно подумать, сколько шин она будет занимать. Структуры с кратным размеру шины объёмом хороши, ещё лучше - если обьем кратен размеру шины с множителем 2^n.
Что за бред?

1. шина обычно == sizeof(void*)

>1. шина обычно == sizeof(void*)
Не понимаю вас. Во первых разрядность шины памяти не связана с разрядностью указателей, а во вторых эти ваши шины здесь не о чём.

Ну ок, ни о чём, хороших и быстрых программ вам.

> У меня МНОГО объектов и важна скорость работы с ними.

Собственно выравнивание и позволяет увеличить скорость обращения к полям. Доверьтесь компилятору, если не работаете с вводом-выводом этих объектов.

>1. шина обычно == sizeof(void*)

Обычно - это где?
На i8088 это не так. На iPentium тоже, видите ли.

Вам уже сто раз сказали. На большинстве классических машин скорость работы зависит от выравнивания размеру машинного слова, чем от размера структуры. Единственное преимущество небольшого размера структуры — возможность поместиться в кеш… Но тут всё зависит от алгоритма, конечно же

> На большинстве классических машин скорость работы зависит от выравнивания размеру машинного слова, чем от размера структуры. Единственное преимущество небольшого размера структуры — возможность поместиться в кеш…

Вот чего я ждал! Спасибо.

>Думаю оно имело ввиду, что записиориентированные файлы - это пережиток досевой эпохи. Типа сейчас рулят xml и ковровое бомбометание.

Дык.. ведь всем давно известно, что xml рулить не может, не? =)

> ведь всем давно известно, что xml рулить не может, не? =)

XML рулит у джавистов и шарпистов т.к. они ничего больше не знают. А остальные выбирают формат в зависимости от поставленной задачи.