𝐑𝐨𝐨𝐭𝐓𝐨𝐨𝐥 𝐁𝐥𝐨𝐠
194 subscribers
570 photos
48 videos
5 files
60 links
ニャン
Download Telegram
This media is not supported in your browser
VIEW IN TELEGRAM
⚡️ Portal: Solver запустили на Raspberry Pi 3B 2016...

Оптимизация не перестает удивлять

Что дальше?)
😱4❤‍🔥2💯1
В номинации айтишник года награждается:
😁6❤2🤩1
Экстравагантное использование препроцессора для избежания виртуализации

Когда я говорил про гибкость С++, я в буквальном смысле имел ввиду - С++ очень гибкий. И недавное, чисто обдумывая препроцессинг, мой мозг заметил одну интересную вещь....

Представим задачу с реверсивной зависимостью:
// RenderInterface.h

class IRender
{
virtual void SetupScreen();

virtual void ClearScreen();
virtual void UpdateScreen();
};


И потом где-то, где-то далеко, мы реализуем:
// OpenGLRender.h

class ROpenGLRender : IRender
{
virtual void SetupScreen() override;

virtual void ClearScreen() override;
virtual void UpdateScreen() override;
};

^ В целом неплохо, да? Но что меня, как Ардуинщика, смущает - виртуальные функции...
Во первых: само их существование - убивает меня, как человека, умеющего чувствовать железо
И второе (самое очевидное): - если другой разработчик банально забудет реализовать функцию из интерфейса?

И, относительно недавно заметил одну интересную вещь: Если мы сделаем файл с обьявлением функций, а затем просто будем подключат его и реализовывать все функции? Покажу на практике:
// RenderDeclaration.h

void SetupScreen();

void ClearScreen();
void UpdateScreen();

^ Мы просто объявили функции в безымянном, для компилятора, файле (Напомню - компилятор работает только с .cpp файлами)

А вот затем, в целевом файле, делаем такой фокус:
// OpenGLRender.h

class ROpenGLRender
{
#include "RenderDeclaration.h"
};

Иии, самое интересное, реализацию делаем напрямую в .cpp:
// OpenGLRender.cpp

void ROpenGLRender::SetupScreen() { ... }

void ROpenGLRender::ClearScreen() { ... }
void ROpenGLRender::UpdateScreen() { ... }


По сути, что мы сделали? При проходе препроцессингом, строка #include "RenderDeclaration.h" раскроется с содержимым внутри RenderDeclaration.h, то есть:
// OpenGLRender.h

class ROpenGLRender
{
// #include "RenderDeclaration.h"
void SetupScreen();

void ClearScreen();
void UpdateScreen();
};

^ А затем уже линковщик подловит все обьявления функций с их реализациями в OpenGLRender.cpp и все будет хорошо

Но хорошо, вы скажите, это не гибко и вообще очень плохо. Но я вас спрошу: "Какая, черт побери, гибкость в фундаменте архитектуры, которая ну никак не меняется?!"

По сути, виртуализация - это очень тяжелая штука. Каждая виртуальная функция уже КАК МИНИМУМ занимает от 4 до 8 байт! (4 байта на 32 битной машине. 8 байт на 64 битной машине. Но не суть)

Например вы пишете движок, вы 1 раз реализовали класс для определенной графики - и забыли. Вам не нужно каждый раз менять что-то, особенно динамично - это не имеет смысла так такового (а оверхед будет иметь)

"А если человек хочет реализовать свой вариант графики?" - тогда он просто создаст новый класс, подключит файл с функциями, IDE ему сразу предложит/подскажет какие функции надо реализовать - реализуете и работаете. Все! А чтобы применить графику, достаточно (к примеру):
// Config.h

#define RENDER_CLASS ROpenGLRender


А затем, уже где-то под капотом движка:
// Engine.cpp
#include "Config.h"

void Engine::SetupRender()
{
RENDER_CLASS RenderClass;

RenderClass.SetupScreen();
RenderClass.ClearScreen();
RenderClass.UpdateScreen();

/* Other... */
}


И, если кто не понял, при проходе препроцессингом RENDER_CLASS заменится на ROpenGLRender и мы получим строку ROpenGLRender RenderClass;

