Общее количество операций, сравнений + ходов, примерно одинаково в любом случае. K-way merge делает больше сравнений, но меньше движений. Моя система имеет 8-стороннюю кэш-память (Intel 3770K 3,5 ГГц), которая в случае четырехсторонней сортировки слиянием позволяет использовать 4 строки кэша для 4 входных циклов и 1 строку кэша для объединенного выходного цикла. В 64-битном режиме имеется 16 регистров, которые могут использоваться для рабочих переменных, 8 из них используются для указателей на текущую и конечную позицию каждого «прогона» (оптимизация компилятора).
В моей системе я сравнил четырехстороннее слияние (без кучи, ~ 3 сравнения на перемещенный элемент) с двухсторонним слиянием (~ 1 сравнение за ход, но в два раза больше проходов), четырехстороннее в 1,5 раза больше количество сравнений, но в 0,5 раза больше количества ходов, так что, по сути, такое же количество операций, но 4-й способ примерно на 15% быстрее из-за проблем с кешем.
Я не знаю, достаточно ли 16 регистров для слияния 6 путей, чтобы быть чуть-чуть быстрее, а 16 регистров недостаточно для слияния 8 путей (некоторые из рабочих переменных будут основаны на памяти / кэше). Попытка использовать кучу, вероятно, не поможет, поскольку куча будет основываться на памяти / кэше (не на основе регистра).
K-way слияние в основном полезно для внешних сортировок, где время сравнения игнорируется из-за гораздо больших накладных расходов на ходы.