Вопрос в том, что ты будешь им жать. Если киношку, так это изначально бредовый тест, ибо она не жмётся по любому (уже сжата), а если дерево портежей, то тут всё зависит от опций компиляций, которые ты не привёл. Можно сделать несолидный архив, толку от него никакого, за то можно жать хоть по 256 файлов одновременно, ибо в несолидном каждый файл жмётся отдельно от других. Что получается в итоге - меня волнует мало, ибо прямое копирование даёт примерно такое же "сжатие", да ещё и работает вообще независимо от CPU, благодаря DMA (потому такое "сжатие" хоть в 256 потоков не имеет вообще никакого смысла). А вот если у тебя таки солидное сжатие, то сжать N+1 файл ты сможешь только после сжатия Nного. Такой вот странный алгоритм. Он принципиально однопоточный.

Блаблаблабла, вот только тесты, где WinRAR показал результат близкий к многопоточному 7zip и в разы лучший однопоточного WinZip, опровергают твоё теоретизирование на корню.

ну это для вас "вброс", а я прекрасно знаю

Я это уже заметил.

В моём посте чётко указано что лучший показатель - у 7zip

что там и как оно в 7zip я не в курсе, если честно. Тоже не использую, и по тем же причинам.

ну мы ваще-то с того и начали, но ты зачем-то перевёл стрелки на молотки, WinRAR, и 7zip.

повторяю - что 7zip, что WinRAR - для меня не пруф ни разу.

хорошо. только позже. Сейчас у меня времени нет.

согласен. фанатизм. Но у меня несколько другой подход - я оцениваю архиваторы вовсе не потому, свободный он, или не свободный, нет. WinRAR не свободный, но вот алгоритмы, которые он использует, мне известны. Вопрос в том, что ты будешь им жать. Если киношку, так это изначально бредовый тест, ибо она не жмётся по любому (уже сжата), а если дерево портежей, то тут всё зависит от опций компиляций, которые ты не привёл. Можно сделать несолидный архив, толку от него никакого, за то можно жать хоть по 256 файлов одновременно, ибо в несолидном каждый файл жмётся отдельно от других. Что получается в итоге - меня волнует мало, ибо прямое копирование даёт примерно такое же "сжатие", да ещё и работает вообще независимо от CPU, благодаря DMA (потому такое "сжатие" хоть в 256 потоков не имеет вообще никакого смысла). А вот если у тебя таки солидное сжатие, то сжать N+1 файл ты сможешь только после сжатия Nного. Такой вот странный алгоритм. Он принципиально однопоточный. Конечно ты можешь что-то с этим сделать, но степень сжатия катастрофически упадёт. NoWay. Это просто математика, причём выводы известны очень давно, и сделаны они конечно не мной. В принципе, ты можешь распараллелить блочный алгоритм типа BWT (как в bzip2), но тут тоже проблема - каждому потоку нужна будет своя память, и не мало (сотни мегабайт, а лучше гигабайты), естественно это возможно только на многопроцессорных серверных мамках, где каждый процессор имеет свою память. Многоядерный будет просто ждать, когда дойдёт очередь к единственной в системе памяти. Опять-таки, это вовсе не кривизна ПО, а "кривизна" алгоритмов. К сожалению, математики пока других не придумали. Во всяком случае, в открытых источниках их нет. Я не математик, я быдлокодер, потому затрудняюсь сказать, что этому мешает. Учи матчасть, если тебе это интересно.

ЗЫЖ ладно, мне тут одну НЁХ надо вылечить, т.ч. самозабаниваюсь

...который вы заставили просчитывать морально устаревший и жутко тормозной PPMD в WinRAR'е  smile

В моём посте чётко указано что лучший показатель - у 7zip

А вот теперь на сцену должны выйти пруфы от тебя. Потому что pigz (многопоточный gzip) обрабатывает архивы в разы быстрее gzip.

Наверное, это какая-то избирательная слепота, потому что WinRAR показал результат близкий к 7zip

Поставь да посмотри. Ты же всё равно на любой мой тест будешь изворачиваться лишь бы не признать свою ошибку.

При том, что вера в то что т.н. свободные архиваторы при том же количестве потоков покажут кардинально лучшие результаты - это именно фанатизм.

Короче говоря, даже при самом неблагоприятном раскладе скорость работы винта ощутимо выше скорости работы самого мощного разогнанного проца с шестью ядрами и НТ

...который вы заставили просчитывать морально устаревший и жутко тормозной PPMD в WinRAR'е  smile

