Оптимизация bool и битовые поля

Господа, сегодня в нашем чате выяснилась неприятная новость - вы не знаете как оптимизировать bool?

Обьясняю на пальцах:
Начиная с первого стандарта С++98 (тык) тип bool определен как целочисленный тип, размер которого определяется реализацией (implementation-defined) и на большинстве современных платформ равен 1 байту, то есть: sizeof(bool) = 1 байт

Но логичный вопрос: Если для true и false нужен лишь 1 бит, то куда остальные 7 бит деваются? НИКУДА

7 бит банально "простаивают", не используются.

Скажете фигня? Так-то да, но есть и более низкоуровневые вещи, где это явно проявляется - видеокарта

В любом игровом движке есть внегласная цель: убить время в общении между CPU и GPU. Это синхронизации, перевод команд, общение - все это занимает уйму времени (а я напомню - мы должны выдать как минимум*60 кадров в секунду, при этом успеть просчитать движковые компоненты, акторы мира, UI, звуки, кнопки, и зарендерить это все)

И один из способов ускорить общение CPU и GPU - банально сжать данные для передачи по шине, чтобы уменьшить количество передаваемых байт. И именно тут bool вставляет палки в колеса: Создать 32 переменных bool - это 32 байта. А если использовать оптимизированный вариант - всего-лишь 4 байта. Чувствуете разницу? Данные сжались в 8 раз!

Теперь про сам способ (не является серебрянной пулей, но иногда выигрывает)

Битовые поля

struct S {
  uint8_t  a : 1;
  uint8_t  b : 3;
  uint8_t  c : 4;
};

^ Здесь ": 1" и тд. - указывает количество бит, выделенных для данной переменной. В нашем случае a - 1 бит, b - 3 бита, c - 4 бита. Замерив размер структуры через sizeof(S) на большинстве компиляторов и платформ это даст 1 байт. 1 байт! Но мы в него впихнули 3 переменных!

И это не конец, ведь, можно создать 8 переменных по 1 биту, и тем самым, упакуем 8 переменных в 1 байт. А вспоминая, что bool и так использует 1 бит для работы, то получается мы 8 bool-переменных упаковали в 1 байт, вместо 8!

Оптимизация? Оптимизация. И если кто считает чересчур бредом - взгляньте исходники Unreal Engine. У него во всех горячих местах используется этот простой синтаксис

Use every bit for your purposes. Think Cold.

Shoko - Compile-time UI Framework

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

Завел отдельный блог для своего фреймворка: Shoko - UI Framework

Блог не будет стремиться к финальному продукту, это просто.. разработка. Такая, какая она есть - со всем своим ужасом и красотой

Да, будет больше живых, "нетехничных", моментов, а также слишком заумные штуки

Так что кто желает - приглашаю присоединиться к своему ответу на вопрос "Как далеко можно зайти, перенося Runtime на Compile-time?"

Ссылочка: тык

С НОВЫМ ГОДОМ!

Я хочу от всей души поблагодарить всех вас, кого встретил, и кто остался со мной
Хочется вот просто обнять всех! И сказать вот что:

Атом - Бро, мы с тобой сколько уже прошли? Брат за брата как 2 солдата - и в снег, и в град, и в Демо, и в Релиз

Денчик - тот самый, мой любимый 🤪 😋. Люблю, уважаю, и просто рад что встретил тебя

мдпка - жжешь! Просто в соло поднялся и в музыке, и в C#. А вообще - ты красавчик, растешь на глазах, и мотивируешь меня

Оранж - Ну просто наш крепкий политик и специалист в монолитности кода)) Рад что встретил тебя, дружище!

Матвейка - Любимый кот Шредингера, хотя стоит тебе просто определится с языком программирования и все пойдет в гору

Котомаг - И ссоримся, и миримся, и скидываем друг-другу ДЗ по Алгебре и арты по ZZZ - Все стабильно, а стабильность - залог успеха

