Ru-Board.club
← Вернуться в раздел «Программы»

» Архиваторы. Сравнение сжатия

Автор: TCPIP
Дата сообщения: 25.03.2005 01:31
abz
Все просто. Распаковка ведется в память. Более того, скорее всего, речь идет вообще просто о времени, которое требуется на выполнение операции тестирования...
Автор: abz
Дата сообщения: 25.03.2005 01:35
TCPIP

Цитата:
Распаковка ведется в память.

Так он пишет, что

Цитата:
Запаковка 7мин.,

Тогда как даже физически скопировать такой объём информации просто невозможно! Ну, разве только скази винтом. Но запаковать - это сказка про белого бычка...

Добавлено:
Да и распаковка в память ничего не решит, ведь из памяти нужно ещё записать на диск! Ты всерьёз веришь, что на это удёт 1,5 минуты?

Добавлено:

Цитата:
Более того, скорее всего, речь идет вообще просто о времени, которое требуется на выполнение операции тестирования...

И причём тут тестирование когда он ясно написал:

Цитата:
Запаковка 7мин., а распаковка 1.5мин.!

Автор: TCPIP
Дата сообщения: 25.03.2005 02:23
abz
02:35 25-03-2005
Цитата:
Тогда как даже физически скопировать такой объём информации просто невозможно!

5,4/420 ~ 0.01. То есть всего-то 10 мегабайт в секунду. Почему же нельзя скопировать?
Кстати, если ты копировал
Цитата:
с одного логического диска на другой

то это гораздо медленнее, чем копировать с физического диска на физический диск.

Цитата:
Ты всерьёз веришь, что на это удёт 1,5 минуты?

Ну, тяжело конечно поверить в скорость 60 мегабайт/с.

Цитата:
И причём тут тестирование

Ну, может он чего перепутал, по порядку величины больше похоже на скорость выполнения данной операции...
Автор: abz
Дата сообщения: 25.03.2005 02:58
TCPIP

Цитата:
5,4/420 ~ 0.01. То есть всего-то 10 мегабайт в секунду. Почему же нельзя скопировать?

Потому, что на обычном винте 7200 rpm для этого нужно 11 мин!

Цитата:
Кстати, если ты копировал

Цитата: с одного логического диска на другой


то это гораздо медленнее, чем копировать с физического диска на физический диск.
Автор: TCPIP
Дата сообщения: 25.03.2005 03:15
abz
03:58 25-03-2005
Цитата:
Логично, хотя с трудом в это верится

Ну, видимо, дело в том, что попасть на один и тот же цилиндр и для записи и для чтения маловероятно, поэтому головкам приходится прыгать с места на места, сперва для чтения, потом для записи. Иное дело, когда копирование идет на другой физический диск, головкам на диске-источнике не надо мотаться туда-сюда.

Цитата:
Потому, что на обычном винте 7200 rpm для этого нужно 11 мин!

Тут я соглашусь в том смысле, что так как ты говоришь чаще всего и есть в реальной ситуации. Я имею в виду, что те самые 20-30 мегабайт при записи (и 30-50 при чтении) у меня если и были, то на абсолютно чистом, разве что отформатированном диске, ну да это уже почти не по теме...
Автор: Widok
Дата сообщения: 25.03.2005 17:11
SerIg
abz
TCPIP
за флуд.
Автор: SerIg
Дата сообщения: 25.03.2005 21:33

Цитата:
SerIg

Только что провёл эксперимент. Простое копирование Проводником с одного логического диска на другой (на одном физическом винте 80 Гб 7200 об.) 5,15 Гб. информации (виртуальные СD) на свежедефрагментированном диске заняло у меня 11 мин. 25 сек!!! Машина - Cel2400 (разогнан до 3ГГц) 512 Мб. ОЗУ Мать - Gigabyte GA-8PE800

Так, что твои данные, ну никак не получатся физически, даже если твой архиватор вообще не жмёт, а просто копирует...

abz
Для начала не сравнивай Цел с пнем, его количествой кеша, и 800-й шиной, плюс материнка.

Не веришь не надо, но я огромные игра жму, за такое время, вообщем от 3-15мин. у меня занимало максимум.

Да и память у меня 2x512 DDR400 Samsung.


А вообще сама прога уникально работает, я сам удивился когда её попробовал, скачайте AstrumIW 2.08.00 и убедитесь сами!

Все заканчиваем флудить, а то нас...
Автор: Panzer
Дата сообщения: 28.03.2005 12:40
Немножко самопальных тестов. тестировались:

