Всё ещё дневник =)
This commit is contained in:
@@ -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. Начнём с простейшего.
|
||||
|
||||
##
|
||||
|
||||
@@ -0,0 +1,3 @@
|
||||
build
|
||||
sandbox
|
||||
|
||||
@@ -0,0 +1,3 @@
|
||||
cmake_minimum_required(VERSION 3.15)
|
||||
project(tests)
|
||||
add_executable(size_vs_index src/size_vs_index.cpp)
|
||||
Reference in New Issue
Block a user