article plan

This commit is contained in:
2026-08-11 15:12:52 +03:00
parent 53332b0f62
commit ac894a86b4
+68
View File
@@ -171,3 +171,71 @@ $$
При попадании в кэш:
...
## 5. Оптимизации с сохранением текущего формата
### 5.1. Новый кэш
Заменить небольшой кэш на два раздельных bucketed LRU для `Provides` и `Requires`, увеличить вместимость. Хранить длину и более сильный fingerprint, избегать лишних
`strlen`/`strcmp`, `free` и полных `memmove`. Отдельно убрать повторные `realloc` при построении входных наборов.
Проверить cold, warm, поток меняющихся `Requires` к одному `Provides` и поток
полностью уникальных пар.
### 5.2. Radix sort
Для больших наборов заменить $O(n\log n)$ `qsort()` стабильной LSD radix sort по
байтам хеша. Число проходов
$$
k=\left\lceil\frac b8\right\rceil,
\qquad T_{\mathrm{radix}}=O(kn),
$$
дополнительная память $O(n+256)$. Для малых $n$ оставить `qsort()`; в `set9.c`
порог равен 128.
### 5.3. Оптимальный проход по массивам
Сделать адаптивный алгоритм:
- равные мощности - `memcmp` и быстрый вывод «равны/несравнимы»;
- близкие мощности - обычное линейное слияние;
- $p/r$ велико - galloping/jump search с монотонной нижней границей;
- немедленный выход при первом отсутствующем хеше.
## 6. Варианты со сменой формата или API
### 6.1. Roaring Bitmap - отрицательный результат
Равномерно распределённые хеши не образуют плотных диапазонов, ради которых создан
Roaring. Для 1000 символов при `bpp=32` получено:
| Представление | Длина строки | Cold compare | Warm compare |
| -------------------- | -----------: | -----------: | -----------: |
| Golomb/Base62 `set9` | 3994 | 293.87 мкс | 5.24 мкс |
| raw Roaring/hex | 19 924 | 1321.17 мкс | 399.20 мкс |
То есть строка длиннее в 4.99 раза, cold-сравнение медленнее в 4.50 раза, warm -
в 76.14 раза. Zstd уменьшал строку до 14 126 символов, но оставлял её в 3.54 раза
длиннее `set9`; в соответствующем прогоне cold- и warm-сравнение проиграли в 4.96
и 101.86 раза. Этот вариант нужен в статье как важный отрицательный эксперимент.
### 6.2. Прямые хеши и Base64
В формате D1 отсортированные усечённые хеши хранятся фиксированной шириной без
дельт и Golomb-кода, затем упаковываются в Base64. Теоретическая длина payload:
...
Для 1000 символов и `bpp=32` строка выросла с 3994 до 5340
символов (+33.7%). Приложить разные результаты тестов. (тесты бы прогнать снова)
Отдельно про увеличение размера и влияние на apt команды от этого
выводы насчёт формата
### 6.3. Альтернативные хэш функции
тут про разные хэши, их быстрдействие и тесты коллизий
## 8. Вывод