теперь узнайте с какой скоростью файлы достаются из памяти, и вешайтесь. Потому-что выборка из памяти это как раз и есть узкое место для gzip и xz(lzma). А уж про тормозной (по сравнению с RAM) диск я вообще промолчу.

ваши тесты доказывают, что толку от этого никакого.

да? а почему я не вижу тестов?

причём тут "фанатик"? я просто не использую WinRAR, и его скоростные характеристики меня абсолютно не волнуют. И не использую вовсе не из-за фанатизма, а просто потому, что на тех серверах, что мне надо админить WinRAR не ставится. На тестовой машинке, с которой я сейчас пишу, ставится, но костыльно, и совершенно не интегрируется с остальными программами. Я вот не могу каждый день в 4:18 бежать к компьютеру, и жать бекап ручками. А вот xz работает автоматически, без всяких напрягов. Ну и кроме того, не я один "фанатег" - gzip встроен чуть более чем везде, даже в Internet Explorer. А вот rar встроен только в WinRAR.

ну это для вас "вброс", а я прекрасно знаю, насколько там простые алгоритмы, и как мало времени они занимают. Причём это случилось не вчера, а где-то так с первого пня. Конечно диски стали с тех пор намного быстрее, но CPU сейчас считают ЕЩЁ быстрее. Т.ч. ситуация только усугубляется.

Пожай тоже соглашусь с drBatty, а вот Macumazan,  если уш говорите то предоставьте хоть какое то подтверждение ваших слов, а иначе это просто сотрясение воздуха.

Естесственно, ибо на такой вброс

отвечать пруфами мгновенно  -  слишком много чести.

Перед cp -r дропай кеши, а то ерунда

Дропал, всё как положено.

Нормальный тест. ФС не с нуля для теста создана, а используется уже чёрт знает сколько времени, представь степень её фрагментации. Слышно было, как головки прыгали по блинам.

Провёл пару тестов:
...

joker@localhost ~ $ time cp -r /media/video/Movies/Трон /media/home/joker/

...

Перед cp -r дропай кеши, а то ерунда, да и вообще cp скорость мерить ерунда а не тест.
Хотя бы так:

echo 3 | tee /proc/sys/vm/drop_caches
time dd if=/dev/zero of=/tmp/speedtest.bin bs=4K count=10M

и то это не будет реальной скоростью работы винта с кучей файлов, просто линеный тест.

WinRAR 4 превосходно параллелится.

7zip параллелится тоже (до 12 потоков - легко) и он одинаков для обеих платформ.

Я думаю, тут другая причина: криворукие кодеры, так как многопоточные версии у тех же gzip и bzip2 есть и работают в разы быстрее однопоточных.

Мог бы сразу сказать что фанатик, я бы и время не тратил.

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

Провёл пару тестов:

joker@localhost ~ $ time cp -r /media/video/Movies/Трон /media/home/joker/

real    3m49.215s
user    0m0.147s
sys     0m21.894s
joker@localhost ~ $ du -h /media/video/Movies/Трон
21G     /media/video/Movies/Трон

это около 92 Мб/сек, раздел /media/home - Ext4, раздел /media/video - XFS, находятся на разных хардах

Теперь то же самое для одного харда:

joker@localhost ~ $ time cp -r /media/home/joker/Трон /media/home/joker/Видео/

real    9m35.935s
user    0m0.184s
sys     0m20.246s

это около 36,5 Мб/сек

Короче говоря, даже при самом неблагоприятном раскладе скорость работы винта ощутимо выше скорости работы самого мощного разогнанного проца с шестью ядрами и НТ

Итого: даже самый мощный и дорогой, притом разогнанный, десктопный проц показал в 7zip 650/28 = 23,2 Мб/сек

и что? молотки какие-то вместо картинок, программы маздайные... WinRAR как был тормозным УГ на PPMD, так им и остался, и алгоритм этот не распараллеливается. Впрочем, как и большинство других. Потому-то СПО вроде xz так до сих пор и работает одним потоком, ибо смысла нет. Кстати, я что-то не наблюдаю не только тестов, но и gzip, bzip2, lzma, xz... Ваша маздаевская чашуя мне безразлична.

И да, мне интересно взглянуть на десктопный процессор, который осилит в реальном времени сжимать или расжимать поток данных в более чем 100 Мб/сек

а мне вот интересно посмотреть на файловую систему, которая обеспечит поток файлов со скоростью 100мегабайт в секунду. Причём с записью. Причём хоть с примитивным, но с каким-никаким сжатием. Задачка чутка посложнее, чем примитивный алгоритм LZ77/78.