Всё ещё дневник =)

This commit is contained in:
2026-05-03 20:23:17 +05:00
parent b25b30cfc7
commit da7a16338c
3 changed files with 85 additions and 19 deletions
+79 -19
View File
@@ -170,6 +170,21 @@ typedef struct FXMemoryBlock {
1. **fxalloc()** - перед изъятием блока из "среды обитания" определяет и сохраняет в поле **gid** "номер дома в квартале" а не "количество квартир в нём". Алгоритмическая сложность $O(n)$.
2. **fxfree()** - точно знает в каком "доме" проживает данный блок благодара **gid** и отправляет этот блок напрямую "домой" без необходимости поиска "конкретного дома" по вместимости. Алгоритмическая сложность $O(1)$.
<details>
<summary>Сравнение времени выполнения на массиве из 20 элементов</summary>
```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
```
</details>
Это микрооптимизация, но, на уровне архитектуры это важный нюанс, принцип хеширования - основа оптимизации.
Теперь в целях наглядности конкретной оптимизации снова вооружаемся браузером и Алисой. Просим её расчитать примерное время для новой концепции и наших градаций, радуемся результату и смакуем(эта радость будет недолгой):
@@ -260,6 +275,10 @@ typedef struct FXGradedMemoryPool {
**Использовать осторожно, нудятина!!!**
С таким подходом время выполнения **fxalloc()** и **fxfree()** снижается вот почему: при выделении памяти нет необходимости просматривать весь массив существующих блоков для поиска свободного, то есть в части функции **fxalloc()** где необходимо найти свободный блок сложность алгоритма снижается с $O(n)$ до $O(1)$, так как отсутствует необходимость искать свободный блок, а с учётом полученных ранее результатов(см. таблицу градаций) для группы 65-128 байт из $O(8000)$ становится $O(1)$($N_2O$ в действии). Радуем Алису кодом ниже, чувствуем себя Богами оптимизации:
<details>
<summary>Чтение промпта опасно для психического здоровья!</summary>
```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() {}
```
</details>
***
$^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 < Максималь
|**Прогноз:**| ∞ лет | Железо будет жить вечно… или пока не отключится блок питания|
|**Автор:**| ∞ терпения | Верит, что однажды всё заработает без танцев с бубном |
**Дополнительные выводы Алисы:**
* **Философский:** «Железо работает не благодаря, а вопреки всем законам физики и инженерии».
* **Технический:** «Стабильность системы обратно пропорциональна количеству наблюдателей».
* **Практический:** «Если оно работает — не трогай. Если не работает — выключи и включи. Если и это не помогло — шепни кулеру, что он лучший».
## Расчёт потоков
**Промпт("Ломаем мозг" Алисе):**
<details>
<summary style="font-weight:bold;">Слабонервным не смотреть!</summary>
<summary style="font-weight:bold;">YandexGPT 5.1 Pro(АлисаAI)©: Опасно для чтения, уровень абсурда 9/10!</summary>
```C
/**
@@ -645,13 +671,14 @@ void summon_teleporter_in(struct sockaddr_in* _SrvAddr) {
* @brief МАХИМАЛЬНО_ЛИМУЗИНОВ_ЗА_РАЗ -> защита от OOB
*
*/
///< YandexGPT 5.1 Pro(АлисаAI)©: Уровень абсурда 9/10
```
</details>
**Продолжаем для шифрования:**
<details>
<summary style="font-weight:bold;">Слабонервным не смотреть!</summary>
<summary style="font-weight:bold;">YandexGPT 5.1 Pro(АлисаAI)©: Опасно для чтения, уровень абсурда 10/10!</summary>
```C
/**
@@ -724,6 +751,9 @@ l2header* spell_teleport_unchant(void* _RawPacket, SessKey* _Key) {
**Теперь для БД и лога**
<details>
<summary style="font-weight:bold;">YandexGPT 5.1 Pro(АлисаAI)©: Опасно для чтения, уровень абсурда 11/10!</summary>
```C
/**
* @author всё ещё admin@felexdev.ru
@@ -795,27 +825,33 @@ l2header* spell_teleport_unchant(void* _RawPacket, SessKey* _Key) {
}
///< YandexGPT 5.1 Pro(АлисаAI)©: Уровень абсурда 11/10
```
</details>
**Добиваем Алису:**
<details>
<summary style="font-weight:bold;">Самая обыкновенная таблица</summary>
```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 промпта ;)
```
</details>
**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. Начнём с простейшего.
##
+3
View File
@@ -0,0 +1,3 @@
build
sandbox
+3
View File
@@ -0,0 +1,3 @@
cmake_minimum_required(VERSION 3.15)
project(tests)
add_executable(size_vs_index src/size_vs_index.cpp)