Compare commits
10
Commits
548159e5ea
...
main
| Author | SHA1 | Date | |
|---|---|---|---|
 krosh
|
4ebf8fe4a8 | ||
|
krosh
|
fe2edcea5c | ||
|
krosh
|
1cca8e5c88 | ||
|
krosh
|
e38d1365cd | ||
|
krosh
|
9e9c99fc2b | ||
|
krosh
|
87b588f63e | ||
|
krosh
|
8a53f2186b | ||
|
krosh
|
1fac5b277d | ||
|
krosh
|
7106d0c9ea | ||
|
krosh
|
f86537626a |
@@ -2,6 +2,9 @@
|
||||
|
||||
Коэффициент считается как отношение времени базовой реализации к времени проверяемой реализации. Значение больше `1×` означает ускорение, меньше `1×` — замедление.
|
||||
|
||||
- `original set.c` - код текущего `lib/set.c` в `rpm`/`rpm-build`
|
||||
- `set9.c` - drop-in замена оригинального `lib/set.c`.
|
||||
|
||||
## original set.c w/out optimizations
|
||||
|
||||
функция `decode_set` идёт по пути функций:
|
||||
|
||||
@@ -0,0 +1,210 @@
|
||||
|
||||
\author{Дмитрий Гудов}
|
||||
|
||||
% Город
|
||||
\city{Москва}
|
||||
|
||||
% Организация
|
||||
\affiliation{ALT Linux}
|
||||
|
||||
% Название проекта, которому посвящён доклад (необязательно,
|
||||
% но желательно).
|
||||
% \projecttitle{set-строки в rpm}
|
||||
% Сайт(ы) проекта
|
||||
\projecturl{\url{https://github.com/kr0sh512/alt-rpm-set-version}}
|
||||
|
||||
\title{Исследование и улучшение механизма работы \texttt{set}-строк в ALT RPM}
|
||||
\maketitle
|
||||
|
||||
\begin{abstract}
|
||||
В ALT RPM версии зависимостей \texttt{set:} кодируют множества ELF-символов и
|
||||
позволяют проверять совместимость библиотек точнее, чем по одному SONAME.
|
||||
В работе разобраны формат строк и оптимизации исходного \texttt{lib/set.c},
|
||||
описана совместимая реимплементация \texttt{set9.c} и приведены результаты её
|
||||
проверки на метаданных Sisyphus и в симуляциях APT. Отдельно рассмотрены
|
||||
несовместимые альтернативные форматы и замена хэш-функции.
|
||||
\end{abstract}
|
||||
|
||||
\keywords{ALT RPM, ELF-символы, set:version, Golomb--Rice}
|
||||
|
||||
\begingroup
|
||||
\setlength{\emergencystretch}{3em}
|
||||
|
||||
\section*{1. Зачем нужны set-строки}
|
||||
|
||||
Обычная зависимость от версии библиотеки не гарантирует, что в ней остались все нужные программе символы: символ можно удалить, не сменив SONAME, а одинаковые SONAME могут скрывать разные наборы экспортов. Поэтому ALT RPM использует версии зависимостей вида \texttt{set:<encoded-set>}. Для \texttt{Provides} такая строка описывает символы, предоставляемые библиотекой, а для \texttt{Requires} --- символы, которые конкретный потребитель требует от неё. В такой конфигурации сравниваются не номера версий, а включение множеств: все хэши символов из \texttt{Requires} должны присутствовать в \texttt{Provides}.
|
||||
|
||||
Гарантия вероятностная, поскольку вместо полных имён символов хранятся усечённые хэши. Ложное отрицание невозможно: совпадающее имя всегда даёт то же хэш-значение. Возможны ложные положительные результаты, если разные имена имеют одинаковый усечённый хэш.
|
||||
|
||||
\section*{2. Структура set-строки}
|
||||
|
||||
Set-строка формируется следующим образом:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Список символов формируется автодепами \texttt{rpm-build}. Для \texttt{Provides} это отфильтрованные экспортируемые базовые имена ELF-символов; для \texttt{Requires} \texttt{ldd --bindings} связывает сильные неопределённые символы с конкретной библиотекой.
|
||||
\item Для каждого имени вычисляется Jenkins OAAT; при формировании строки оставляются младшие \texttt{bpp} бит хэша. Допустимый диапазон \texttt{bpp} --- от 10 до 32.
|
||||
\item Массив хэшей сортируется, повторы удаляются, а абсолютные значения заменяются дельтами между соседними значениями.
|
||||
\item Для кодирования Golomb--Rice вычисляется параметр \texttt{Mshift = bpp - log2(cnt) - 1}; затем он ограничивается диапазоном 7--31 так, чтобы \texttt{Mshift < bpp}.
|
||||
\item Массив дельт сжимается кодировкой Golomb--Rice, а битовый поток преобразуется в Base62-строку.
|
||||
\end{enumerate}
|
||||
|
||||
При формировании строки \texttt{Requires} точность \texttt{bpp} выбирается по числу символов соответствующей предоставляющей библиотеки, а не по числу требуемых символов. Это сохраняет одинаковую точность представления для обеих сторон зависимости и уменьшает риск коллизий в малом множестве \texttt{Requires}.
|
||||
|
||||
Итоговая строка имеет вид:
|
||||
|
||||
\begin{verbatim}
|
||||
set:<bpp_char><Mshift_char><base62-полезная нагрузка>
|
||||
\end{verbatim}
|
||||
|
||||
\begin{verbatim}
|
||||
bpp_char = bpp - 7 + 'a'
|
||||
Mshift_char = Mshift - 7 + 'a'
|
||||
\end{verbatim}
|
||||
|
||||
Краткая схема:
|
||||
|
||||
\begin{verbatim}
|
||||
массив строк
|
||||
| (Jenkins OAAT)
|
||||
v
|
||||
массив усечённых хэшей -- сортировка и удаление повторов
|
||||
| (разности соседних значений)
|
||||
v
|
||||
массив дельт
|
||||
| (преобразование Golomb--Rice)
|
||||
v
|
||||
битовый поток
|
||||
| (Base62)
|
||||
v
|
||||
set-строка
|
||||
\end{verbatim}
|
||||
|
||||
\subsection*{Механизм сравнения set-строк}
|
||||
|
||||
Для проверки включения множества символов \texttt{Requires} в множество \texttt{Provides} выполняется обратное декодирование:
|
||||
|
||||
\begin{verbatim}
|
||||
set-строка
|
||||
| (обратное Base62-преобразование)
|
||||
v
|
||||
битовый поток
|
||||
| (обратное преобразование Golomb--Rice)
|
||||
v
|
||||
массив дельт
|
||||
| (накопление дельт)
|
||||
v
|
||||
отсортированный массив усечённых хэшей
|
||||
\end{verbatim}
|
||||
|
||||
Если точности строк различаются, значения приводятся к минимальному \texttt{bpp} из двух строк. После проекции сохраняются сортировка и уникальность: части массива по разные стороны удаляемого старшего бита сливаются с удалением повторов. Затем включение одного отсортированного множества усечённых хэш-значений в другое проверяется линейным проходом с пропусками.
|
||||
|
||||
\section*{3. Практическая реализация}
|
||||
|
||||
Несмотря на описанную структуру set-строки, в текущем \texttt{lib/set.c} применяется множество оптимизаций, направленных на ускорение \texttt{rpmsetcmp(const char *set1, const char *set2)}. В рабочем вызове первым аргументом передаётся \texttt{Provides}, вторым --- \texttt{Requires}; результат \texttt{1} означает строгое включение первого множества во второе, \texttt{0} --- равенство, а \texttt{-1} и \texttt{-2} --- обратное включение и несравнимость соответственно.
|
||||
|
||||
\subsection*{3.1. Слитый декодер}
|
||||
|
||||
Вместо последовательного декодирования Base62 и Golomb--Rice применяется функция \texttt{decode\_base62}\allowbreak\texttt{\_golomb()}, объединяющая оба этапа. Она считывает Base62-полезную нагрузку парами символов, с помощью заранее вычисленной таблицы получает биты, накапливает блоки до 24 бит и сразу декодирует значения Golomb--Rice. После этого восстанавливаются абсолютные значения из дельт.
|
||||
|
||||
Роль этой оптимизации подтверждается отдельной контрольной серией: вариант без оптимизированного декодера расходовал в APT-симуляциях в 1,47--2,82 раза больше суммарного процессорного времени, чем исходный \texttt{set.c}.
|
||||
|
||||
\subsection*{3.2. Кэширование \texttt{Provides} set-строк}
|
||||
|
||||
При передаче первого параметра в \texttt{rpmsetcmp()} его строка кэшируется. Исходная реализация использует массив из 256 записей, содержащих короткий отпечаток, исходную строку и декодированный массив хэшей; совпадение отпечатка подтверждается полным сравнением строки. При попадании запись перемещается в начало двумя вызовами \texttt{memmove()}; при заполнении кэша последняя запись освобождается, а новая помещается в позицию 243. Поэтому этот кэш близок к LRU, но не является строгим LRU.
|
||||
|
||||
Кэшируется только первый операнд, а второй декодируется при каждом сравнении. Следовательно, попадание в кэш устраняет не всё сравнение, а только повторное декодирование \texttt{Provides}; нормализация \texttt{bpp} также выполняется заново.
|
||||
|
||||
\subsection*{3.3. Быстрое сравнение включения множеств символов}
|
||||
|
||||
После получения отсортированных и приведённых к одинаковому \texttt{bpp} массивов хэшей необходимо проверить включение множеств. Как правило, множество \texttt{Requires} разрежено относительно \texttt{Provides}. Для этого \texttt{lib/set.c} использует макросы \texttt{IFLT4} и \texttt{IFLT8}: они делают прыжки на 4 или 8 элементов и уточняют позицию меньшими шагами. Вариант \texttt{IFLT8} выбирается при \texttt{len(Provides) >= 16 * len(Requires)}, в остальных случаях используется \texttt{IFLT4}.
|
||||
|
||||
Фиксированные шаги являются компромиссом между простотой и числом сравнений. Они хорошо работают для разреженных требований, но не учитывают точное отношение размеров множеств.
|
||||
|
||||
\section*{4. Совместимая реимплементация}
|
||||
|
||||
Для упрощения сопровождения была создана совместимая с форматом и публичным API реализация \texttt{set9.c}. В \texttt{set9.c} были реализованы следующие изменения.
|
||||
|
||||
\subsection*{4.1. Потоковое кодирование и хранение символов}
|
||||
|
||||
Энкодер \texttt{set9.c} передаёт значения по цепочке «хэш --- дельта --- Golomb--Rice --- Base62» без промежуточных массивов битов и дельт. Вместо отдельных выделений памяти под каждое имя используется растущая строковая арена, а в массиве символов хранятся смещения. Это позволет существенно уменьшить число вызовов \texttt{malloc()}.
|
||||
|
||||
\subsection*{4.2. Сортировка}
|
||||
|
||||
Для наборов меньше 128 значений сохраняется \texttt{qsort()}, а для больших используется стабильная побайтовая LSD radix sort. Число проходов равно \texttt{ceil(bpp/8)} и не превышает четырёх; дополнительная память имеет размер \texttt{O(n + 256)}.
|
||||
|
||||
\subsection*{4.3. Изменённый кэш и декодер}
|
||||
|
||||
В новой реализации используются два независимых кэша по 512 записей --- по одному для каждого операнда. Поиск выполняется через хэш-бакеты, а двусвязный LRU-список перемещает запись за \texttt{O(1)}. Ключ включает исходную строку и целевой \texttt{bpp}, поэтому результат нормализации можно повторно использовать.
|
||||
|
||||
Потоковый декодер использует 64-битный аккумулятор и более простую таблицу Base62. Для сравнения равных по размеру множеств применяется \texttt{memcmp()}, а для неравных проверяется только потенциальное включение меньшего в большее; разреженный случай использует монотонный поиск с шагом, зависящим от отношения размеров.
|
||||
|
||||
\subsection*{4.4. Проверка корректности и производительности}
|
||||
|
||||
\texttt{set9.c} был собран с \texttt{-Wall -Wextra -Werror}; встроенный \texttt{SELF\_TEST} успешно проверил хэширование, сортировку, кодирование и декодирование, метаданные, понижение \texttt{bpp}, включение, кэш, построитель и API. На снимке Sisyphus для \texttt{x86\_64/noarch} от 21 августа 2026 года проверены 68\,494 пары \texttt{set:} с одинаковым capability: 232 пары равны, в 68\,260 случаях \texttt{Provides} строго содержит \texttt{Requires}, а две несравнимые пары \texttt{python3(ast)} дополнительно имеют обычный unversioned \texttt{Provides}. С учётом 661 такого unversioned \texttt{Provides} все 69\,153 set-требования снимка удовлетворяются.
|
||||
|
||||
Для производительности сравнивались две локальные сборки \texttt{librpm}: исходная реализация и версия с описанными изменениями. Замеры выполнялись на одинаковых симуляционных командах \texttt{apt-get}. В таблице приведены средние процессорные времена. Коэффициент равен отношению времени исходной реализации к времени изменённой: значение больше единицы означает ускорение, меньше единицы --- замедление.
|
||||
|
||||
\begin{center}
|
||||
\begingroup
|
||||
\scriptsize
|
||||
\setlength{\tabcolsep}{2pt}
|
||||
\begin{tabular}{@{}lrrrrrr@{}}
|
||||
\hline
|
||||
Команда & \shortstack{\texttt{set.c}\\user, с} & \shortstack{\texttt{set.c}\\system, с} & \shortstack{\texttt{set9.c}\\user, с} & \shortstack{\texttt{set9.c}\\system, с} & \shortstack{Коэффициент\\по user} & \shortstack{Коэффициент\\по user+system} \\
|
||||
\hline
|
||||
\texttt{-s check} & 0.453 & 0.033 & 0.503 & 0.040 & 0.901$\times$ & 0.896$\times$ \\
|
||||
\texttt{-s autoremove} & 0.763 & 0.040 & 0.810 & 0.040 & 0.942$\times$ & 0.945$\times$ \\
|
||||
\texttt{-s install rpm-build} & 1.210 & 0.050 & 1.283 & 0.050 & 0.943$\times$ & 0.945$\times$ \\
|
||||
\texttt{-s install openuds-server} & 3.747 & 0.080 & 3.897 & 0.083 & 0.962$\times$ & 0.961$\times$ \\
|
||||
\texttt{-s install password-store} & 1.233 & 0.050 & 1.310 & 0.050 & 0.941$\times$ & 0.944$\times$ \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\endgroup
|
||||
\end{center}
|
||||
|
||||
Во всех пяти завершённых сценариях \texttt{set9.c} медленнее исходной реализации: суммарное процессорное время увеличилось на 4,0--11,6\%. Таким образом, упрощённый декодер с улучшениями сортировки и кэша не компенсировали стоимость более сложного декодера в данной APT-нагрузке. Однако, данная реализация остаётся значительно быстрее работы оригинального \texttt{set.c} с декодированием "в лоб".
|
||||
|
||||
\section*{5. Прочие исследования}
|
||||
|
||||
В данной главе собраны исследования, которые не вошли непосредственно в совместимую реализацию, однако важны своими идеями и результатами. Форматы этого раздела несовместимы с существующими \texttt{set:}-строками и требуют регенерации метаданных.
|
||||
|
||||
\subsection*{5.1. Хранение хэшей без Golomb--Rice}
|
||||
|
||||
Первое направление --- отказаться от дельт и Golomb--Rice и хранить отсортированные усечённые хэши почти напрямую в Base64. Это уменьшает стоимость декодирования, но увеличивает строку. В микротесте с 1000 предоставляемыми и 500 требуемыми символами при \texttt{bpp=32} длина строки выросла с 3994 до 5340 символов. Построение строки ускорилось: \texttt{set\_fini} занял 105,09 вместо 147,45 мкс. Холодное сравнение заняло 113,04 вместо 129,67 мкс (0,87$\times$ времени \texttt{set9}), а прогретое --- 1,04 вместо 2,99 мкс (0,35$\times$).
|
||||
|
||||
Однако результат зависит от нагрузки: при одном требуемом символе прогретое сравнение прямого формата заняло 1,02$\times$ времени \texttt{set9}.
|
||||
|
||||
Также был рассмотрен Roaring Bitmap. В проверенном прототипе на разреженных усечённых хэшах он дал более длинные строки и более медленное сравнение: строка выросла до 19\,924 символов, холодное сравнение стало в 4,50 раза, а прогретое --- в 76,14 раза медленнее \texttt{set9}. Сжатие zstd сократило строку до 14\,126 символов, но холодное и прогретое сравнения остались в 4,96 и 101,86 раза медленнее.
|
||||
|
||||
\subsection*{5.2. Тестирование хэш-функций}
|
||||
|
||||
Отдельно проверялась идея заменить Jenkins OAAT на CityHash32 или XXH32. На фиксированных случайных байтовых строках, медиана трёх запусков, Jenkins уступал: для 16 байт --- 22,330 нс/хэш; CityHash32 --- 10,402; XXH32 --- 7,792. Для 1024 байт значения составили 1796,485, 232,598 и 184,234 нс/хэш соответственно.
|
||||
|
||||
Однако скорость отдельной хэш-функции не описывает её качества на данных,
|
||||
характерных для \texttt{set:}-строк. Поэтому для Jenkins OAAT, XXH64 и t1ha2
|
||||
была измерена вероятность единицы в каждом из младших 32 битов хэша на корпусе
|
||||
из 577\,509 уникальных C++ ABI-символов, извлечённых из 259 ELF-файлов пяти
|
||||
пакетов ALT p11. Корпус намеренно содержит близкие по префиксу имена: 99,60\%
|
||||
символов имеют с другим символом общий префикс длиной не менее 12 знаков, а
|
||||
95,05\% --- не менее 24 знаков. Среднее отклонение вероятности единицы в
|
||||
выходном бите от $0{,}5$ равно 0,0475 процентного пункта для Jenkins OAAT, 0,0431 для XXH64 и
|
||||
0,0615 для t1ha2; максимальное отклонение одного бита --- 0,167, 0,122 и
|
||||
0,188 процентного пункта соответственно. Следовательно, все три функции
|
||||
достаточно равномерно смешивают проверенный корпус; только по этой метрике
|
||||
замена Jenkins OAAT не получает убедительного обоснования.
|
||||
|
||||
Следовательно, в проверенной метрике устойчивого преимущества замены Jenkins не обнаружено. Кроме того, новая хэш-функция изменила бы все значения в wire-format и потребовала бы новой версии формата и пересоздания репозиторных метаданных.
|
||||
|
||||
\section*{6. Итоги}
|
||||
|
||||
Работа позволила восстановить назначение и инварианты \texttt{set:}-формата, описать пути исходного \texttt{lib/set.c} и подготовить совместимую реализацию \texttt{set9.c}. Проверка на Sisyphus и \texttt{SELF\_TEST} подтверждают корректную обработку исследованного корпуса и публичного API. Вместе с тем APT-измерения показали отрицательный результат по производительности: более читаемая и структурированная реализация не превзошла специализированный декодер исходного кода.
|
||||
|
||||
Эксперименты с прямым хранением хэшей, Roaring Bitmap и альтернативными хэш-функциями уточнили границы дальнейшей оптимизации.
|
||||
|
||||
\endgroup
|
||||
|
||||
|
||||
%%% Local Variables:
|
||||
%%% mode: latex
|
||||
%%% TeX-master: "../main"
|
||||
%%% End:
|
||||
@@ -184,7 +184,338 @@ B=\sum_{i=1}^{n}\ell_i
|
||||
\end{center}
|
||||
\end{table}
|
||||
|
||||
После сортировки получается массив $(255,280,460,711,758)$, а после вычисления разностей --- $(255,25,180,251,47)$. Для $n=5$ формула даёт $m=7$; полученный 43-битный поток преобразуется в payload \texttt{ZvpACXZy}. Параметрам $b=10$ и $m=7$ соответствуют заголовочные символы \texttt{d} и \texttt{a}, поэтому итоговая строка равна \texttt{set:daZvpACXZy}. Пример показывает, что строка содержит достаточно данных для восстановления упорядоченного множества усечённых хешей, но не исходных имён символов.
|
||||
После сортировки получается массив $(255,280,460,711,758)$, а после вычисления разностей --- $(255,25,180,251,47)$. Для $n=5$ формула даёт $m=7$; полученный 43-битный поток преобразуется в payload \texttt{ZvpACXZy}. Параметрам $b=10$ и $m=7$ соответствуют заголовочные символы \texttt{d} и \texttt{a}, поэтому итоговая строка равна \texttt{set:daZvpACXZy}.
|
||||
|
||||
\section{Построение \texttt{set:}-строк в \texttt{set.c}}
|
||||
\label{CONSTRUCTION}
|
||||
|
||||
Благодаря сценариям автозависимостей \texttt{rpm-build} утилита \texttt{mkset} получает символы из ELF-файлов и далее использует \texttt{lib/set.c}, вызывая интерфейс построения множества:
|
||||
\[
|
||||
\texttt{set\_new()}\ \longrightarrow\
|
||||
\texttt{set\_add()}\ \longrightarrow\
|
||||
\texttt{set\_fini()}.
|
||||
\]
|
||||
|
||||
Функция \texttt{set\_new()} создаёт пустую структуру \texttt{struct set}. В исходной реализации она представляет собой растущий массив пар «указатель на строку --- хеш». Функция \texttt{set\_add()} увеличивает ёмкость массива блоками по 1024 элемента и копирует каждое имя отдельным вызовом \texttt{xstrdup()}. На этом этапе хеши ещё не вычисляются, поэтому один объект можно финализировать с заданным значением \texttt{bpp}.
|
||||
|
||||
Основную работу выполняет \texttt{set\_fini()}. Её действия следуют в фиксированном порядке:
|
||||
\begin{enumerate}
|
||||
\item проверяется непустота множества и условие $10\leq b\leq32$;
|
||||
\item для каждого имени вычисляется Jenkins OAAT и применяется маска из $b$ младших бит;
|
||||
\item массив пар сортируется стандартной функцией \texttt{qsort()} по хеш-значению;
|
||||
\item для равных хешей различных имён выводится предупреждение о коллизии;
|
||||
\item хеши копируются в числовой массив, а повторяющиеся значения удаляются;
|
||||
\item массив кодируется последовательно как дельты, код Голомба--Райса и Base62;
|
||||
\item сформированная строка копируется в динамическую память и возвращается вызывающей стороне.
|
||||
\end{enumerate}
|
||||
|
||||
Удаление повторов необходимо в двух случаях. Во-первых, одно имя может несколько раз попасть во входной поток. Во-вторых, различные имена могут совпасть после усечения хеша. Для семантики $H_b(S)$ оба случая означают один элемент множества. При этом предупреждение о коллизии формируется до удаления повторов, пока реализации ещё доступны исходные строки и можно различить совпадение имён от совпадения их хешей.
|
||||
|
||||
Оценим вычислительную сложность. Пусть $L$ --- суммарная длина всех входных имён, $n$ --- их количество, а $B$ --- длина потока Голомба--Райса в битах. Хеширование требует $O(L)$ операций, сортировка --- $O(n\log n)$ сравнений, линейные проходы сортированного массива --- $O(n)$, кодирование --- $O(B)$. Поэтому для исходного варианта
|
||||
\[
|
||||
T_{\mathrm{build}}=O(L)+O(n\log n)+O(B).
|
||||
\]
|
||||
Хранимые копии строк, массив пар, массив уникальных хешей, битовый буфер и результирующая строка дают дополнительную память порядка
|
||||
\[
|
||||
M_{\mathrm{build}}=O(L+n+B).
|
||||
\]
|
||||
Главным асимптотическим слагаемым для больших наборов остаётся \texttt{qsort()}, тогда как большое число отдельных копирований строк и наличие промежуточного битового массива влияют на постоянные затраты. Это определяет два независимых направления дальнейшего улучшения: замена сортировки для крупных множеств и потоковое кодирование без промежуточных представлений. При этом любые изменения должны сохранять байтовую совместимость формата.
|
||||
|
||||
\section{Сравнение \texttt{set:}-строк}
|
||||
\label{COMPARISON}
|
||||
|
||||
Функция \texttt{rpmsetcmp()} получает две строки и определяет отношение включения между закодированными множествами. В штатном пути RPM первым операндом передаётся \texttt{Provides}, а вторым --- \texttt{Requires}. Возвращаемые значения различают четыре результата: 1, если первое множество строго содержит второе; 0 при равенстве; $-1$, если первое множество строго содержится во втором; $-2$, если множества несравнимы по включению. Ошибки декодирования первого и второго операндов отображаются соответственно в коды $-3$ и $-4$.
|
||||
|
||||
\subsection{Обратное декодирование и нормализация точности}
|
||||
|
||||
После удаления необязательного префикса \texttt{set:} проверяются параметры $b$ и $m$, а затем выполняется обратная цепочка преобразований
|
||||
\[
|
||||
\begin{aligned}
|
||||
\text{Base62-строка}
|
||||
&\longrightarrow \text{битовый поток}
|
||||
\longrightarrow \text{дельты Голомба--Райса},\\
|
||||
&\longrightarrow \text{возрастающий массив хешей}.
|
||||
\end{aligned}
|
||||
\]
|
||||
Логически это преобразование обратно рассмотренному в разд.~\Ref{FORMAT}. Однако исходный \texttt{lib/set.c} не создаёт отдельный битовый массив: функция \texttt{decode\_base62\_golomb()} объединяет первые две стадии. Она считывает обычные символы попарно, преобразует их предварительно вычисленной таблицей и обрабатывает блоки до 24 бит. Частное и остаток кода Голомба--Райса восстанавливаются непосредственно из этих блоков. После этого единственный линейный проход суммирует дельты и получает исходные усечённые хеши.
|
||||
|
||||
Две строки могут иметь разные значения \texttt{bpp}. Сравнение выполняется при общей точности
|
||||
\[
|
||||
b_* = \min(b_P,b_R).
|
||||
\]
|
||||
Для этого более точный массив последовательно проецируется на один бит вниз. На одном шаге применяется отображение
|
||||
\[
|
||||
\pi_t(x)=x\bmod 2^t.
|
||||
\]
|
||||
После удаления старшего бита исходный возрастающий массив распадается на две возрастающие части. Обе части сливаются с сохранением возрастания элементов, а появившиеся совпадения удаляются. Поэтому после понижения точности сохраняются одновременно сортировка и представление множества без повторов. При разности точностей $d=|b_P-b_R|$ слияние повторяется $d$ раз.
|
||||
|
||||
В результате сравниваются два возрастающих массива
|
||||
\[
|
||||
\widehat P=H_{b_*}(P),\qquad
|
||||
\widehat R=H_{b_*}(R).
|
||||
\]
|
||||
|
||||
Понижение \texttt{bpp} необходимо, так как сравнение множеств хэшей отличающейся точности невозможно.
|
||||
|
||||
\subsection{Кэш декодированных множеств}
|
||||
|
||||
Декодирование длинной строки существенно дороже проверки нескольких уже готовых целых значений. Кроме того, один поставщик обычно сопоставляется с требованиями нескольких пакетов. Поэтому исходная реализация кэширует декодированный первый операнд, то есть в обычном вызове множество \texttt{Provides}.
|
||||
|
||||
Кэш состоит из двух массивов по 256 элементов: коротких отпечатков и указателей на записи. Отпечаток формируется из трёх байтов строки и служит только предварительным фильтром. Корректность попадания подтверждается полным сравнением исходной строки. Запись одним выделением памяти хранит декодированный массив, его длину и копию строки.
|
||||
|
||||
Поиск выполняется линейно. При попадании запись перемещается в начало двумя вызовами \texttt{memmove()}. Если кэш заполнен, последняя запись освобождается, а новый элемент вставляется на позицию 243 (\texttt{PIVOT\_SIZE}), после чего хвост обоих массивов также сдвигается. Такая схема приближает LRU-политику, но не является строгим LRU: новая, ещё не подтвердившая полезность запись помещается около конца кэша, тогда как повторно использованная попадает в начало.
|
||||
|
||||
Второй операнд исходная реализация каждый раз декодирует во временный массив на стеке. Кроме того, кэш хранит результат при исходном \texttt{bpp}; если для конкретного сравнения его требуется понизить, проекция вычисляется заново. Следовательно, кэш особенно полезен для потока сравнений одного \texttt{Provides} с разными \texttt{Requires} одинаковой точности, но не устраняет стоимость декодирования требований и нормализации.
|
||||
|
||||
\subsection{Проверка включения возрастающих массивов}
|
||||
|
||||
Наивная проверка $\widehat R\subseteq\widehat P$ последовательно продвигает указатель по $\widehat P$ до очередного требуемого значения. Исходная реализация одновременно вычисляет оба отношения включения с помощью флагов \texttt{ge} и \texttt{le}. Это позволяет одним проходом получить все четыре значения публичного API, а не только ответ на типичный для RPM вопрос $\widehat R\subseteq\widehat P$.
|
||||
|
||||
Для ускорения поиска используются макросы \texttt{IFLT4} и \texttt{IFLT8}. Первый перемещает указатель по массиву первого операнда блоками по четыре элемента, после превышения искомого значения возвращается на два элемента и уточняет позицию единичными шагами. Второй выполняет ту же схему с начальным шагом восемь и уточнениями 4, 2 и 1. В конец массива добавляются восемь значений-сентинелов $\mathtt{UINT\_MAX}$, благодаря чему пробный прыжок за последний настоящий элемент остаётся допустимым обращением к памяти. Макрос \texttt{IFLT8} выбирается при $p\geq16r$, в остальных случаях используется \texttt{IFLT4}.
|
||||
|
||||
Такой выбор учитывает разреженность требований, установленную в разд.~\Ref{PROBLEM}, но лишь двумя фиксированными режимами. При медианном $p/r=28{,}1$ шаг восемь уже применим, тогда как при $p/r=257$ он всё ещё остаётся равным восьми и не отражает фактическое среднее расстояние между требуемыми значениями.
|
||||
|
||||
Пусть $s_P$ и $s_R$ --- длины payload двух строк, а $d=|b_P-b_R|$. Холодное сравнение имеет оценку
|
||||
\[
|
||||
T_{\mathrm{cold}}=
|
||||
O(s_P+s_R)+O\bigl(d\max(p,r)\bigr)+O(p+r).
|
||||
\]
|
||||
Поскольку формат ограничивает $10\leq b\leq32$, величина $d$ ограничена константой, и итоговая асимптотика линейна по размеру входных строк и декодированных множеств. При попадании первого операнда в кэш исчезает его декодирование, но остаются линейный поиск по кэшу, проверка строки, декодирование второго операнда, возможная нормализация и проход по массивам:
|
||||
\[
|
||||
T_{\mathrm{hit}}=
|
||||
O(C+s_P+s_R)+O\bigl(d\max(p,r)\bigr)+O(p+r),
|
||||
\qquad C=256.
|
||||
\]
|
||||
Здесь член $s_P$ отражает окончательную проверку ключа; на практике она выполняется только для записей с совпавшим коротким отпечатком. Дополнительная память одного холодного вызова составляет $O(p+r)$, не считая сохраняемого в процессе кэша первого операнда.
|
||||
|
||||
\section{Оптимизации с сохранением текущего формата}
|
||||
\label{COMPATIBLE_OPTIMIZATIONS}
|
||||
|
||||
Для проверки направлений оптимизации была создана экспериментальная реализация \texttt{set9.c} [\Ref{SET9}]. Она сохраняет Jenkins OAAT, формат заголовка, Golomb--Rice/Base62-представление и пять функций публичного API. Поэтому сформированные ею строки побайтово совместимы с исходной реализацией, а изменения относятся только к внутренним структурам и алгоритмам.
|
||||
|
||||
Помимо оптимизации сравнения, построение множества было переведено с отдельных \texttt{xstrdup()} для каждого имени на общую растущую строковую арену. В массиве элементов хранятся смещения, которые остаются корректными после \texttt{xrealloc()} арены. Кодирование и декодирование выполняются потоково: дельты, состояния Голомба--Райса и Base62 обрабатываются через 64-битный аккумулятор без отдельных массивов битов и дельт.
|
||||
|
||||
\subsection{Два bucketed LRU-кэша}
|
||||
|
||||
Вместо одного линейного кэша используются два независимых кэша --- для первого и второго операндов. Каждый содержит до 512 записей и таблицу из 1024 бакетов. Разделение предотвращает взаимное вытеснение часто повторяющихся \texttt{Provides} и \texttt{Requires}, а бакеты ограничивают область поиска записи.
|
||||
|
||||
Ключ включает короткий отпечаток исходной строки и целевую точность $b_*$. Совпадение, как и в исходном варианте, обязательно подтверждается полным \texttt{strcmp()}, поэтому ускоряющая структура не меняет семантику. Значение $b_*$ принципиально важно: одна строка может сравниваться с операндами разной точности и давать разные нормализованные массивы.
|
||||
|
||||
При промахе строка декодируется, сразу приводится к $b_*$ и в таком виде сохраняется. Повторное сравнение той же строки при той же точности не требует ни декодирования, ни цикла \texttt{downsample\_set()}. Порядок вытеснения поддерживается двусвязным списком: попадание переносит запись в начало за $O(1)$, а при заполнении удаляется самый старый элемент. В отличие от массивного кэша, полный сдвиг записей не требуется. При равномерном распределении отпечатков ожидаемая стоимость поиска близка к $O(1)$ плюс стоимость окончательной проверки строки.
|
||||
|
||||
\subsection{Radix sort для больших множеств}
|
||||
|
||||
При построении строки исходный \texttt{qsort()} требует $O(n\log n)$ вызовов функции сравнения. Для 32-битных целых ключей число разрядов заранее ограничено, поэтому в \texttt{set9.c} при $n\geq128$ применяется стабильная LSD radix sort по байтам хеша. Для меньших наборов сохраняется \texttt{qsort()}, поскольку подготовка таблиц и временного массива не окупается.
|
||||
|
||||
Число проходов определяется фактически используемой точностью:
|
||||
\[
|
||||
k=\left\lceil\frac b8\right\rceil,
|
||||
\qquad
|
||||
T_{\mathrm{radix}}=O(kn).
|
||||
\]
|
||||
На каждом проходе сначала подсчитываются 256 значений текущего байта, затем префиксные суммы преобразуют счётчики в позиции, после чего элементы стабильно распределяются во временный массив. Источник и приёмник меняются местами между проходами. Дополнительная память равна
|
||||
\[
|
||||
M_{\mathrm{radix}}=O(n+256).
|
||||
\]
|
||||
Так как $b\leq32$, выполняется не более четырёх линейных проходов.
|
||||
|
||||
\subsection{Адаптивная проверка включения}
|
||||
|
||||
Мощности массивов после нормализации позволяют заранее исключить часть отношений. Если $p=r$, строгого включения быть не может: равенство проверяется одним \texttt{memcmp()}, а несовпадение означает несравнимость. Если $p>r$, проверяется только $\widehat R\subseteq\widehat P$; обратное строгое включение невозможно. Случай $p<r$ обрабатывается симметрично. Тем самым устраняется одновременное ведение двух флагов и выбирается единственная содержательная проверка.
|
||||
|
||||
Функция \texttt{sorted\_subset()} использует отношение мощностей
|
||||
\[
|
||||
j=\left\lfloor\frac{n_{\mathrm{large}}}{n_{\mathrm{small}}}\right\rfloor.
|
||||
\]
|
||||
При $j<4$ выполняется обычное линейное слияние. Для разреженного случая поиск очередного элемента начинается от позиции предыдущего совпадения, делает шаг приблизительно $j$, а затем делит шаг пополам до нахождения нижней границы. Указатель по большому массиву движется только вперёд; при первом отсутствующем хеше функция немедленно возвращает отрицательный результат.
|
||||
|
||||
Для плотного случая сохраняется оценка $O(p+r)$. В разреженном потоке суммарное число крупных шагов имеет порядок $O(p/j)$, а уточнение границы требует до $O(\log j)$ проб на один элемент меньшего множества:
|
||||
\[
|
||||
T_{\mathrm{sparse}}=
|
||||
O\left(\frac pj+r\log j\right).
|
||||
\]
|
||||
При характерном $j\approx p/r$ первое слагаемое имеет порядок $r$. В отличие от фиксированного выбора между шагами 4 и 8, величина перехода адаптируется к наблюдаемому отношению мощностей.
|
||||
|
||||
\section{Результаты экспериментальной проверки}
|
||||
\label{RESULTS}
|
||||
|
||||
Проверка экспериментальной реализации проводилась в два этапа. Сначала проверялась корректность формата и операций над множествами, затем измерялась производительность в сценариях пакетного менеджера.
|
||||
|
||||
\subsection{Дифференциальное тестирование на синтетических множествах}
|
||||
|
||||
Для проверки совместимости был разработан дифференциальный тест, не использующий заранее подготовленные \texttt{set:}-строки. На каждой итерации он самостоятельно формировал исходное множество из случайных уникальных строк. Число символов выбиралось в диапазоне от 1 до 1000, длина каждого имени --- от 1 до 100 знаков, а параметр $bpp$ --- от 10 до 32. В алфавит входили латинские буквы, цифры и знаки, встречающиеся в именах экспортируемых символов: точка, знак \texttt{@} и подчёркивание.
|
||||
|
||||
Из исходного множества строилось второе множество с заранее известным отношением к первому. Тест охватывал четыре класса входов: равные множества, строгое включение, несравнимые множества и некорректные \texttt{set:}-строки. Для проверки строгого включения из первого множества удалялась случайная непустая часть элементов. В случае несравнимости после удаления добавлялись новые символы, отсутствующие в первом множестве. Некорректная строка генерировалась случайным набором символов, в таком случае был шанс получить корректную строку, но для нас остаётся важным одинаковый результат двух программ.
|
||||
|
||||
Один и тот же набор исходных символов независимо передавался построителю исходного \texttt{set.c} и построителю \texttt{set9.c}. Таким образом, каждая реализация сама выполняла хеширование, сортировку и кодирование, после чего её вариант \texttt{rpmsetcmp()} сравнивал полученную пару строк. Тест сопоставлял наблюдаемый результат публичного API: $1$ для строгого надмножества, $0$ для равенства, $-1$ для строгого подмножества, $-2$ для несравнимости и $-3$ или $-4$ для ошибки декодирования соответствующего операнда. Для случая включения операнды дополнительно менялись местами, что позволяло одновременно проверить результаты $1$ и $-1$.
|
||||
|
||||
Генерация и сравнение выполнялись циклически до ручной остановки теста. Такой подход проверял эквивалентность реализаций на широком диапазоне мощностей и точностей.
|
||||
|
||||
\subsection{Производительность в сценариях APT}
|
||||
|
||||
Для измерения времени использовались две локальные сборки \texttt{librpm}: с исходным \texttt{set.c} и с \texttt{set9.c}. На каждой сборке трижды выполнялись одинаковые успешно завершившиеся симуляции APT. В табл.~\Ref{APT_RESULTS} приведены средние значения процессорного времени пользователя и ядра. Время ожидания и ввода-вывода в эти величины не входит.
|
||||
|
||||
Коэффициент вычислялся по суммарному процессорному времени:
|
||||
\[
|
||||
K_{\mathrm{CPU}}=
|
||||
\frac{U_{\mathrm{original}}+S_{\mathrm{original}}}
|
||||
{U_{\mathrm{set9}}+S_{\mathrm{set9}}}.
|
||||
\]
|
||||
Значение $K_{\mathrm{CPU}}>1$ означает ускорение, а $K_{\mathrm{CPU}}<1$ --- замедление экспериментальной реализации.
|
||||
|
||||
\begin{table}[H]
|
||||
\begin{center}
|
||||
\caption{\label{APT_RESULTS}Сравнение исходного \texttt{set.c} и \texttt{set9.c} в симуляциях APT}
|
||||
\scriptsize
|
||||
\begin{tabular}{|l|r|r|r|r|r|}
|
||||
\hline
|
||||
Сценарий & \multicolumn{2}{c|}{Исходный, с} & \multicolumn{2}{c|}{\texttt{set9.c}, с} & $K_{\mathrm{CPU}}$ \\
|
||||
\cline{2-5}
|
||||
& user & system & user & system & \\
|
||||
\hline
|
||||
\texttt{-s check} & 0,453 & 0,033 & 0,503 & 0,040 & 0,896 \\
|
||||
\hline
|
||||
\texttt{-s autoremove} & 0,763 & 0,040 & 0,810 & 0,040 & 0,945 \\
|
||||
\hline
|
||||
\texttt{-s install rpm-build} & 1,210 & 0,050 & 1,283 & 0,050 & 0,945 \\
|
||||
\hline
|
||||
\texttt{-s install openuds-server} & 3,747 & 0,080 & 3,897 & 0,083 & 0,961 \\
|
||||
\hline
|
||||
\texttt{-s install password-store} & 1,233 & 0,050 & 1,310 & 0,050 & 0,944 \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
\end{table}
|
||||
|
||||
Во всех пяти измеренных сценариях \texttt{set9.c} не превзошёл исходный вариант: суммарное процессорное время увеличилось примерно на 4,0--11,6\%. Это отрицательный результат, вызванный более простым потоковым декодером, который не превзошёл специализированного табличного декодера исходной реализации даже при условии остальных оптимизаций.
|
||||
|
||||
Для проверки этого объяснения исходный слитый декодер отдельно сравнивался с вариантом, в котором Base62, код Голомба--Райса и восстановление дельт выполнялись последовательными стадиями. В зависимости от сценария слитый путь сокращал суммарное процессорное время в 1,47--2,82 раза. Следовательно, благодаря табличной обработке Base62/Golomb получается измеримый выигрыш. Практическое направление дальнейшей работы может состоять в разработке нового формата хранения и обработки \texttt{set:}-строк.
|
||||
|
||||
\section{Варианты со сменой формата или API}
|
||||
\label{ALTERNATIVE_FORMATS}
|
||||
|
||||
Оптимизации разд.~\Ref{COMPATIBLE_OPTIMIZATIONS} ограничены требованием побайтовой совместимости. Параллельно исследовались представления, снимающие это ограничение. Их результаты нельзя напрямую переносить на существующие RPM-метаданные: новый формат требует повторного формирования зависимостей репозитория.
|
||||
|
||||
\subsection{Roaring Bitmap: отрицательный результат}
|
||||
|
||||
Roaring Bitmap [\Ref{ROARING}] предназначен прежде всего для множеств, содержащих плотные участки целочисленного пространства. Усечённые хеши, напротив, распределены по диапазону приблизительно равномерно. Поэтому контейнеры bitmap не получают длинных серий соседних значений, но сохраняют собственные заголовки и индексы.
|
||||
|
||||
В микротесте использовались 1000 предоставляемых и 500 требуемых символов при $b=32$. Результаты приведены в табл.~\Ref{ROARING_RESULTS}. Коэффициенты времени вычислены относительно \texttt{set9.c}; значение больше единицы означает замедление.
|
||||
|
||||
\begin{table}[H]
|
||||
\begin{center}
|
||||
\caption{\label{ROARING_RESULTS}Сравнение Golomb/Base62 и Roaring Bitmap}
|
||||
\small
|
||||
\begin{tabular}{|l|r|r|r|}
|
||||
\hline
|
||||
Представление & Длина строки & Cold compare & Warm compare \\
|
||||
\hline
|
||||
Golomb/Base62 \texttt{set9} & 3\,994 & 1,00 & 1,00 \\
|
||||
\hline
|
||||
Roaring/hex & 19\,924 & 4,50 & 76,14 \\
|
||||
\hline
|
||||
Roaring+zstd & 14\,126 & 4,96 & 101,86 \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
\end{table}
|
||||
|
||||
Без дополнительного сжатия строка оказалась длиннее в 4,99 раза. Холодное сравнение заняло 1321,17 мкс вместо 293,87 мкс, а прогретое --- 399,20 мкс вместо 5,24 мкс. При этом построение bitmap занимало лишь $0,76$ времени \texttt{set\_fini()} варианта \texttt{set9}; ускорение генерации не компенсировало стоимость хранения и сравнения.
|
||||
|
||||
Сжатие zstd [\Ref{ZSTD}] уменьшило строку до 14\,126 символов, то есть до 3,54 длины \texttt{set9}, но добавило декомпрессию в горячий путь. В отдельном прогоне холодное и прогретое сравнения были медленнее соответственно в 4,96 и 101,86 раза. Таким образом, Roaring Bitmap для равномерных хешей является подтверждённым отрицательным вариантом: структура данных не соответствует распределению кодируемых значений.
|
||||
|
||||
\subsection{Прямые хеши в Base64}
|
||||
|
||||
Другой вариант, обозначенный как D1, исключает дельты и код Голомба--Райса. $n$ отсортированных уникальных хешей записываются подряд по $b$ бит, после чего битовый массив преобразуется в Base64-строку [\Ref{BASE64}]. Если
|
||||
\[
|
||||
Q=\left\lceil\frac{nb}{8}\right\rceil
|
||||
\]
|
||||
--- число байтов упакованного массива, то доминирующая часть длины payload равна
|
||||
\[
|
||||
L_{\mathrm{payload}}=
|
||||
\left\lceil\frac{4Q}{3}\right\rceil,
|
||||
\]
|
||||
а заголовок формата добавляет постоянное число символов. В отличие от Golomb--Rice, эта оценка почти не зависит от расстояний между соседними хешами: цена быстрого произвольного доступа --- увеличение метаданных.
|
||||
|
||||
Для тех же 1000/500 символов при $b=32$ длина строки выросла с 3994 до 5340 символов, то есть на 33,7\%. Результаты теста показаны в табл.~\Ref{DIRECT_RESULTS}; отношение меньше единицы означает, что D1 затратил меньшую долю времени \texttt{set9.c}.
|
||||
|
||||
\begin{table}[H]
|
||||
\begin{center}
|
||||
\caption{\label{DIRECT_RESULTS}Тест прямого представления D1}
|
||||
\small
|
||||
\begin{tabular}{|l|r|r|r|}
|
||||
\hline
|
||||
Операция & \texttt{set9}, мкс & D1, мкс & D1/\texttt{set9} \\
|
||||
\hline
|
||||
\texttt{set\_fini()} & 147,45 & 105,09 & 0,71 \\
|
||||
\hline
|
||||
\texttt{rpmsetcmp()}, cold & 129,67 & 113,04 & 0,87 \\
|
||||
\hline
|
||||
\texttt{rpmsetcmp()}, warm & 2,99 & 1,04 & 0,35 \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
\end{table}
|
||||
|
||||
Для крупного требования прямое представление ускорило все три измеряемые операции, особенно попадание в кэш. Однако при одном требуемом символе холодное сравнение занимало 83,22 мкс ($0,88$ времени \texttt{set9}), а прогретое --- 0,86 мкс ($1,02$), то есть преимущество исчезало. Это подчёркивает зависимость результата от формы нагрузки: выигрыш одного сравнения не доказывает ускорение полного потока зависимостей APT. D1 представляет интерес как компромисс между размером и стоимостью декодирования, но требует отдельной сквозной проверки на преобразованных метаданных репозитория.
|
||||
|
||||
\subsection{Альтернативные хеш-функции}
|
||||
|
||||
Отдельно сравнивались Jenkins OAAT, xxHash32 [\Ref{XXHASH}] и CityHash32 [\Ref{CITYHASH}]. Сравнение было необходимо, так как xxHash и CityHash --- хеш-функции, разработанные значительно позже последнего обновления \texttt{set.c}. В каждом замере использовались три запуска; в табл.~\Ref{HASH_SPEED} приведены медианы. Для коротких строк указано время одного хеширования, для длинных --- пропускная способность.
|
||||
|
||||
\begin{table}[H]
|
||||
\begin{center}
|
||||
\caption{\label{HASH_SPEED}Скорость 32-битных хеш-функций}
|
||||
\small
|
||||
\begin{tabular}{|l|r|r|}
|
||||
\hline
|
||||
Функция & 32 байта, нс/хеш & 1024 байта, ГиБ/с \\
|
||||
\hline
|
||||
Jenkins OAAT & 50,98 & 0,53 \\
|
||||
\hline
|
||||
xxHash32 & 11,56 & 5,18 \\
|
||||
\hline
|
||||
CityHash32 & 16,70 & 4,10 \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
\end{table}
|
||||
|
||||
На строках длиной 32 байта xxHash32 был быстрее Jenkins примерно в 4,4 раза, CityHash32 --- в 3,1 раза. При 1024 байтах различие по пропускной способности достигало соответственно 9,8 и 7,7 раза. Следовательно, Jenkins OAAT не является оптимальным по скорости, особенно на длинных входах.
|
||||
|
||||
Для оценки качества использовался другой тест, в нём сравнивались Jenkins OAAT, 64-битный xxHash и \texttt{t1ha2\_atonce} [\Ref{T1HA}]. Поскольку формат \texttt{set:version} сохраняет не более 32 бит хеша, при сопоставлении учитывались младшие 32 выходных бита всех трёх функций.
|
||||
|
||||
Тест измерял лавинный эффект на реальном корпусе экспортируемых C++-символов ALT Linux p11. Утилита \texttt{provided\_symbols} извлекла из 259 ELF-файлов пяти пакетов 577\,509 уникальных имён. Пакеты выбирались среди имеющих наиболее длинные \texttt{Provides set:}-строки. Корпус специально является сложным для хеширования похожих строк: 99,60\% символов имеют с другим символом общий префикс длиной не менее 12 знаков, 95,05\% --- не менее 24 знаков, а медиана максимального общего префикса равна 61 знаку.
|
||||
|
||||
Для каждого бита вычислялась доля $q_i$ корпусных хешей, в которых этот бит равен единице. Идеальному распределению соответствует $q_i=0{,}5$. Результаты обоих тестов представлены в табл.~\Ref{HASH_QUALITY_EXOTIC}. Значения приведены в процентах от полной шкалы вероятности; последний столбец содержит максимальное среднее абсолютное отклонение младших 32 бит от $0{,}5$.
|
||||
|
||||
Среднее абсолютное отклонение по младшим 32 битам вычислялось как:
|
||||
\[
|
||||
\overline{\Delta}=\frac{1}{32}\sum_{i=0}^{31}|p_i-0{,}5|.
|
||||
\]
|
||||
Меньшее значение $\overline{\Delta}$ соответствует более равномерному лавинному эффекту.
|
||||
|
||||
\begin{table}[H]
|
||||
\begin{center}
|
||||
\caption{\label{HASH_QUALITY_EXOTIC}Качество перемешивания младших 32 бит хеш-функций}
|
||||
\scriptsize
|
||||
\begin{tabular}{|l|r|r|r|r|}
|
||||
\hline
|
||||
Функция & \makecell{Корпус\\$\overline{\Delta}$, \%} & \makecell{Корпус\\$\Delta_{\max}$, \%} \\
|
||||
\hline
|
||||
Jenkins OAAT & 0,0475 & 0,167 \\
|
||||
\hline
|
||||
xxHash64 & 0,0431 & 0,122 \\
|
||||
\hline
|
||||
t1ha2 & 0,0615 & 0,188 \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
\end{table}
|
||||
|
||||
Все три функции продемонстрировали близкое к равномерному распределение. На реальном корпусе лучший результат получен для xxHash64, однако разность между функциями составляла сотые доли процента, а максимальное отклонение отдельного бита не превысило 0,188\%.
|
||||
|
||||
Таким образом, тестирование на похожих C++-символах не выявило недостаточного перемешивания Jenkins OAAT. xxHash64 и t1ha2 остаются кандидатами для отдельной оценки производительности, но качество распределения само по себе не обосновывает замену Jenkins.
|
||||
|
||||
\References
|
||||
\begin{enumerate}
|
||||
@@ -197,8 +528,61 @@ ALT RPM source code, 2010--2012.
|
||||
|
||||
\item
|
||||
\Label{JENKINS}
|
||||
Jenkins B.
|
||||
\emph{A Hash Function for Hash Table Lookup}.
|
||||
1997, обновлено в 2013 г.
|
||||
[Электронный ресурс] URL: \url{https://burtleburtle.net/bob/hash/doobs.html}.
|
||||
|
||||
\item
|
||||
\Label{GOLOMB-RICE}
|
||||
Wikipedia contributors.
|
||||
\emph{Golomb coding: описание кодов Голомба и Райса}.
|
||||
[Электронный ресурс] URL: \url{https://en.wikipedia.org/wiki/Golomb_coding}.
|
||||
|
||||
\item
|
||||
\Label{SET9}
|
||||
Гудов Д.О.
|
||||
\emph{set9.c --- экспериментальная реализация алгоритмов set:version}.
|
||||
Исходный код на GitHub.
|
||||
[Электронный ресурс] URL: \url{https://github.com/kr0sh512/alt-rpm-set-version/blob/main/reimplement/set9.c}.
|
||||
|
||||
\item
|
||||
\Label{ROARING}
|
||||
RoaringBitmap.org.
|
||||
\emph{Roaring Bitmaps --- A better compressed bitset}.
|
||||
[Электронный ресурс] URL: \url{https://roaringbitmap.org/}.
|
||||
|
||||
\item
|
||||
\Label{BASE64}
|
||||
Josefsson S.
|
||||
\emph{The Base16, Base32, and Base64 Data Encodings}. RFC~4648, 2006.
|
||||
[Электронный ресурс] URL: \url{https://www.rfc-editor.org/info/rfc4648}.
|
||||
|
||||
\item
|
||||
\Label{ZSTD}
|
||||
Collet Y., Kucherawy M.
|
||||
\emph{Zstandard Compression and the application/zstd Media Type}. RFC~8878, 2021.
|
||||
[Электронный ресурс] URL: \url{https://www.rfc-editor.org/info/rfc8878}.
|
||||
|
||||
\item
|
||||
\Label{XXHASH}
|
||||
Collet Y.
|
||||
\emph{xxHash --- extremely fast non-cryptographic hash algorithm}.
|
||||
Исходный код и документация.
|
||||
[Электронный ресурс] URL: \url{https://github.com/Cyan4973/xxHash}.
|
||||
|
||||
\item
|
||||
\Label{CITYHASH}
|
||||
Google.
|
||||
\emph{CityHash --- a family of hash functions for strings}.
|
||||
Исходный код и документация.
|
||||
[Электронный ресурс] URL: \url{https://github.com/google/cityhash}.
|
||||
|
||||
\item
|
||||
\Label{T1HA}
|
||||
Erthink.
|
||||
\emph{t1ha --- Fast Positive Hash}.
|
||||
Исходный код и документация.
|
||||
[Электронный ресурс] URL: \url{https://gitflic.ru/project/erthink/t1ha}.
|
||||
|
||||
\end{enumerate}
|
||||
|
||||
Reference in New Issue
Block a user