Cache забывающий массив заголовков

Я пытаюсь понять подобранный в кэше забытый массив lookahead, который описан в здесь, а со страницы 35 эта презентация

Анализ внедрения в упрощенное Дерево фракталов:

  • Стоимость слияния 2 массивов размера X - это O (X = B) блок ввода/вывода. Слияние очень Эффективность ввода-вывода.
  • Стоимость одного элемента для объединения равна O (1/B), поскольку элементы O (X) были слиты.
  • Максимальное количество раз, когда каждый элемент объединяется, равен O (logN).
  • Средняя стоимость вставки - O (logN/B)

Я могу понять # 1, # 2 и # 3, но я не могу понять # 4. Из статьи слияние можно рассматривать как перенос бинарных добавок, например, (31) B может быть представлено:    11111
при вставке нового элемента (плюс 1) должно быть 5 = ​​log (32) merge (5 переносов). Но в этой ситуации нам нужно объединить 32 элемента! Кроме того, если каждый раз мы плюс 1, то сколько переносов будет выполняться от 0 до 2 ^ k? Anwser должен быть 2 ^ k - 1. Другими словами, одно слияние на вставку!

Итак, как вычисляется # 4?

Ответ 1

В то время как вы правы в обоих случаях, количество объединенных элементов (и, следовательно, переносов) в худшем случае равно N, а количество общих слияний также имеет тот же порядок, стоимость вставки средняя все еще логарифмическая. Он исходит из двух фактов: слияния меняются по стоимости, а количество недорогих слияний намного выше, чем количество дорогостоящих.

Это может быть проще увидеть на примере.
Пусть множество B = 1 (т.е. 1 элемент на блок, наихудший случай каждого слияния, имеющего стоимость) и N = 32 (например, мы вставляем 32 элемента в первоначально пустой массив).
Половина вложений (16) помещает элемент в пустой подмассив размером 1 и поэтому не вызывает слияние. Из оставшихся вставок один (последний) должен объединить (переместить) 32 элемента, один (16-й) движется 16, два (8-е и 24-е) перемещают 8 элементов, 4-х перемещают 4 элемента и восемь перемещают 2 элемента. Таким образом, общее число перемещений элементов равно 96, что дает среднее значение 3 ходов на вставку.

Надеюсь, что это поможет.

Ответ 2

Первые уровни журнала B соответствуют (одной странице) памяти, поэтому любые вещи, которые происходят на этих уровнях, не влекут ввода-вывода. (Это также устраняет проблему с анализом rrenaud, что O (1) объединяется при вставке, так как вы только начинаете платить за них после слияния первого журнала B.)

Как только вы объединяете по крайней мере элементы B, происходит Факт 2.

Рассмотрим работу с элементарной точки зрения. Он объединяет O (log N) раз. Он получает заряженный O (1/B) каждый раз, когда это происходит. Общая стоимость вставки - O ((log N)/B) (необходимо, чтобы дополнительные параны отличались от O (log N/B), что было бы неплохой производительностью вставки - даже хуже, чем B-дерево).

"Средняя" стоимость - это действительно амортизированная стоимость - это сумма, которую вы начисляете на этот элемент для его вставки. Немного более формально это общая работа для вставки N элементов, а затем делить на N. Амортизированная стоимость O ((log N)/B) на самом деле означает, что вставка N элементов - O ((N log N)/B) I/Os - для всей последовательности. Это сопоставимо с B-деревьями, что для N вложений делает в общей сложности O ((N log N)/log B) I/O. Разделение на B, очевидно, намного лучше, чем деление на журнал B.

Вы можете пожаловаться на то, что работа комковата, что вы иногда делаете вставку, которая вызывает большой каскад слияний. Это нормально. Вы не взимаете все слияния с последней вставкой. Каждый платит свою небольшую сумму за каждое слияние, в котором они участвуют. Поскольку (log N)/B обычно будет намного меньше 1, каждый заряжается менее, чем один ввод-вывод в течение всех слияний участвует в.

Что произойдет, если вам не нравится амортизированный анализ, и вы говорите, что хотя пропускная способность вставки увеличивается на пару порядков, вам не нравится, когда одна вставка может вызвать огромный объем работы? Ага! Существуют стандартные способы деамортизации такой структуры данных, когда вы выполняете бит упреждающего слияния во время каждой вставки. Вы получаете ту же сложность ввода/вывода (вам придется поверить мне на слово), но это довольно стандартный материал для людей, которые заботятся об амортизированном анализе и деамортируют результат.

Полное раскрытие: я являюсь одним из авторов документа COLA. Кроме того, rrenaud был в моем классе алгоритмов. Кроме того, я основатель Tokutek.