LINUX.ORG.RU
ФорумTalks

Тяжёлый выбор в трате лишних байт структуры

 align, , , ,


0

5

И так, есть структура

{
  u8
  u8
  u16  x;
  u16
  u16
  i64
  u64
  u8 [128]
  ...
}

Поле x получилось так что в нём младшие 12 бит и старшие 4 бита используются почти отдельно и приходится везде расставлять &0xFFF. Тянет отделить старшие 4 бита в отдельное u8 поле, но посмотрите насколько фатально это повлияет на дыры из-за выравнивания :( Как быть?

★★★★★

Последнее исправление: firkax (всего исправлений: 2)

Пахома (pahole) в помощь

mittorn ★★★★★
()

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

задолбало ставить &0xfff, обмажься дефайнами, геттерами, сеттерами, аксессорами. Распакуй в удобную структуру. Но почти точно общение с этим полем в очень небольшом участке кода, вам очень надо всё поломать ?

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

Распакуй в удобную структуру.

Не, распаковать как раз без проблем. Я про то что она в памяти станет лишние 8 байт занимать 🤡 хотя добавили всего один, и с двумя некрасивыми дырами против идеальной укладки которая сейчас. Я более чем уверен что при любом раскладе производительность измеримо не изменится, проблема скорее эстетическая.

firkax ★★★★★
() автор топика
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от iSage

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

firkax ★★★★★
() автор топика
Последнее исправление: firkax (всего исправлений: 1)

Как быть?

Битовые поля рассматривал в качестве варианта?

u5er ★★★
()
Ответ на: комментарий от firkax

Они нарушают принцип прозрачности конвертации си в ассемблер

Что за принцип такой?

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

Но ведь это не так, как минимум на архитектурах load-store.

hateyoufeel ★★★★★
()
Ответ на: комментарий от firkax

распакуй в колоночность тогда у тя в байте будет два нибла

ваще колоночность это не новость у Кнута буквально проводится тезис о семантической эквивалентности массива записей и записи массивов

при этом в зависимости от распределения потребных действий набор записей это больше для oltp а набор массивов для olap

qulinxao3 ★☆
()
Ответ на: комментарий от firkax

ващет «колоночность» при современных кэшах

обычно быстрее ибо однороднее данные ну и сжатие вдруг

qulinxao3 ★☆
()

Как быть?

Заменить массив структур на структуру массивов.

i-rinat ★★★★★
()

затерпи. напиши макросы. или перемести переменные что u64 тебя за жопу не кусало.

ckotctvo
()
Ответ на: комментарий от firkax

Ну нет так нет. Может тебе ещё union как-то поможет…

aiqu6Ait ★★★★
()

Докупи память.

Возможность зарабатывать больше среднего — единственная причина заниматься такими постыдными занятиями как программирование.

buddhist ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)