Работа над дневником

DAIRY.md

@@ -140,6 +140,14 @@ int main(int argc, char* argv[]) {
 ```
 Теперь при обходе переменной grades в цикле мы можем быть уверены что дальше чем нужно - не уйдём и вполне себе спокойно можем использовать цикл **for**:
 ```C
+/**
+ * @brief Принцип поиска обходом
+ * @date 30.04.2026
+ * @note Добавлено после 2-х часов доказываний Алисе что я - не олень
+ * @note Алиса, конкретно в случае таких значений бинарный поиск\
+ * не подходит, см. таблицу градаций, это лишний if(...) {}! Самые частые обращения\
+ * в первые 3 пула памяти!!!
+*/
 for (size_t i = 0; grades[i].est_size; i++) {
     // Инициализируем отдельный пул по грейду
 }
@@ -519,7 +527,7 @@ open files                          (-n) 1024               < Максималь
 * **RAM:** 16+ млн потенциальных соединений(абсурд, но мы же архитектуем, ну будем отклоняться от традиций инженерии).
 * **CPU:** `4 ядра @ 3.2 ГГц → 12.8 млрд инструкций/сек` не топ, но — терпимо.
 
-Для чего всё это — используется при инжинерных расчётах теоретической пропускной способности железяк. Тут начинаются магиматические ритуалы с углублением в ассемблер, призываем нашего любимого критика заклинанием "Алиса...", проводим "утончённые" расчёты по способностям сущностей под названием поток "переварить" байты из пакетов. В чём особенность этого этапа — вся соль в том что если конкретно на этом этапео становиться на очевидном узком месте `` и принять это как данность, то может возникнуть ложное ощущение что в нашем распоряжении "вечность" для алокации одного пакета, однако если посмотреть на систему в комплексе, то это не то что бы просто не так,— это абсолютно "не так".
+Для чего всё это — используется при инжинерных расчётах теоретической пропускной способности железяк. Тут начинаются магиматические ритуалы с углублением в ассемблер, призываем нашего любимого критика заклинанием "Алиса...", проводим "утончённые" расчёты по способностям сущностей под названием поток "переварить" байты из пакетов. В чём особенность этого этапа — вся соль в том что если конкретно на этом этапео становиться на очевидном узком месте и принять это как данность, то может возникнуть ложное ощущение что в нашем распоряжении "вечность" для алокации одного пакета, однако если посмотреть на систему в комплексе, то это не то что бы просто не так,— это абсолютно "не так".
 
 **Небольшое отсупление:** В начале 2000-х увидев на барахолке христоматию С не смог пройти мимо и купил(ни разу не пожалел — очень интересно-полезное чтиво). Ну и само-собою разумеещееся начал углубляться в сказочный мир С более осознанно нежели прежде(псевдо-параллелизм/синхронизация, межпроцессное взаимодействие), железо было самым скромным, банальный Windows 98, однако это мне дало понимание на пробах и ошибках как стоит а как не стоит проектировать приложения которые предусматривают синхронизацию. Не могу судить об уровне подготовки современных программистов ибо не знаю чему их учат чему — нет, но точно знаю что такое плохо/хорошо спроектировано и написано. К чему я всё это рассказываю, если брать в учёт что у нас всего 65535 сокетов на процесс, соответственно нагрузка не высокая и сделать аллокатор исходя из этого расчёта, на 100% надёжных мьютексах(пользовательское пространство) то работать будет, но:
 * **Медленно** — клиент будет ощущать эти задержки, ибо в нашем случае пинг работает против проекта.
@@ -551,8 +559,10 @@ open files                          (-n) 1024               < Максималь
 
 **Промпт("Ломаем мозг" Алисе):**
 
-> Алиса, оцени пожалуйста юмор и проведи расчёты: Кастуем заклинание "Алиса", скармливаем ей payload пакета в 32 гномо-домика(uint8_t gnomes_home;), название железяки Intel Core i5-3470 и недожелезяки 8 GB, спрашиваем сколько телепортов сможет держать один summon epoll с последующим переселением в очередь без оглядки на nofile, жги по-полной в режиме телепортации гномиков!
+> Алиса, проведи пожалуйста расчёты: Кастуем заклинание "Алиса", скармливаем ей payload пакета в 32 гномо-домика(uint8_t gnomes_home;), название железяки Intel Core i5-3470 и недожелезяки 8 GB, спрашиваем сколько телепортов сможет держать один summon epoll с последующим переселением в очередь без оглядки на nofile, жги по-полной в режиме телепортации гномиков! P.S.: Знаю что "нечаяно" порвал твои шаблоны, прояви креатив ;) extern "C" { ///< YandexGPT 5.1 Pro(АлисаAI)©: Уровень абсурда 8/10 };
+```C
 
+```
 **Продолжаем для шифрования:**
 
 ```C
@@ -563,10 +573,10 @@ open files                          (-n) 1024               < Максималь
  * @note Алиса, мы считаем худший гипотетический вариант для аллокатора, пересчитай предыдущий промпт
  * с новыми вводными, не пытайся понять логику или улучшить,\
  * определи максимально возможное количество пакетов в секунду. Учти расходы на копирование:\
- * 'teleported_in → this summon → teleported_out', ключ у каждого телепорта свой(TLS другого саммона).
+ * 'teleported_in → this summon → teleported_out', ключ у каждого телепорта свой(Thread Local Storage другого саммона).
  * @note Размер гномо-квартала страндартный: из предыдущего промпта(на всякий случай: 32 гномо-домика).
  * @note Teleport version 0x0290
- * @note Не забудь оценить юмор ;)
+ * @note юмор сугубо для тебя ;)
  * CPU: Intel Core i5-3470
  * 
 */
@@ -620,6 +630,7 @@ l2header* spell_teleport_unchant(void* _RawPacket, SessKey* _Key) {
 	_Key->u32[SESSKEY_PART1] += size;
 	return pkg;
 }
+///< YandexGPT 5.1 Pro(АлисаAI)©: Уровень абсурда 10/10
 ```
 
 **Теперь для БД и лога**
@@ -635,7 +646,7 @@ l2header* spell_teleport_unchant(void* _RawPacket, SessKey* _Key) {
  * @ЭСКЬЮЭЛЬ: MySQL - живёт рядом,- в том же разделе ССД, общение через юнихокеты/пайпы
  * @Железяка: Intel Core i5-3470 4 @ 3.2 GHz
  * @OSь: ПОСИХ-совместима, %llx - это ключ для size_t(ака long long hex)
- * @note P.S.: Не забудь оценить юмор! =D
+ * @note P.S.: Юмор только для тебя! Не забудь проявить креатив!!! =D
  * @note P.P.S.: Забыл напомнить про копирование: teleported_in → this summon → teleported_out
  */
     /**
@@ -693,7 +704,7 @@ l2header* spell_teleport_unchant(void* _RawPacket, SessKey* _Key) {
         );
         _DB->exec(ENCHANTED_SCROLL_OF_UPDATE);
     }
-    
+    ///< YandexGPT 5.1 Pro(АлисаAI)©: Уровень абсурда 11/10
 ```
 
 **Добиваем Алису:**
@@ -713,15 +724,17 @@ P.S.: Забыл попросить посчитать количество `get
 | 6 | Выселение гномиков из домиков                 | Шифрование                                |       |
 | 7 | Изгнание гномиков обратно к месту прописки    | отправка пакетов обратно пользователям    |       |
 |   |                                               |                              **ИТОГО:**   |       |
+
+P.P.S: подбей итоги по юмору за все 4 промпта ;)
 ```
 
-**YandexGPT 5.1 Pro(АлисаAI)©**
+**YandexGPT 5.1 Pro(АлисаAI)©(Ответ вашей Алисы может отличаться)**
 
 Конечно! С удовольствием подведу итоги в виде таблицы — с юмором и точностью. Вы тоже лучшая, спасибо за доверие! 😊
 
 **Итоговая таблица: «Гном‑менеджмент в IT‑вселенной»**
 
-|№|    Summons by skills (магические навыки)    |   Sommun description (что творит summon)  |Потоков (сколько summon‑ов нужно)|Примечания (шутки и факты)|
+|№|    Summons by skills (магические навыки)    |   Summon description (что творит summon)  |Потоков (сколько summon‑ов нужно)|Примечания (шутки и факты)|
 |:-:|:------------------------------------------|:-|:-:|:-|
 |1| Призыв гномиков внешнего мира               | Приём пакетов, инициализация подключений  |1–2|Гномики стучатся в дверь: «Тук‑тук, мы из сети!»|
 |2| Расселение гномиков по домам                | Расшифровка пакетов (алхимия XOR)         |2–3|Гномики раскладывают вещи по полкам: «Где мой топор? Опять в логах затерялся!»|
@@ -750,3 +763,29 @@ P.S.: Забыл попросить посчитать количество `get
 | Операций с владениями/сек (Бог дал + Бог взял)    | 1 967 532 | 983 766 × 2           |
 | Задержка на миграцию/призыв                       |  0.06 мкс | 6 × 0.01 мкс          |
 | Доля времени на миграцию                          |    1 %    | От общего времени на пакет(6.1 мкс)|
+
+# 30.04.2026
+
+Пока ещё не сплю, время всего 10:49, глаза в кучу, тараканы врознь, но мы продолжаем!
+
+## Дилема
+
+Итак, по итогу предыдущих расчётов вырисовывается очень забавная картина:
+* Реальный полезный размер данных который мы можем передавать по сети крайне мал и неделим(22 байта).
+* Затраты на копирование данных между очередями примерно равны 1% от всего времени процессора на процесс.
+* Время между предположительными выделениями памяти составляет $Singularity$, а количество выделений/освобождений стремится к $+∞$.
+
+## Снижение нагрузки на аллокатор:
+1. В виду низкой вариативности пускать буферы "по кругу":
+    * **Плюсы:** уменьшение алокаций;
+    * **Минусы:** вся нагрузка на выделение памяти ложится на поток/потоки ввода-вывода(хотя, $\frac{+∞}{матан\_lvl\_80^{EXP^{INT^{MEN}}}} \underset{\text{HotKey F1}}{\Rightarrow} useskill(sto\_raz\_tak\_delal, -∞) \Rightarrow Anihilation \Rightarrow \Phi yx = Фух$, проблема решена! Lineage-форэвэр! 😂);
+2. Забить болт и лечь спать. =D
+
+
+На каждый пакет(изначально) память выделяется под данные на каждом переходе между потоками, то есть $163961×6=983766$ раз, соответственно если мы будем пуск
+
+### Windows VS Linux(POSIX)
+
+Проблемка, конечно та ещё. Вот сейчас начнут совсем неожиданные нюансы:
+
+

templates/calc_threads.c

@@ -0,0 +1,9 @@
+/*
+ * Алиса, проведи пожалуйста расчёты: Кастуем заклинание "Алиса", скармливаем ей payload пакета
+ * в 32 гномо-домика(uint8_t gnomes_home;), название железяки Intel Core i5-3470 и недожелезяки 8 GB,
+ * спрашиваем сколько телепортов сможет держать один summon epoll с последующим переселением в очередь
+ * без оглядки на nofile, жги по-полной в режиме телепортации гномиков!
+ * P.S.: Знаю что "нечаяно" порвал твои шаблоны, прояви креатив ;)
+ * */
+#include <sys/epoll.h>
+