7.4 KiB
Исследование алгоритма разрешения зависимостей в 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),
Полная сложность алгоритма холодного сравнения:
...
При попадании в кэш:
...