ну сейчас нам пруф предоставят?

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

Это в твоих надуманных теориях. Поставь, например, lbzip2/pigz и удивись.

Возьмём мощнейшие на данный момент десктопные процессоры и посмотрим на их результаты в архиваторных бенчмарках на распаковку.
Однопоточный WinZip:

Многопоточный WinRAR:

Многопоточный 7zip:

Итого: даже самый мощный и дорогой, притом разогнанный, десктопный проц показал в 7zip 650/28 = 23,2 Мб/сек, и это в 12 потоков. Да лет 5-7 назад винты быстрее работали. А в других тестах показатели ещё плачевнее.

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

С картинками какая-то фигня вышла, вот та тема: http://www.thg.ru/cpu/obzor_intel_core_ … print.html

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

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

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

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

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

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

ы. Линейная она зашкаливает:

$time dd if=/dev/zero of=/mnt/storage/speedtest.bin bs=4K count=10M
10485760+0 записей считано
10485760+0 записей написано
 скопировано 42949672960 байт (43 GB), 323.114 c, 133 MB/c
dd if=/dev/zero of=/mnt/storage/speedtest.bin bs=4K count=10M  16.52s user 27.34s system 13% cpu 5:23.29 total

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

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

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

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

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

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

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

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

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

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

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

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

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