1. UHARC 0.6a ----- high compression multimedia archiver ----- BETA version
Copyright (c) 1997-2005 by Uwe Herklotz All rights reserved 06 Feb 2005
2. 7-Zip (A) 4.12 beta Copyright (c) 1999-2004 Igor Pavlov 2004-11-18
3. Slim!, PPMII based archiver version: 0.23, 21 Sep 2004
author: Serge Voskoboynikov homepage: http://www.bars.lg.ua/slim/
4. DURILCA, DURILCA-light - dirty useless really illusory compressor/archiver, v.0.4b(non-public)
(C) 2004 by Dmitry Shkarin <dmitry.shkarin@mtu-net.ru>
5. RAR 3.42 Авторские права (C) 1993-2004 Александр Рошал 26 Dec 2004

Архивация занимала не больше минуты.
В каждом пункте приведены архивы и исходник, отсортированы по размеру. Ближайшие цифры к файлу, слева от него - это размер в байтах . Расширения сделаны по возможности мнемоническими. Архив DURILCA: *.dur; DURILCA-light: *.durl; Slim: *.sl
в п.1 приведены вызовы архиваторов с параметрами. Там видно, как получены имена архивов.

1. Файл, содержащий 109 582 английских слов, отсортированных по алфавиту, одно слово в строке
7za.exe a ENG-WORDS.7z -r -y -mx=9 WORDS.TXT -x!*.7z
7za.exe a ENG-WORDS-ppm.7z -r -m0=PPMd -m0mem=128m -m0o=4 WORDS.TXT
UHARC.exe a -m3 -md32768 -pr -r+ ENG-WORDS-alz.uha -d1 WORDS.TXT
UHARC.exe a -mx -md32768 -pr -r+ ENG-WORDS-ppm.uha -d1 WORDS.TXT
slim23d.exe a -v ENG-WORDS.sl WORDS.TXT
DURILCA-l.exe e -t1(7) -fENG-WORDS-doc.durl WORDS.TXT
DURILCA.exe e -t2 -fENG-WORDS-txt.dur WORDS.TXT
rar.exe a -s -m5 ENG-WORDS-m5 WORDS.TXT

27.03.2005 21:19 135 513 ENG-WORDS.sl
27.03.2005 21:18 162 694 ENG-WORDS-ppm.uha
27.03.2005 21:21 185 491 ENG-WORDS-txt.dur
27.03.2005 21:18 234 756 ENG-WORDS.7z
27.03.2005 21:18 237 479 ENG-WORDS-ppm.7z
27.03.2005 21:18 274 812 ENG-WORDS-alz.uha
27.03.2005 21:19 288 781 ENG-WORDS-doc.durl
28.03.2005 14:17 329 046 ENG-WORDS-m5.rar
27.03.2005 21:16 1 154 335 WORDS.TXT

2. The Lord of the Rings, plain text
Приведены только отличающиеся от других тестов параметры
7za.exe a lotr-eng-ppm.7z -r -m0=PPMd -m0mem=128m -m0o=8 lotr-eng.txt
DURILCA-l.exe e -t2 -flotr-eng-txt.durl lotr-eng.txt

27.03.2005 20:33 553 375 lotr-eng-txt.dur
27.03.2005 20:31 569 449 lotr-eng-txt.durl
27.03.2005 20:30 596 442 lotr-eng.sl
27.03.2005 20:29 648 330 lotr-eng-ppm.uha
27.03.2005 20:28 652 369 lotr-eng-ppm.7z
28.03.2005 14:07 652 577 lotr-eng-m5.rar
27.03.2005 20:28 814 146 lotr-eng.7z
27.03.2005 20:28 839 046 lotr-eng-alz.uha
27.03.2005 20:20 2 684 086 lotr-eng.txt

3. ВЛАСТЕЛИН КОЛЕЦ, dos кодировка, plain text
7za.exe a lotr-rus-ppm.7z -r -m0=PPMd -m0mem=128m -m0o=12 lotr-rus.txt
rar.exe a -s -m5 -mc63:128t lotr-rus-m5-mc63-128t lotr-rus.txt

27.03.2005 20:50 517 694 lotr-rus-txt.dur
27.03.2005 20:48 530 630 lotr-rus-txt.durl
27.03.2005 20:47 575 885 lotr-rus.sl
27.03.2005 20:45 623 022 lotr-rus-ppm.7z
28.03.2005 14:23 623 529 lotr-rus-m5-mc63-128t.rar
27.03.2005 20:46 685 382 lotr-rus-ppm.uha
27.03.2005 20:45 782 309 lotr-rus.7z
27.03.2005 20:45 801 544 lotr-rus-alz.uha
27.03.2005 19:29 2 447 988 lotr-rus.txt