И одна милая девушка - Что нашла меня под мое грустное настроение перед моим ДР, и теперь которую я рад менторить по С++. Я рад что встретил тебя


Еще раз обнимаю всех вас, ребятки ;)

if(std::time(nullptr) > 1767214800)
    std::cout << "New Year 2026!";

Решил тоже поднять IQ и начал изучать сетевой код на UE4 (💀)

Эта всякая синхронизация, RPC, владения событий, кто прав а кто виноват - бррр, что за жесть

Я же сам не любитель асинхронности, а тут такое...

Будто пытаешься писать на JavaScript не имея доступа к гайдам - Все такое расплывчитое, не понятное. Но главное что все всё знают и кивают головой, ага

А теперь к действительно актуальным вопросам

https://habr.com/ru/articles/983596/

А знаете.. в моменте у меня просто щелкнуло и я понял как работает мультиплеер в Анриле - и на деле это довольно таки интересный подход!

В чем суть:
В концепции Анрила хост/сервер - Держит весь мир и является источником правды. Клиенты же - синхронизируются с сервером. Это называется репликация

Да, клиенты могут отправлять ему команды, изменять данные, но последнее слово - за сервером

И в С++ (да и в блюпринтах) для UPROPERTY() существует такой параметр как Replicated который говорит, что переменная - реплецируемая, то есть, ее итоговое состояние будет жестко синхронизировано с сервером

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

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

Так вот что я понял - работа мультиплеера проста до безумия если быть в потоке с Анрилом!

Когда клиент, например, хочет присесть - выполянется локальное действие Crouch (bIsCrouch = true) И происходит отправка команды серверу, который у себя обновляет состояние переменной bIsCrouch для нашего игрока

И в чем соль - если не просить сервер обновить переменную, то на сервере bIsCrouch так и останется false, затем в новом пакете данных (между сервером и клиентом) будет диссинхрон нашего локального bIsCrouch = true и пакетного bIsCrouch = false, а так как макрос UPROPERTY(Replicated) обязует Анрил синхронизировать переменные, то произойдет неприятный пролаг, рассинхронизация и пошло поехало, покатилось побежало...

А благодаря тому способу, теперь мы сами по себе (локально) выставляем bIsCrouch = true и просим сервер обновить его bIsCrouch на true. А потом в следующем пакете данных приходит новый bIsCrouch = true, который и так равный локальному bIsCrouch и все будет в потоке - Сервер будет хранить истину для других клиентов, и мы получаем бесплатный и быстрый отклик

И да - можно, конечно, всю логику отдать серверу, чтобы его просить обновить переменную и ждать пока придет ответ, но... Это будет дико долго, из-за чего будет плохой отклик и вы будете чувствовать задержку вообще в любом действии во всей игре

Как-то так

Thinking in Four Dimensions. Think Cold.

А часики то тикают...

Черт возьми, оно работает...
знали бы вы мое волнение сейчас

Когда я только начинал проектировать Shoko, то много внимания уделял про архитектуру и кроссплатформенность до уровня Embedded

И знаете? Оно работает!

Слева - Raspberry Pi 3B (1GB RAM) + LCD Shield (Linux)
Справа - Мой ПК (Windows 11)

И абсолютно не меняя код (только конфиг), я могу переключаться между платформами, ха

Compile-time UI начинает жить!

Если бы массивы были искусством, то это был бы Black-White Array

Емае, как же я кайфую от алгоритма, просто блаженство

https://habr.com/ru/articles/984184/

Моя честная реакция когда в школе упомянули Указательное местоимение:

Я просто сейчас в диком сегфолте

Ведь реально.. Это мини-версия статичной рефлексии из С++26!

Которую я случайным образом повторил на С++17

Вот до чего доводит долго сидеть в Райдере по 10 часов 💀

Рефлексия там, где ее не должно быть

Немного ночной пост о том, как я в Shoko реализовал собственную статическую рефлексию на С++17