Комментарии 17
вероятно, из-за скорости выполнения операций ввода/вывода
интересно было бы проверить на быстром hdd/ssd для того чтобы быть уверенным, нет ли програмного ограничения в 4 потока
и какие результаты будут на 32, 64 потоках с HT и без
интересно было бы проверить на быстром hdd/ssd для того чтобы быть уверенным, нет ли програмного ограничения в 4 потока
и какие результаты будут на 32, 64 потоках с HT и без
В общем-то, можно даже и без 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В результате получаем каталог, находящийся в оперативной памяти.
Разумеется, данные стираются при перезагрузке, но для временного хранения файлов, к которым необходим быстрый доступ (и на чтение, и на запись), решение отличное.
Зачем программно ограничивать 4 потока?
pbzip2, насколько я понимаю, использует параллельную сортировку блока, всё остальное может быть и последовательным. Сортировка блока в 900 тысяч байт (размер блока по умолчанию) хорошо распараллеливается даже на 100 процессоров.
Собственно, на сайте есть графики, и я не вижу причин им не доверять.
pbzip2, насколько я понимаю, использует параллельную сортировку блока, всё остальное может быть и последовательным. Сортировка блока в 900 тысяч байт (размер блока по умолчанию) хорошо распараллеливается даже на 100 процессоров.
Собственно, на сайте есть графики, и я не вижу причин им не доверять.
Проверил в рамдиске на 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
ИМХО, при привышении числа потоков количества физических ядер сказываются издержки синхронизации. Ведь дополнительный поток ядра использует те же вычислительные элементы, что и первый. Следовательно, при идентичном алгоритме оба потока будут конкурировать за одни и те же аппаратные ресурсы ядра (регистры, сумматоры, ...), что не даст выигрыша в производительности, но и замедлит вычисления.
Спасибо за дополнительные тесты! Указал в тексте на их наличие.
НЛО прилетело и опубликовало эту надпись здесь
у меня есть подозрение что никому не нужен архиватор, умеющий отжирать все дсотупные ядра, особенно на серверах :)
Опция -k — что за идотское решение. Програма по умолчанию должна действовать неразрушительно, а здесь нужно помнить не забыть включить опцию.
Строго говоря, поведение не совсем разрушительное — до окончания компрессии/декомпрессии файл не удаляется. Кроме того, у bzip2 поведение такое же (то есть авторы pbzip2 оставили «как было»).
Впрочем, я бы и сам был рад почитать о том, почему первоначально было решено сделать именно так (кстати, не только в bzip2 — у gzip то же самое).
Впрочем, я бы и сам был рад почитать о том, почему первоначально было решено сделать именно так (кстати, не только в bzip2 — у gzip то же самое).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почти линейное увеличение производительности bzip2 на многопроцессорных системах