4. Сапковский "ВЛАДЫЧИЦА ОЗЕРА" MsWord doc.
DURILCA-l.exe e -t123 -fozero-t123.durl "ВЛАДЫЧИЦА ОЗЕРА.doc"
DURILCA.exe e -t1(7) -fozero-doc.dur "ВЛАДЫЧИЦА ОЗЕРА.doc"
7za.exe a ozero-ppm.7z -r -m0=PPMd -m0mem=128m -m0o=12 "ВЛАДЫЧИЦА ОЗЕРА.doc"

27.03.2005 22:22 302 400 ozero-doc.dur
27.03.2005 22:22 313 800 ozero-t123.durl
27.03.2005 22:19 314 590 ozero.sl
28.03.2005 14:04 330 676 ozero-m5-mc63-128t.rar
27.03.2005 22:18 336 300 ozero-ppm.uha
27.03.2005 22:59 357 626 ozero-ppm.7z
27.03.2005 22:18 373 684 ozero-alz.uha
27.03.2005 22:59 382 693 ozero.7z
16.02.2000 02:39 1 132 032 ВЛАДЫЧИЦА ОЗЕРА.doc

5. Сапковский "ВЛАДЫЧИЦА ОЗЕРА.doc" -> *.rtf через MsWord 2002 SP3.
DURILCA e -t2 -fozero1-txt.dur "ВЛАДЫЧИЦА ОЗЕРА.rtf"
7za.exe a ozero1-ppm.7z -r -m0=PPMd -m0mem=128m -m0o=28 "ВЛАДЫЧИЦА ОЗЕРА.rtf"

27.03.2005 22:37 314 372 ozero1-txt.dur
27.03.2005 22:30 315 667 ozero1.sl
27.03.2005 22:49 332 004 ozero1-ppm.7z
28.03.2005 14:29 346 132 ozero1-m5-mc63-128t.rar
27.03.2005 22:35 396 317 ozero1-t123.durl
27.03.2005 22:49 446 256 ozero1.7z
27.03.2005 22:28 456 220 ozero1-ppm.uha
27.03.2005 22:28 468 893 ozero1-alz.uha
27.03.2005 22:10 3 980 270 ВЛАДЫЧИЦА ОЗЕРА.rtf

6. Сапковский "ВЛАДЫЧИЦА ОЗЕРА.doc" -> *.htm через MsWord 2002 SP3.
7za.exe a ozero-h-ppm.7z -r -m0=PPMd -m0mem=128m -m0o=32 "ВЛАДЫЧИЦА ОЗЕРА.htm"

27.03.2005 23:09 291 302 ozero-h-txt.dur
27.03.2005 23:05 293 727 ozero-h.sl
27.03.2005 23:04 306 911 ozero-h-ppm.7z
27.03.2005 23:06 320 674 ozero-h-txt.durl
27.03.2005 23:04 336 249 ozero-h-ppm.uha
27.03.2005 23:04 389 821 ozero-h-alz.uha
27.03.2005 23:03 407 574 ozero-h.7z
28.03.2005 14:31 416 325 ozero-h-m5-mc63-128t.rar
27.03.2005 22:30 2 498 081 ВЛАДЫЧИЦА ОЗЕРА.htm
Автор: abz
Дата сообщения: 28.03.2005 12:59
Ничего из твоей писанины не понял. Можно как-то более удобочитаемо привести результаты?
Автор: biomednet
Дата сообщения: 28.03.2005 13:27
Panzer
Тэг "more"
разрабатывали специально для Вас.
ВСЕМ! Читайте правила. Они иногда меняются...в лучшую сторону.
abz

Цитата:
Ничего из твоей писанины не понял

Полностью согласен.
набор символов...
Panzer
пожалуйста, отредактируйте свой пост, добавьте комментарии и пояснения.
Автор: Panzer
Дата сообщения: 28.03.2005 14:41
biomednet

Цитата:
пожалуйста, отредактируйте свой пост, добавьте комментарии и пояснения.

попытался

Цитата:
Тэг "more" разрабатывали специально для Вас.

Мне кажется, что либо оставить только анонс и весь тест убрать в "more", либо оставить все как есть. Подожду других высказываний
Автор: TCPIP
Дата сообщения: 28.03.2005 18:13
Panzer
Не указана очень существенная характеристика --- время, затрачиваемое на упаковку и распаковку. И, действительно, хороший вариант для апробации тега [more]
Автор: Lomster
Дата сообщения: 28.03.2005 18:32
Panzer

Цитата:
Мне кажется, что либо оставить только анонс и весь тест убрать в "more", либо оставить все как есть. Подожду других высказываний

Может написать напр. так:

