WIP plan.md for asvk
This commit is contained in:
@@ -0,0 +1,173 @@
|
||||
# Исследование алгоритма разрешения зависимостей в 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),
|
||||
$$
|
||||
|
||||
Полная сложность алгоритма холодного сравнения:
|
||||
|
||||
...
|
||||
|
||||
При попадании в кэш:
|
||||
|
||||
...
|
||||
Reference in New Issue
Block a user