И да, если я создам класс RVulkanRender, реализую функции, обновлю конфиг как #define RENDER_CLASS RVulkanRender, то получу тот же гибкий функционал при минимальных затратах. Никаких виртуальных функций, виртуальных таблиц и прочего

А в завершении могу добавить: При обновлении движка, создателю достаточно добавить новое обьявление в RenderDeclaration.h, а затем пользователь (работающий на движке) просто дополнит свой класс RVulkanRender новой функцией и все будет как раньше - без всякого "ой, я случайно забыл переопределить функцию"

What you don't use, you don't pay for. Think Cold.
❤4👍2🔥1👀1
Теория многопоточности - это просто

И я серьёзно: кто хочет вкатиться в теорию многопоточности - не поленитесь и почитайте эту шикарную статью на Хабре:

https://habr.com/ru/articles/974198/
❤1🔥1🤩1💯1
Когда настолько завайбкодился, что даже мониторы не выдержали и отвернулись

писец что я несу под температурой. опять.
🎄9💔2
RootSAI - Simple Assembler Interpreter
I use assembler btw

На днях написал свой простой интерпретатор виртуального 8-битного процессора на плюсах

Проект вышел небольшой, хотя разрабатывать было жуть как интересно

Внутри: 8 регистров, 15 инструкций и моя фирменная архитектура для масштабируемости 🤌

И да, я не полностью воссоздаю архитектуру какого-либо процессора. Проект служит чисто в образовательных целях, а также быть оптимизированным под запуск на настоящем 8-битном AVR 💀

Ссылка: https://github.com/RootTool0/RootSAI
❤3🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
❤2💯2🔥1😱1
С++ тян
теперь вы видели все

Перевод:
- Эй, С++. Можешь ли ты скомпилировать этот код для меня?

- Нет проблем, одну минуту, давай я проверю твой код... Ох~.. Ты правда хочешь сделать это, хах?

- Сделать что? Какие-то проблемы в моём коде?

- Нет-нет, все в порядке! Ноль синтаксических ошибок в коде, то что нужно для меня! Держи свой .exe файл

- Отлично, рад слышать. Спасибо большое

В консоли. Пытается запустить программу

- Ну давай-же... Оно должно работать...
- 🤛 SEGMENTATION FAULT

^ Критическая ошибка программы, когда она пытается получить доступ к памяти, к которой не имеет права. Обычно это разыменование нулевого указателя, или же, выход за границы массива
❤‍🔥3💋2❤1
Что ж, пропал надолго конечно, но теперь я снова здесь

Что могу сказать:
- Обновил комнату
- Обновил столик
- Обновил рабочее место

Теперь сидим с Атомом, работаем, на время не смотрим. Ах, как же давно я не кодил...
(прошла буквально 1 неделя)
❤3🔥2
Оптимизация 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.
❤3🔥2😱1
Shoko - Compile-time UI Framework

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

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

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

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

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

Ссылочка: тык
💯2
С НОВЫМ ГОДОМ!

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

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

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

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

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

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

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

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


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

if(std::time(nullptr) > 1767214800)
std::cout << "New Year 2026!";
❤4❤‍🔥1💯1🎄1
This media is not supported in your browser
VIEW IN TELEGRAM
Решил тоже поднять IQ и начал изучать сетевой код на UE4 (💀)

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

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

Будто пытаешься писать на JavaScript не имея доступа к гайдам - Все такое расплывчитое, не понятное. Но главное что все всё знают и кивают головой, ага
❤6😁1
а еще ловит даже на парковке
❤4🤣3🤩1👀1
А теперь к действительно актуальным вопросам

https://habr.com/ru/articles/983596/
❤4👀2
This media is not supported in your browser
VIEW IN TELEGRAM
А знаете.. в моменте у меня просто щелкнуло и я понял как работает мультиплеер в Анриле - и на деле это довольно таки интересный подход!
❤4❤‍🔥1🔥1
В чем суть:
В концепции Анрила хост/сервер - Держит весь мир и является источником правды. Клиенты же - синхронизируются с сервером. Это называется репликация

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

И в С++ (да и в блюпринтах) для 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.
❤3👍3❤‍🔥1🔥1🤯1