1. Такой-то тест, таких-то архиваторов, т.е. цели, инструментарий, условия, тестовый материал.
2. Выводы: в результате тестирования обнаружилось то-то, выводы можем сделать таке-то.
3. Полный материал тестирования: в тег [more]

2ALL
Предложение: определиться с форматом результатов тестирований, для удобства и удобочитаемости.
Автор: Panzer
Дата сообщения: 29.03.2005 11:08
TCPIP

Цитата:
Не указана очень существенная характеристика --- время, затрачиваемое на упаковку и распаковку.

Указана - упаковка не более минуты во всех случаях. Соответственно распаковка не медленнее. Я решил, что преимущество по скорости в пределах минуты несущественно.
Автор: abz
Дата сообщения: 29.03.2005 23:00
Panzer

Цитата:
Указана - упаковка не более минуты во всех случаях. Соответственно распаковка не медленнее. Я решил, что преимущество по скорости в пределах минуты несущественно.

А что значит второе значение слева направо? Типа, 22:22 22:19 и.т.д.
Автор: TCPIP
Дата сообщения: 30.03.2005 02:28
Panzer
13:08 29-03-2005
Цитата:
Указана - упаковка не более минуты

Все верною Сорри. Одна проблема: думается, что ситуация слишком идеальная --- слишком маленькие объемы информации рассматриваются. Нетипичная задача в данном случае, ибо, как мне кажется, экспериметры с максимальным сжатием экспериметральными архиваторами следует проводить на больших (порядка гигабайта) данных, когда разница в результате в несколько десятков мегабайт имеет смысл (ну-ка хранить атулуковскую базу в zip (даже в RAR) или в 7z!). Небольшие массивы (документы и прочее) обычно имеет смысл сжимать просто раром --- без лишней головной боли --- быстро и результативно. Здесь же можно сопоставить временные затраты (они могут расти нелинейно, как в случае с RK: одно дело подождать 10 минут, как с RAR, другое дело --- несколько часов, как с RK). На интервале же в 1 минуту их, согласитесь, не оценить, что ведет к бессмысленности проведения указанного эксперимента...
Автор: Viewgg
Дата сообщения: 01.04.2005 17:05

Цитата:
Не указана очень существенная характеристика --- время, затрачиваемое на упаковку и распаковку.

А вам не кажется, что тема называется так:
Цитата:
Какой архиватор отличается максимальным сжатием?

Посему публиковать время сжатия здесь, на мой взгляд, бессмысленно. Можно сделать в другой теме - впрочем, это на усмотрение модератора.
TCPIP

Цитата:
экспериметры с максимальным сжатием экспериметральными архиваторами следует проводить на больших (порядка гигабайта) данных

Не согласен, поскольку очень важная задача подобных архиваторов - сжатие для переправки через Интерент, где часто прихолится брать малые объемы, а 10 Кб уже имеют значение.
Panzer
Сделайте хотя бы простейшую таблицу, хоть в Блокноте! Тогда всё сразу станет ясно. Сам я оформлял криво, но хоть понять можно:
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=220#19
Автор: Benchmark
Дата сообщения: 01.04.2005 17:41
Viewgg

Цитата:
Не согласен, поскольку очень важная задача подобных архиваторов - сжатие для переправки через Интерент, где часто прихолится брать малые объемы, а 10 Кб уже имеют значение.

При быстром модемном коннекте (56k или V90) даже 100 Кб не имеют значения. А на выделенке и, тем более, DSL, и 10 мег погоды не делают совершенно.

Например мне для того, чтобы максимально быстро сжать и закачать данные на фтп (т.е. имеет значение время сжатия + время закачки), выгоднее всего пользоваться RAR с минимальной компрессией (-m1 или -m2). Если пользоваться более мощной (и занимающей больше времени) компрессией того же RAR'a, или медленными архиваторами вроде 7zip и WinRK, то проигрышь получается по времени. Причем при больших объемах данных - значительный.
Автор: arsvrn
Дата сообщения: 01.04.2005 17:51
Viewgg

Цитата:
публиковать время сжатия здесь, на мой взгляд, бессмысленно

Позволю себе возразить против такого мнения, потому что

Цитата:
сжатие для переправки через Интерент

лишь одна из задач архивирования. Не менее важная задача, например - архивирование баз данных (в том числе и ежедневное), объемами сотни Мб. Да и просто отнести домой какой-нибудь дистрибутив на флэшке тоже нередко надо.
А если время не интересует, давайте пользовать WinRK - он все-таки заметно лучше других жмет (но время...).
Автор: TCPIP
Дата сообщения: 02.04.2005 01:50
Viewgg
19:05 01-04-2005
Цитата:
А вам не кажется, что тема называется так:



Цитата:
сжатие для переправки через Интерент,

Так то оно так. Только если вы кому-то пришлете 314 372 ozero1-txt.dur сомневаюсь, что он оценит такую экономию по сравнению с 332 004 ozero1-ppm.7z, так как прийдется искать durilca и прочее. Хотя, для персонального онлайн-бекапа, почему бы и нет?
Benchmark
19:41 01-04-2005
Цитата:
А на выделенке и, тем более, DSL, и 10 мег погоды не делают совершенно.

Здесь не соглашусь. Например зараренный имаж диска скачивается куды быстрее (даже на хорошем канале), чем зазипленный и уж тем более голый. К сожалению, встроенная в протокол компрессия --- лишь способ компенсации передачи текстов.
arsvrn
19:51 01-04-2005
Цитата:
лишь одна из задач архивирования. Не менее важная задача, например - архивирование баз данных (в том числе и ежедневное), объемами сотни Мб. Да и просто отнести домой какой-нибудь дистрибутив на флэшке тоже нередко надо.

Именно об этом я и говорю. Можно кстати переменовать тему в Какой архиватор самый оптимальный? (понятно, что в данном случае речь идет о чисто эмпирическом выборе оптимальности )
Автор: Benchmark
Дата сообщения: 02.04.2005 12:51
TCPIP

Цитата:
Например зараренный имаж диска скачивается куды быстрее (даже на хорошем канале), чем зазипленный и уж тем более голый.

Речь идет не про скачивание, а про компрессию + закачивание. Т.е. чтобы кто-то скачал этот имидж, надо чтобы ты его сначала сжал и закачал на фтп.

