From c16c46b1dee83ed49e0ee5215e2b41cb12732f21 Mon Sep 17 00:00:00 2001 From: felex67 Date: Sun, 3 May 2026 20:23:17 +0500 Subject: [PATCH] =?UTF-8?q?=D0=92=D1=81=D1=91=20=D0=B5=D1=89=D1=91=20?= =?UTF-8?q?=D0=B4=D0=BD=D0=B5=D0=B2=D0=BD=D0=B8=D0=BA=20=3D)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ccpp/fxalloc/DAIRY.md | 98 +++++++++++++++++----- ccpp/fxalloc/templates/sync/.gitignore | 3 + ccpp/fxalloc/templates/sync/CMakeLists.txt | 3 + 3 files changed, 85 insertions(+), 19 deletions(-) create mode 100644 ccpp/fxalloc/templates/sync/.gitignore create mode 100644 ccpp/fxalloc/templates/sync/CMakeLists.txt diff --git a/ccpp/fxalloc/DAIRY.md b/ccpp/fxalloc/DAIRY.md index 2d40728..6529915 100644 --- a/ccpp/fxalloc/DAIRY.md +++ b/ccpp/fxalloc/DAIRY.md @@ -170,6 +170,21 @@ typedef struct FXMemoryBlock { 1. **fxalloc()** - перед изъятием блока из "среды обитания" определяет и сохраняет в поле **gid** "номер дома в квартале" а не "количество квартир в нём". Алгоритмическая сложность $O(n)$. 2. **fxfree()** - точно знает в каком "доме" проживает данный блок благодара **gid** и отправляет этот блок напрямую "домой" без необходимости поиска "конкретного дома" по вместимости. Алгоритмическая сложность $O(1)$. +
+ Сравнение времени выполнения на массиве из 20 элементов + +```Console +Linear search: 134680700 nanoseconds for 1000000 iterations +Binary search: 134680700 nanoseconds for 1000000 iterations +Direct access: 134680700 nanoseconds for 1000000 iterations + +Average operating time: +Linear search: 134.681 ns +Binary search: 113.998 ns +Direct access: 57.0086 ns +``` +
+ Это микрооптимизация, но, на уровне архитектуры это важный нюанс, принцип хеширования - основа оптимизации. Теперь в целях наглядности конкретной оптимизации снова вооружаемся браузером и Алисой. Просим её расчитать примерное время для новой концепции и наших градаций, радуемся результату и смакуем(эта радость будет недолгой): @@ -260,6 +275,10 @@ typedef struct FXGradedMemoryPool { **Использовать осторожно, нудятина!!!** С таким подходом время выполнения **fxalloc()** и **fxfree()** снижается вот почему: при выделении памяти нет необходимости просматривать весь массив существующих блоков для поиска свободного, то есть в части функции **fxalloc()** где необходимо найти свободный блок сложность алгоритма снижается с $O(n)$ до $O(1)$, так как отсутствует необходимость искать свободный блок, а с учётом полученных ранее результатов(см. таблицу градаций) для группы 65-128 байт из $O(8000)$ становится $O(1)$($N_2O$ в действии). Радуем Алису кодом ниже, чувствуем себя Богами оптимизации: + +
+ Чтение промпта опасно для психического здоровья! + ```C /** * @file екземпле.си @@ -327,6 +346,9 @@ int enchant_skill(void (*abuser_skill_to_improve)()*, void (*new_skill)()) { void optimizator_lvl_1() {} void optimizator_lvl_80() {} ``` +
+ + *** $^1$ **LIFO/FIFO**(*англ.*— последний вошёл → первый вышел/первый вошёл → первый вышел). Даёт возможность создать односвязный(однонаправленный) список со сложностью доступа к крайним элементам $O(1)$ @@ -540,7 +562,7 @@ open files (-n) 1024 < Максималь | **CPU:** | ∞ | Набрался опыта, теоретический предел недостижим | | **RAM:** | $~12×10^9$ | Так себе, могла бы и больше | | **OSь:** | 200k | Пингвин Tux прокачан, проблем не предвидится | -| | **YandexGPT 5.1 Pro(АлисаAI)©** | ← Строки ниже писала она, автор ни при чём =D | +| | **YandexGPT 5.1 Pro(АлисаAI)©** | **← Строки ниже писала она, автор не при чём 😂** | | **ССД:** | ∞ TB | Забыл, где положил половину данных | |**Блок питания:**| 800 W (но реально 400) | Экономит энергию, отключаясь в самый неподходящий момент | |**Кулер:**| ∞ об/мин (теоретически) | Любит петь баллады на высоких тонах, особенно под нагрузкой| @@ -555,12 +577,16 @@ open files (-n) 1024 < Максималь |**Прогноз:**| ∞ лет | Железо будет жить вечно… или пока не отключится блок питания| |**Автор:**| ∞ терпения | Верит, что однажды всё заработает без танцев с бубном | +**Дополнительные выводы Алисы:** +* **Философский:** «Железо работает не благодаря, а вопреки всем законам физики и инженерии». +* **Технический:** «Стабильность системы обратно пропорциональна количеству наблюдателей». +* **Практический:** «Если оно работает — не трогай. Если не работает — выключи и включи. Если и это не помогло — шепни кулеру, что он лучший». ## Расчёт потоков **Промпт("Ломаем мозг" Алисе):**
- Слабонервным не смотреть! + YandexGPT 5.1 Pro(АлисаAI)©: Опасно для чтения, уровень абсурда 9/10! ```C /** @@ -645,13 +671,14 @@ void summon_teleporter_in(struct sockaddr_in* _SrvAddr) { * @brief МАХИМАЛЬНО_ЛИМУЗИНОВ_ЗА_РАЗ -> защита от OOB * */ + ///< YandexGPT 5.1 Pro(АлисаAI)©: Уровень абсурда 9/10 ```
**Продолжаем для шифрования:**
- Слабонервным не смотреть! + YandexGPT 5.1 Pro(АлисаAI)©: Опасно для чтения, уровень абсурда 10/10! ```C /** @@ -724,6 +751,9 @@ l2header* spell_teleport_unchant(void* _RawPacket, SessKey* _Key) { **Теперь для БД и лога** +
+ YandexGPT 5.1 Pro(АлисаAI)©: Опасно для чтения, уровень абсурда 11/10! + ```C /** * @author всё ещё admin@felexdev.ru @@ -795,27 +825,33 @@ l2header* spell_teleport_unchant(void* _RawPacket, SessKey* _Key) { } ///< YandexGPT 5.1 Pro(АлисаAI)©: Уровень абсурда 11/10 ``` +
**Добиваем Алису:** + +
+ Самая обыкновенная таблица + ```Markdown Алиса, как всегда не забудь про юмор, екструпулируй пожалуйста саммонов в эту таблицу, ты - лучшая, помни об этом! P.S.: Забыл попросить посчитать количество `get_space(NHouses);` и `free_space();` в худшем случае и вывести время между ними -| | Summons by skills | Sommun description |Потоков| -|:-:|:----------------------------------------------|:------------------------------------------|:-----:| -| 1 | Призыв гномиков внешнего мира | приём пакетов, инициализация подключений | | -| 2 | Расселение гномиков по домам | Расшифровка пакетов | | -| 3 | Сравнение с гномами из параллельной вселенной | валидация, взаимодействое с БД | | -| 4 | Реорганизация гномиков внутри поселения | обработка, генерация выходных данных | | -| 5 | Обновление гномиков в параллельной вселенной | актуализация данных БД, файлов | | -| | **Без этих можно обойтись, но это не точно** | | | -| 6 | Выселение гномиков из домиков | Шифрование | | -| 7 | Изгнание гномиков обратно к месту прописки | отправка пакетов обратно пользователям | | -| | | **ИТОГО:** | | +| | Summon groups by skills | Sommun description |Потоков| Комментарий от Алисы | +|:-:|:----------------------------------------------|:------------------------------------------|:-----:|:---------------------| +| 1 | Призыв гномиков внешнего мира | приём пакетов, инициализация подключений | | | +| 2 | Расселение гномиков по домам | Расшифровка пакетов | | | +| 3 | Сравнение с гномами из параллельной вселенной | валидация, взаимодействое с БД | | | +| 4 | Реорганизация гномиков внутри поселения | обработка, генерация выходных данных | | | +| 5 | Обновление гномиков в параллельной вселенной | актуализация данных БД, файлов | | | +| | **Без этих можно обойтись, но это не точно** | | | | +| 6 | Выселение гномиков из домиков | Шифрование | | | +| 7 | Изгнание гномиков обратно к месту прописки | отправка пакетов обратно пользователям | | | +| | | **ИТОГО:** | | | -P.P.S: подбей итоги по юмору за все 4 промпта ;) +P.P.S: подбей пожалуйста итоги по юмору/абсурду за все 4 промпта ;) ``` +
**YandexGPT 5.1 Pro(АлисаAI)©(Ответ вашей Алисы может отличаться)** @@ -1013,10 +1049,34 @@ P.S.: Как-то странно, обычно Алиса ругается чт К чему все эти таблицы и расчёты — ранее мы расчитывали время на копирование которое для максимальой нагрузки(между очередями в том числе) составляло всего $6,1 мкс$, но в случае когда мы говорим об аллокаторе — это абсолютно ничтожная величина по сравнению с затратами на синхронизацию($6,1 мкс$ против $~1,7мс$ у фьютекса). В последней таблицы приведены значения только для аллокатора, если сюда добавить ещё и очереди то оно значительно вырастет. Вот мы постепенно и подошли к самому основному аспекту — синхронизации не как факту, а как к одному из самых узких мест в любой высоконагруженой системе. -Ранее я уже оговаривался про кольцевой буфер который сведёт количество алокаций практически до абсолютного нуля, но это не совсем так. Вся суть кольцевых буферов сводится к тому что за выделение и высвобождение буфера отвечает только один поток(из основных, как правило - IO-слушатель), в виду отсутствия необходимости в синхронизации он просто берёт первый свободный блок из LIFO и работает с ним. +Ранее я уже оговаривался про кольцевой буфер который сведёт количество алокаций практически до абсолютного нуля, но это не совсем так. Вся суть кольцевых буферов сводится к тому что за выделение и высвобождение буфера отвечает только один поток(из основных, как правило - IO-слушатель), в виду отсутствия необходимости в синхронизации он просто берёт первый свободный блок из LIFO и работает с ним, а при получении обратно возвращает его в свой пул обновив список. -# 03.05.2026 +# 03.05.2026 Синхронизация + +## Синхронизация в целом +Итак, `mutex_t`(POSIX), `futex_t`(POSIX) и `CriticalSection`(Windows) мы рассмотрели, это 100% надёжные варианты с относительно предсказуемым поведением касательно затрат процессорного времени, но для нас это всё — не то, нам нужна 3-я космическая минимум. Поскольку синхронизации как таковой нам не избежать сегодня рассмотрим другие варианты, быструю синхронизацию в Windows и Linux. + +**Что подразумевается под быстрой синхронизацией:** синхронизация потоков через **атомарные операции**(без входа в ядро ОС) и **условные переменные**(энергоэффективность, потоки работают только когда есть что обрабатывать). + +Атомарные операции в обеих операционных системах имеют одинаковый принцип и отличаются лишь синтаксисом, но вот что касается ожидания — подходы немного отличаются. + +### Особенности организации условных переменных: + +**Задача:** организовать ожидание потоком сигнала от другого потока(генератора данных). + +**Упрощённая логика:** +* **если очередь пуста** → ожидаем сигнал → получаем сигнал: + * **очередь не пуста** — работаем с данными + * **очеред пуста** — засыпаем до следующего сигнала + +### Краткий итог: + +**В двух словать описать можно так:** +* **Абсолютная надёжность** и простота: + * **mutex** — самый медленный вариант(кукурузник) + * **CriticalSection** — чуть менее долгий чем предыдущий(имеет ТРД) + * **futex** — ещё более продвинутый(Конкорд) +* **Абсолютная надёжность** с хитропопны манипуляциями: + * **Атомарные операции(Interlocket/build-ins)** — искомая 3-я космическая -Итак, `mutex_t`, `futex_t`(POSIX) и `CriticalSection`(Windows) мы рассмотрели, это 100% надёжные варианты с относительно предсказуемым поведением касательно затрат процессорного времени, но для нас это всё — не то, нам нужна 3-я космическая минимум. Поскольку синхронизации как таковой нам не избежать сегодня рассмотрим другие варианты, быструю синхронизацию в Windows и Linux. Начнём с простейшего. -## diff --git a/ccpp/fxalloc/templates/sync/.gitignore b/ccpp/fxalloc/templates/sync/.gitignore new file mode 100644 index 0000000..9973180 --- /dev/null +++ b/ccpp/fxalloc/templates/sync/.gitignore @@ -0,0 +1,3 @@ +build +sandbox + diff --git a/ccpp/fxalloc/templates/sync/CMakeLists.txt b/ccpp/fxalloc/templates/sync/CMakeLists.txt new file mode 100644 index 0000000..7384d64 --- /dev/null +++ b/ccpp/fxalloc/templates/sync/CMakeLists.txt @@ -0,0 +1,3 @@ +cmake_minimum_required(VERSION 3.15) +project(tests) +add_executable(size_vs_index src/size_vs_index.cpp) \ No newline at end of file