# Исследование алгоритма разрешения зависимостей в ALT RPM

## Замысел и структура статьи

Статья будет как решение одной формальной задачи. В ALT RPM пакет-потребитель задаёт множество
требуемых символов $R$ (`Requires`), а пакет-поставщик - множество предоставляемых
символов $P$ (`Provides`). Зависимость выполнима тогда и только тогда, когда

$$
R \subseteq P.
$$

Явное перечисление тысяч ELF-, Python- и файловых символов раздувает RPM-метаданные,
поэтому множества представлены компактными set-строками.

## 1. Постановка задачи и данные ALT Linux

Ввести обозначения для bpp(b), множеств, хэш функций(H), длин строк и т.д.

Проверяемое программой условие имеет вид

$$
H_b(R)\subseteq H_b(P).
$$

Отмечаем вероятностную природу: из $R\subseteq P$ следует
$H_b(R)\subseteq H_b(P)$, поэтому коллизия не создаёт ложного отказа. Обратное
неверно: отсутствующий символ может совпасть по хешу с символом из $P$ и дать
ложное принятие зависимости.

(Представить данные ниже табличкой)
Привести срез Sisyphus `x86_64 + noarch`: 47 367 пакетов, 14 761 `Provides`-отношение и 68 857
`Requires`-отношений. Для 68 198 реально сопоставимых пар медианы равны
$p=480$, $r=13$, $p/r=28.1$; p75 - 1886, 37 и 80; p90 - 6219, 104 и 257.
В 92.4% пар выполняется $p/r\ge 4$. Это к теме, почему рассматриваем разреженные множества.

## 2. Устройство существующей `set:`-строки

Даём схему формата:

```
массив строк
  | (Jenkins OAAT)
  v
массив хэшей
  | (qsort)
  v
отсортированный массив хэшей
  | (вычисление разницы между элементами)
  v
массив delta
  | (Rice-Golomb преобразование)
  v
битовый массив
  | (base62 преобразование)
  v
set-строка
```

Нужно отдельно разобрать заголовок, диапазоны `bpp` и `Mshift`, внешний префикс
`set:` и роль Base62: строка должна оставаться допустимым токеном версии RPM.
Полезна небольшая иллюстрация на 5-8 символах: исходные имена, хеши,
отсортированный массив, дельты, биты кода и итоговая строка.
Но. Это много альт-специфики, может настолько глубоко не стоит (хотя и не очень глубоко)

### 2.1. Хеширование и вероятность коллизий

! Всё ещё нет нормального анализа коллизий

Текущий код использует 32-битный Jenkins OAAT и оставляет $b$ бит. Для модели
равномерного независимого хеширования ожидаемое число столкнувшихся пар среди
$n$ различных символов равно

(будет мудрёная формула, теория)

В статье формулы дополняем разными табличками по реальным данным из Sisyphus: распределения $p,r,b$, ожидаемые коллизии, реальные.

(Другие хэши идут далее)

### 2.2. Кодирование Golomb-Rice

Для отсортированных значений $0\le x_1<\dots<x_n<N$ определить
$\delta_1=x_1$, $\delta_i=x_i-x_{i-1}$.

Занимаеи столько и столько бит. В реализации параметр выбирается из
$b$ и $n$ приблизительно как

$$
m=b-\lfloor\log_2 n\rfloor-1
$$

с ограничением допустимым диапазоном формата. При средней дельте
$\mathbb E\delta\approx 2^b/n$ это даёт ожидаемую длину порядка

...

### 2.3. Base62

Пояснить экзотичность Base62, его алфавит, принцип кодирования, Z-escape,

## 3. Построение `set:`-строк в `set.c`

(фактически его можно в 2 упихать)

Рассказать путь `set_new()` - `set_add()` - `set_fini()` и отдельно объяснить
сложные участки:

(а тут и нет сложного, всё в cmp запихали)
Можно рассказать о слитом энкодере, но это есть в переписанной части

В оригинальном варианте используется `qsort()`

Записать итоговую сложность построения:

...

И доп памяти:

...

## 4. Сравнение `set:`-строк

### 4.1. Обратное декодирование

Кратко пройти обратную цепочку:

```
set-строка
  | (обратное base62 преобразование)
  v
битовый массив
  | (обратное Rice-Golomb преобразование)
  v
массив delta
  | (вычисление изначальных значений)
  v
массив хэшей
```

Если `bpp` различается, более точное множество проецируется на меньшее число бит,
после чего снова удаляются дубликаты. (btw, тут есть сортировка слиянием, интересный момент)

### 4.2. Кэш декодированных множеств

В исходном `set.c` кэш содержит 256 записей (`CACHE_SIZE=256`), при вытеснении
использует позицию 243 (`PIVOT_SIZE=243`), `free()` и два `memmove()`. Ключ включает
короткий fingerprint, а окончательная проверка требует сравнения строки.

- что именно кэшируется;
- стоимость линейного поиска, `strcmp`, перемещений и аллокаций;
- слабое повторное использование при потоке десятков тысяч различных пар;

(всё надо сильно короче расписывать)

### 4.3. Проверка включения и «прыжок» по массивам

После декодирования задача сводится к двум возрастающим массивам. Базовый вариант

рассказ про IFLT4 и IFLT8

Худшая асимптотика остаётся

$$
T_{\subseteq}(p,r)=O(p+r),
$$

Полная сложность алгоритма холодного сравнения:

...

При попадании в кэш:

...

## 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. Вывод