Вот тут и начинается самое интересное. Посчитай, сколько уйдет на твоей машине времени на архивирование образа диска ZIP'ом, и сколько - RAR'ом в минимальной (-m1 или -m2), и в максимальной компрессии (-m5). И прибавь к этому время, которое тебе нужно, чтобы после сжатия закачать все это добро на фтп (т.е. зависит от скорости твоего upload'a).


Цитата:
Можно кстати переменовать тему в Какой архиватор самый оптимальный? (понятно, что в данном случае речь идет о чисто эмпирическом выборе оптимальности )

Вот тут полностью согласен. Только нужно будет определить эти самые критерии оптимальности. Хотя бы примерно.
Автор: arsvrn
Дата сообщения: 02.04.2005 15:16
TCPIP
Benchmark

Цитата:
Только нужно будет определить эти самые критерии оптимальности

Ясно, что для каждого пользователя эти самые критерии будут различными. Поэтому по моему мнению надо в результатах тестирования просто указывать и сжатие и время. А дальше пусть пользователь сам определяет, какой архиватор для его целей оптимальней.
Автор: Panzer
Дата сообщения: 02.04.2005 19:28
Немножко самопальных тестов. тестировались:
UHARC 0.6a, 7-Zip 4.16 beta, Slim! 0.23, DURILCA & DURILCA-light v.0.4b, RAR 3.42, WinUDA 0.290
[more]
1. UHARC 0.6a ----- high compression multimedia archiver ----- BETA version
Copyright (c) 1997-2005 by Uwe Herklotz All rights reserved 06 Feb 2005
2. 7-Zip (A) 4.12 beta Copyright (c) 1999-2004 Igor Pavlov 2004-11-18
3. Slim!, PPMII based archiver version: 0.23, 21 Sep 2004
author: Serge Voskoboynikov homepage: http://www.bars.lg.ua/slim/
4. DURILCA, DURILCA-light - dirty useless really illusory compressor/archiver, v.0.4b(non-public)
(C) 2004 by Dmitry Shkarin <dmitry.shkarin@mtu-net.ru>
5. RAR 3.42 Авторские права (C) 1993-2004 Александр Рошал 26 Dec 2004
6. WinUDA 0.290 (c) 2004-2005 By Dwing
[/more]
Архив DURILCA: *.dur; DURILCA-light: *.durl; Slim: *.sl; UHARC: *.uha; WinUDA: *.uda
В каждом пункте приведены архивы и исходник, отсортированы по размеру.

Компьютер: Microsoft Windows XP Professional 5.1.2600 Service Pack 2 Сборка 2600
Процессорx86 Family 6 Model 4 Stepping 2 AuthenticAMD ~700 МГц
Полный объем физической памяти 512 МБ
Время замерялось с помощью Timer 3.01 Copyright (c) 2002-2003 Igor Pavlov 2003-07-10. (PT = Process Time)

1. Русский текст (все про Рекса Стаута с lib.ru ), dos кодировка.
Исходно 74 файла, 16 155 082 байт. Собрано в tar. Пробовалось непосредственно для *.txt, и для собранных в tar, показан лучший результат.

16 211 968 txt-rus-big.tar

3 280 851 rus-tar.dur PT = 229.019 = 00:03:49.019
3 372 198 rus-tar.durl PT = 31.775 = 00:00:31.775
3 545 872 rus-tar.sl PT = 548.238 = 00:09:08.238
3 845 427 rus-tar.uda PT = 1539.834 = 00:25:39.834
3 870 169 rus-tar-ppm.7z PT = 35.040 = 00:00:35.040
4 085 758 rus-tar-ppm.rar PT = 55.800 = 00:00:55.800
4 424 433 rus-tar-ppm.uha PT = 166.138 = 00:02:46.138

вызовы архиваторов с параметрами:[more]
7za.exe a rus-tar-ppm.7z -r -m0=PPMd -m0mem=256m -m0o=10 txt-rus-big.tar
rar.exe a -s -m5 -mc63:128t rus-tar-ppm.rar txt-rus-big.tar
UHARC.exe a -d0 -mx -md32768 -pr -r+ rus-tar-ppm.uha txt-rus-big.tar
slim23d.exe a -v rus-tar.sl txt-rus-big.tar
durILCA-l.exe e -t2 -frus-tar.durl txt-rus-big.tar
durILCA.exe e -t2 -frus-tar.dur txt-rus-big.tar
winuda (mode 3)
[/more]

2. English html. Wayne Magnuson: English Idioms.
8,97 МБ (9 413 026 байт), 928 файлов, 3 папки. Собрано в Magn.tar .

10 145 792 Magn.tar

344 760 Magn.sl PT = 129.636 = 00:02:09.636
389 520 Magn-txt.dur PT = 402.879 = 00:06:42.879
392 790 Magn-tar.uda PT = 779.631 = 00:12:59.631
404 369 Magn-ppm.7z PT = 6.299 = 00:00:06.299
461 328 Magn-txt.durl PT = 5.087 = 00:00:05.087
490 679 Magn-ppm.uha PT = 13.699 = 00:00:13.699
618 041 Magn-ppm.rar PT = 20.829 = 00:00:20.829

вызовы архиваторов с параметрами: [more]
7za.exe a Magn-ppm.7z -r -m0=PPMd -m0mem=256m -m0o=22 Magn.tar
rar.exe a -s -inul -m5 -mc63:128t+ Magn-ppm Magn.tar
UHARC.exe a -d0 -mx -md32768 -pr -r+ Magn-ppm.uha Magn.tar
slim23d.exe a -v Magn.sl Magn.tar
durILCA-l.exe e -t2 -fMagn-txt.durl Magn.tar
durILCA.exe e -t2 -fMagn-txt.dur Magn.tar
winuda (mode 3)
[/more]

3. English html. JDKTM 5.0 Documentation с http://java.sun.com/j2se/1.5.0/download.jsp#docs
Исходно jdk-1_5_0-doc.zip. В распакованном виде 223 МБ (234 575 176 байт), 10779 файлов (html), 711 папок. Собрано в tar.
Интересно, что исходный zip с низкой степенью сжатия - totalCommander за секунды (точно не считал )делает zip почти вдвое меньше.

27 982 762 docs-tc.zip totalCommander
45 635 523 jdk-1_5_0-doc.zip
243 221 504 docs.tar

12 570 679 docs-tar.uda PT = 14420.525 = 04:00:20.525
12 671 596 huge-docs-t1.dur PT = 10562.738 = 02:56:02.738
12 784 436 huge-docs-512.sl PT = 5072.675 = 01:24:32.675
14 301 136 huge-docs-ppm.uha PT = 601.544 = 00:10:01.544
14 608 476 huge-docs-ppm.7z PT = 183.283 = 00:03:03.283
16 508 238 huge-docs-t2.durl PT = 172.297 = 00:02:52.297
17 114 242 huge-docs-ppm.rar PT = 391.292 = 00:06:31.292

вызовы архиваторов с параметрами: [more]
7za.exe a huge-docs-ppm.7z -r -m0=PPMd -m0mem=256m -m0o=32 docs.tar
rar.exe a -s -m5 -mc63:128t huge-docs-ppm docs.tar
UHARC.exe a -d0 -mx -md32768 -pr -r+ huge-docs-ppm.uha docs.tar
DURILCA.exe e -t1 -fhuge-docs-t1.dur docs.tar
durILCA-l.exe e -t2 -fhuge-docs-t2.durl docs.tar
slim23d.exe a -m512 huge-docs-512.sl docs.tar
winuda (mode 3)
[/more]

4. *.dll из Windows\system32, 229 файлов, 52 504 082 байт. Собраны в tar.
Пробовалось непосредственно для *.dll, и для собранных в tar, показан лучший результат.
52 504 082 *.dll
52 626 944 system32.TAR

12 989 999 dll-TAR-t1.dur PT = 2270.574 = 00:37:50.574 (14:22.250 на Athlon 2.0 ГГц)
13 967 090 dll.uda PT = 3765.845 = 01:02:45.845
14 781 817 dll-TAR-t1.durl PT = 781.063 = 00:13:01.063
14 887 666 dll.sl PT = 5127.733 = 01:25:27.733
15 184 229 dll.7z PT = 309.024 = 00:05:09.024
15 469 537 dll-ppm.uha PT = 498.957 = 00:08:18.957
17 443 045 dll-ppm.rar PT = 182.171 = 00:03:02.171

вызовы архиваторов с параметрами: [more]
7za.exe a dll.7z -r -y -mx=9 *.dll
rar.exe a -s -inul -m5 -mc63:128t+ dll-ppm.rar *.dll
UHARC.exe a -d0 -mx -md32768 -pr -r+ dll-ppm.uha *.dll
slim23d.exe a -v dll.sl *.dll
durILCA-l.exe e -t1 -fdll-TAR-t1.durl system32.TAR
DURILCA.exe e -t1 -fdll-TAR-t1.dur system32.TAR
winuda (mode 3)
[/more]

5. 4 *.exe файла от MS Office XP. Пробовалось непосредственно для *.exe, и для собранных в tar, показан лучший результат.

5 777 936 MSACCESS.EXE
5 990 928 POWERPNT.EXE
9 189 896 EXCEL.EXE
10 623 688 WINWORD.EXE
31 582 448 *.exe
31 586 816 msof.tar

9 229 184 msof.sl PT = 1173.317 = 00:19:33.317
9 434 635 msof-tar.dur PT = 902.227 = 00:15:02.227 (05:57.984 на на Athlon 2.0 ГГц)
10 784 341 msof-tar.durl PT = 160.731 = 00:02:40.731
11 186 516 msof.uda PT = 2496.700 = 00:41:36.700
11 697 363 msof.7z PT = 191.685 = 00:03:11.685
11 874 794 msof-ppm.uha PT = 362.551 = 00:06:02.551
13 710 026 msof-ppm.rar PT = 134.353 = 00:02:14.353

вызовы архиваторов с параметрами:[more]
7za.exe a msof.7z -r -y -mx=9 *.exe -x!*.7z
slim23d.exe a msof.sl *.exe
UHARC.exe a -d0 -mx -md32768 -pr -r+ msof-ppm.uha *.exe
rar.exe a -s -m5 -mc63:128t msof-ppm.rar *.exe
DURILCA-l.exe e -t1 -fmsof-tar.durl msof.tar
DURILCA.exe e -t1 -fmsof-tar.dur msof.tar
winuda (mode 3)
[/more]
6. Смесь файлов из предыдущих тестов + bmp. Пробовалось непосредственно для *.*, и для собранных в tar, показан лучший результат.
Исходники:
1 594 394 poster3.bmp (784 917 poster3.sl; 802 301 poster3-alz.uha)
2 067 968 cdosys.dll
2 447 988 lotr-rus.txt
2 684 086 lotr-eng.txt
5 760 054 IMG_5773.bmp (1 731 168 IMG_5773-ppm.uha; 2 377 765 IMG_5773.sl)
5 990 928 POWERPNT.EXE

20 545 418 *.*
20 551 168 mix.tar

Результаты:
5 473 603 mix-t3.dur PT = 330.995 = 00:05:30.995
5 914 749 mix-t3.durl PT = 47.798 = 00:00:47.798
6 107 348 mix.uda PT = 1514.097 = 00:25:14.097
6 166 358 mix.sl PT = 588.255 = 00:09:48.255
6 207 962 mix-ppm.uha PT = 213.496 = 00:03:33.496
6 369 617 mix-tar-ppm.rar PT = 52.425 = 00:00:52.425
6 401 390 mix-ppm.rar PT = 52.655 = 00:00:52.655
6 569 054 mix.rar PT = 50.332 = 00:00:50.332
7 159 421 mix-ppm.7z PT = 61.588 = 00:01:01.588
7 599 550 mix.7z PT = 106.553 = 00:01:46.553
10 317 184 mix.zip TC zip; быстро

вызовы архиваторов с параметрами:[more]
durILCA e -t3 -fmix-t3.dur *.*
durILCA-l e -t3 -fmix-t3.durl *.*
winuda (mode 3)
slim23d a mix.sl *.*
UHARC a -d0 -mx -md32768 -pr -r+ mix-ppm.uha .\a\*.*
rar a -s -inul -m5 -mc63:128t+ mix-tar-ppm.rar mix.tar
rar a -s -inul -m5 -mc63:128t+ mix-ppm.rar .\a\*.*
rar a -s -inul -m5 mix.rar .\a\*.*
7za a -r -m0=PPMd -m0mem=128m -m0o=32 mix-ppm.7z .\a\*.*
7za a -r -y -mx=9 mix.7z .\a\*.* -x!*.7z
[/more]
Автор: TCPIP
Дата сообщения: 02.04.2005 23:44
Benchmark
14:51 02-04-2005
Цитата:
И прибавь к этому время, которое тебе нужно, чтобы после сжатия закачать все это добро на фтп (т.е. зависит от скорости твоего upload'a).

Здесь спору нет, если upload ведется для хранилища. А если потом закаченное будут скачивать десятки раз?..
arsvrn
17:16 02-04-2005
Цитата:
А дальше пусть пользователь сам определяет, какой архиватор для его целей оптимальней.

Именно. Нужно обозначить для пользователя некоторые опорные точки, чтобы он знал на что ему следует ориентироваться для выполнения той или иной задачи:

хранение данных
обмен данными

Panzer
Кстати, а как и чем вы вели подсчет времени? И вообще, если возможно, не могли бы вы поделиться know-how по проведению подобных тестов? Примеры бетч-файлов, программ подсчета.
Автор: Viewgg
Дата сообщения: 03.04.2005 21:30
Panzer
Это интересно, что UHARC показал на сжатии худшие результаты, чем 7-ZIP и RAR! Насколько я замечал, в этих тестах (в моих, на сайтах) он всегда выигрывал!
Автор: TCPIP
Дата сообщения: 04.04.2005 01:22
Viewgg
Вроде бы, архиватор от Uwe показывает себя на мультимедийных данных, а здесь бинарники. Хотя, на английском текстовике я тоже не ожидал...
Автор: arsvrn
Дата сообщения: 04.04.2005 13:25
К тесту Panzer'а могу добавить результат по WinRK. К сожалению, только для его набора exe файлов, так как других наборов не имею (а качать 45 Мб не хочу). Для сжатия использовался кодек PWCM с размером модели 256 Мб.

Исходный размер 31 582 448 байт.
После сжатия: 9 488 020 байт.

Время на сжатие более 2 часов. Точно не замерял ввиду кривой конфигурации компа:
Athlon 2.0 ГГц, зато мать на KT133A (шина 133 МГц), 512 Мб ОЗУ.

Viewgg
Проверил UHArc на этом наборе. У Panzer'а все точно.
Автор: TIHb
Дата сообщения: 04.04.2005 19:59
Народ у меня вот такая фигня. Скачал через емуль GTA:VICE CITY -239Mb в sfx архиве.
Распаковал там 7 uha, pack.exe и unpack.exe короче запустил unpack.exe пишет UHARC 0.4 подождал немножко (меньше минуты) пока оно мне в командной строке что-то писало, и опа. Все uha исчезли появилась нормальная игра (даже в реестр прописалось). Игра занимает 1.26 Gb. Но сколько я над этой игрой не ворожил с UHARC 0.4 у меня только фигня и получалась. Один фалй 312Mb зжался до 281Mb, а это уже больше.
PS в командной строке оно не только писало что какой-то файл сейчас разпаковывается но и например "превращаем sound.swx в sound.wav" (только на английском). Может кто знает как это получаеться у некоторых??????!!!!!!
Автор: TCPIP
Дата сообщения: 05.04.2005 01:46
TIHb
20:59 04-04-2005
Цитата:
"превращаем sound.swx в sound.wav" (только на английском). Может кто знает как это получаеться у некоторых??????!!!!!!

Если это релиз от Myth то там обычно все делается с помощью бетч-файлов. Посмотрите, что там за ключи используются. Чтобы окно не закрывалось, можно запускать uha через интрепретатор: cmd /k uha.
Автор: Sav
Дата сообщения: 05.04.2005 16:00
TIHb
20:59 04-04-2005
Цитата:
"превращаем sound.swx в sound.wav"

Возможно, например, что они сконвертировали звук в mp3 (с потерями), а при унпаке восстанавливают wav файл (правда, отличающийся от оригинального, но звучащий почти также).

Страницы: 12345678910111213141516171819202122232425262728293031

Предыдущая тема: canopus pro coder


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.