Почти линейное увеличение производительности bzip2 на многопроцессорных системах

[pil0t]

вероятно, из-за скорости выполнения операций ввода/вывода
интересно было бы проверить на быстром hdd/ssd для того чтобы быть уверенным, нет ли програмного ограничения в 4 потока
и какие результаты будут на 32, 64 потоках с HT и без

[aruseni]

В общем-то, можно даже и без ssd:

# mkdir /mnt/tmpfs
# mount -t tmpfs -o size=1G /mnt/tmpfs/
# df -h /mnt/tmpfs
Filesystem Size Used Avail Use% Mounted on
tmpfs 1.0G 0 1.0G 0% /mnt/tmpfs

В результате получаем каталог, находящийся в оперативной памяти.

Разумеется, данные стираются при перезагрузке, но для временного хранения файлов, к которым необходим быстрый доступ (и на чтение, и на запись), решение отличное.

[middle]

Зачем программно ограничивать 4 потока?

pbzip2, насколько я понимаю, использует параллельную сортировку блока, всё остальное может быть и последовательным. Сортировка блока в 900 тысяч байт (размер блока по умолчанию) хорошо распараллеливается даже на 100 процессоров.

Собственно, на сайте есть графики, и я не вижу причин им не доверять.

[tristan]

Проверил в рамдиске на 2x Xeon 5649 (6c12t x2). После 4-х потов прирост не такой большой, но есть. От HT толку нет.

$ time bzip2 test.tar

real 1m51.689s
user 1m51.543s
sys 0m0.100s

$ time pbzip2 -k -p1 test.tar

real 1m49.841s
user 1m49.179s
sys 0m0.616s

$ time pbzip2 -k -p4 test.tar

real 0m28.480s
user 1m53.675s
sys 0m0.268s

$ time pbzip2 -k -p6 test.tar

real 0m19.610s
user 1m56.967s
sys 0m0.408s

$ time pbzip2 -k -p10 test.tar

real 0m13.906s
user 2m17.089s
sys 0m0.560s

$ time pbzip2 -k -p12 test.tar

real 0m13.480s
user 2m38.526s
sys 0m0.764s

$ time pbzip2 -k -p18 test.tar

real 0m14.813s
user 4m18.336s
sys 0m1.416s

$ time pbzip2 -k test.tar

real 0m17.851s
user 6m44.701s
sys 0m2.356s

[ababo]

ИМХО, при привышении числа потоков количества физических ядер сказываются издержки синхронизации. Ведь дополнительный поток ядра использует те же вычислительные элементы, что и первый. Следовательно, при идентичном алгоритме оба потока будут конкурировать за одни и те же аппаратные ресурсы ядра (регистры, сумматоры, ...), что не даст выигрыша в производительности, но и замедлит вычисления.

[aruseni]

Спасибо за дополнительные тесты! Указал в тексте на их наличие.

[andrewsch]

Интересно, что на 24 ядрах половина процессорного времени ушло на переключение контекста и синхронизацию (практически вдвое больше ресурсов на ту же задачу ушло).

[gribozavr]

Скорее, на доступ в память в соседний NUMA node.

[aruseni]

Спасибо за дополнительные тесты! Указал в тексте на их наличие.

[altexxx]

Укажите, пожалуйста, альтернативу
www.zlib.net/pigz/

[aruseni]

Спасибо, указал.

[andrew_tch]

у меня есть подозрение что никому не нужен архиватор, умеющий отжирать все дсотупные ядра, особенно на серверах :)

[middle]

Однако умеющий отожрать лишь половину, особенно ночью, при минимальной нагрузке, когда обычно делают бэкапы — вполне нужен. С чем pbzip2 справляется.

[andrew_tch]

С другой стороны, ограничение будет скорее в IO, чем в процессоре. А архиватор, нечаянно повесивший дисковую систему… тоже не очень.

[stoune]

Опция -k — что за идотское решение. Програма по умолчанию должна действовать неразрушительно, а здесь нужно помнить не забыть включить опцию.

[aruseni]

Строго говоря, поведение не совсем разрушительное — до окончания компрессии/декомпрессии файл не удаляется. Кроме того, у bzip2 поведение такое же (то есть авторы pbzip2 оставили «как было»).

Впрочем, я бы и сам был рад почитать о том, почему первоначально было решено сделать именно так (кстати, не только в bzip2 — у gzip то же самое).