» FreeArc: бесплатный open-source архиватор - Часть 3

Угу, и последнее подтверждение тому факту, что скоростью/врменем lzma я серёзно лоханулся - этот файл сжимался без торрента фа фоне (который у меня всё время в фоне раздаёт, хотя скорость там гуляет от 300 до 1200 Кб/c) и только с 3-мя открытыми окнами броузера (в которых только текст форумов, нету ничего грузящего систему):

rep128+srep128+lzma 3.827.972.128 => 3.294.530.391 bytes. Ratio 86.0%
Compression time: cpu 7282.85 secs, real 5258.24 secs. Speed 728 kB/s

Так что из всех моих тестов стоит смотреть только на объём... Который тут меняется в пределах 4 Мб, минимум был srep256x2+lzma - 3 293 098 543 bytes, и на 45 619 байт больший srep512+lzma. А максимум (с куда более заметным отрывом от остальной группы) дали
srep16k+rep:512+lzma - 3 297 558 600
srep16k+lzma - 3 297 546 174
srep128+rep128+lzma - 3 297 289 110. Т.е. разница между самым большим и самым малым - 4 460 057 байт, всего лишь 0.14%.

Думаю, смысла в тестировании rep+srep+rep - вообще никакого, потому что разница там не превышает 4 Мб по сравнению с такими же настройками rep+srep - и она скорее всего станет ещё меньше после lmza.

Добавлено:
Так, на ненагуженной системе lzma:959mb:h768mb:mc3 работает чуть ли не быстрее, чем rep:1700mb:a99:h27 . Я прав, что для скорости ht4 очень важно отношение размера хэша к значению mc - т.е. 768mb/3=256 mb тут сильно ускоряет это дело?
Да, тут обозначение lzma:ht4:mc3=lzma:959mb:h768mb:normal:32:mc3

rep:512+srep-512+lzma:ht4:mc3 - 4.002.779.320 => 3.320.549.950 bytes. Ratio 82.9%
Compression time: cpu 3275.88 secs, real 2193.39 secs. Speed 1.825 kB/s

srep-256+srep-256+lzma:ht4:mc3 - 3.997.881.040 => 3.320.147.004 bytes. Ratio 83.0%
Compression time: cpu 3281.36 secs, real 2145.80 secs. Speed 1.863 kB/s

srep-256+lzma:ht4:mc3 - 4.011.245.268 => 3.320.216.844 bytes. Ratio 82.7%
Compression time: cpu 3611.02 secs, real 2105.63 secs. Speed 1.905 kB/s

srep-16kb+lzma:ht4:mc3 - 4.572.251.124 => 3.321.789.954 bytes. Ratio 72.6%
Compression time: cpu 3366.94 secs, real 2254.44 secs. Speed 2.028 kB/s

В итоге - такой lzma в 2-3 раза быстрее lzma:max:192mb:lc8 . При этом сжимает всего лишь на 27-23 Мб слабее - т.е. где-то на 0.8% для srep256. И главное, опять разница сжатых данных между разными minlen srep и rep не выходит за пределы 2 Мб, даже если та - целые 16kb.

Bulat_Ziganshin
Star Ocean: The Last Hope [PAL/ENG] [3-DVD9] xbox 360
в наличии пока 2 диска
немного статистики по ним
изначально iso пожаты были rar Скоростной размер в скобочках
s-so1.iso 7475.5МБ - (rar 6826.3МБ)
s-so2.iso 7475.5МБ - (rar 6797.2МБ)
s-so3.iso 7475.5МБ - (rar 6854.9МБ)
итого 22426.5МБ(21.9ГБ) - (rar 20478.4МБ(~20ГБ))

по одиночке
rep:1024m
s-so1.iso - 5716.5МБ
s-so2.iso - 5146.2МБ
в сумме = 10862.7МБ

srep
s-so1.iso - 5478.1МБ
s-so2.iso - 4950.5МБ
в сумме = 10428.7МБ

вместе
rep:1024m
s-so1.iso + s-so2.iso - 10862.7МБ

srep
s-so1.iso + s-so2.iso - 8835.1МБ

Ghost2004
egor23 - друзья, давайте под тег more прятать простыни, если не против.

Alex Zaguzin
всё что должно быть под more, прячиться под more
или "переписку" тоже под more прятать советуете?

PS: отвечать на вопрос не нужно.

Так,
srep-16kb+lzma:959mb:h928mb:normal:32:mc29:lc8 выдал вот что:
4.572.251.124 => 3.301.558.513 bytes - и проиграл по скорости да сжатию lzma:192mb:max:lc8, хотя и не сильно. (Хотя насчёт скорости не уверен - там система у меня чуть свовсем в процессе не поисла). Так что решил пока оставить этот тест.

egor23
Тоже начал разбираться со Star Ocean'ом. Все три диска srep сжимает так:
Compression ratio: 23516091904 -> 13137095188: 55.86%. Cpu 5.332 mb/sec, real 3.800 mb/sec
(правда, при сжатии работающий торрент мог чуть помешать+фрагментация того файла на 23 Гб составляла аж 1354 фрагмента)

Т.е. с Мб которые 2^20 - вот что выходит.
22426.693 Мб -> 12518.974 Мб

Да, и ещё - специально затарил и в неудобном для кеширования виде "s-so1.iso+s-so3.iso+s-so2.iso". Тест распаковки вот что выдал:
Cpu 162.776 mb/sec, real 15.323 mb/sec

Kernel Time = 165.875 = 00:02:45.875 = 10%
User Time = 144.484 = 00:02:24.484 = 9%
Process Time = 310.359 = 00:05:10.359 = 20%
Global Time = 1535.297 = 00:25:35.297 = 100%

Конечно, не так внушительно, как 25 Мб/с в прошлый раз, но всё равно очень впечатляет.
Торрент я отключил по такому случаю, да и фрагментации сжатого файла почти не было - 3 фрагмента - и это на 13 Гб... Да, и ещё - памяти свободной было много - 1.5-2 Гб, с системным кэшем проблем не было... Правда, система была загружена без /3G, чтобы DXVA работало и видео можно было смотреть не нагружая процессор. Да, и ещё - у распакованного файла стало всего 97 фрагметов - не так много для такого размера.

Если надо - логи srep есть (в смысле информация -s), и для компрессии этих 23 Гб и для их декомпрессии. Можно ещё попробовать собрать 23 Гб как 1+2+3 (а не 1+3+2) - может, так srep ускорится... Обычный rep пока не тестил - но пока у меня только 2 Гб на один процесс, так что больше rep:1gb не выйдёт...

А, ну да, я и забыл. У ват тут блог

Цитата:

real 15.323 mb/sec

отлично! хотя я таки не понял, какое -l при этом было

Alex Zaguzin
egor23
Bulat_Ziganshin

вот и я хотел заметить, что, если забредёт сюда какой-нть _обычный_ пользователь в поиске ответов на свои _простые_ вопросы - все эти "простыни" с логами, тоннами настроек, и пр. его просто испугают

может, стоит все эти технические обсуждения как-то отделить?
создать специальный топик для "энтузиастов сжатия FreeArc"?
а здесь оставить новости о выходе новых версий и прочее _обычное_ обсуждение программы (с резюмированием наиболее интересных и важных находок "энтузиастов" - как например, про 2+ ГБ в шапке)

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

А что вообще тут делать "обычному пользователю"? По-моему, пока здесь только бета-тестеры, или я неправ, и кто-то без затей использует архиватор в повседневной деятельности?

Bulat_Ziganshin

Цитата:

отлично! хотя я таки не понял, какое -l при этом было

Стандартный 512.

Да, действительно, так живо обговаривается тема про srep, а реальный глюк вызывает мало интереса.
Сколько еще раз мне надо сказать о том, что есть проблема в unarc.dll, чтобы ею как-то заинтересовались, не на уровне отписок? Ну не впервые же! Или пусть оно так и будет... Как бы решение я нашел сам, а там кто еще с таким же глюком столкнется пусть пеняет на себя.
А проблема-то достаточно живая, особенно в свете того, что фа не умет бить на тома и что жмет сгруппированные данные одного типа по отдельности лучше, чем все в одном, смешанном...
Как еще описать проблему, какие еще данные надо предоставить, учитывая что unarc.dll никак не логается, я не знаю. Короче я забиваю, когда заинтересуешся, Булат, у тя есть моя аська.

Цитата:

какие еще данные надо предоставить

архив. но подожди сегодняшнего обновления проги, попробуешь с новой dll, я там исправил выделение памяти в tta

Да, больше на USB-винчестер жать ничего не стану. Итак, результаты обычной rep:1gb:h27:a99 -
23.516.091.904 => 17.227.395.259 bytes. Ratio 73.2%
Compression time: cpu 3615.30 secs, real 6951.05 secs. Speed 3.383 kB/s
Т.е. srep сжал в 1.3 раза лучше.

new version:

* UAC compatibility - when you change Explorer Integration in the Settings dialog, it asks your permission
* allow to enable/disable Personal Settings and Explorer Integration due installation
* SREP added to PowerPack and arc.ini
* TTA: improved memory handling
* -mex1..5: added fast compression for already compressed files
* UI: use "1,234,567" instead of "1.234.567"


Добавлено:
Ghost2004
для -mex5t необходима facompress.dll

Цитата:

для -mex5t необходима facompress.dll

Скорее это у меня arc.ini был 9 ноября, и не хотел обновляться при запуске инсталляторов. Сейчас его убрал-переименовал, и встал новый - сразу заработали и -mex5t и -msrep (вручную я его в arc до этого так и не прописал, не успел).

Добавлено:
Не, ошибся - всё равно не работает - хоть facompress.dll сегодняшней версии лежит в каталоге freearc'а . Та же ошибка вылезает "invalid compression method or parameters in 4x4:b7mb:ppmd:8:96mb:c7mb" - как только dict+lzp обрабатывают первый блок. Нужна какая-то особая версия facompress.dll?

Цитата:

для -mex5t

что=то ты напутал. помести сегодняшние arc.exe и facompress.dll в один каталог и дай в нём команду arc a a -mex5t

Bulat_Ziganshin

Цитата:

что=то ты напутал. помести сегодняшние arc.exe и facompress.dll в один каталог и дай в нём команду arc a a -mex5t

Возможно, только не пойму что. Вот что по любому выдаёт:

FreeArc 0.60 RC (November 30 2009) creating archive: a.arc
Compressing 4 files, 3,154,944 bytes. Processed 0% 11%
ERROR: invalid compression method or parameters in 4x4:b7mb:ppmd:8:96mb:c7mb
.
Хоть оставляй path (с каталогом инсталляции freearс'а), хоть его убирай...

Bulat_Ziganshin

Цитата:

arc a a -mex5t

тоже самое
ERROR: invalid compression method or parameters in 4x4:b7mb:ppmd:8:96mb:c7mb
[more=лог..]
arc a a -mex5t -di -di+$#
FreeArc 0.60 RC (November 30 2009) Creating archive: a.arc using dict:64mb:80%:l8192:m400:s100+lzp:64mb:90%:65:h20:d1mb:s16+4x4:b7mb:ppmd:8:96mb:c7mb
Memory for compression 320mb, decompression 320mb, cache 64mb
Started: 0.00 secs
Found 60 files: 0.00 secs
Sorted 60 files: 0.02 secs
Joined filelists, 60 files: 0.02 secs
Compressing 60 files of 20,808,601 bytes: 0.19 secs
Using dict:21mb:80%:l8192:m400:s100+lzp:21mb:90%:65:h20:d1mb:s16+4x4:b7mb:ppmd:8:96mb:c7mb
Memory for compression 299mb, decompression 2 12%
ERROR: invalid compression method or parameters in 4x4:b7mb:ppmd:8:96mb:c7mb
[/more]

Ghost2004
помести сегодняшние arc.exe и facompress.dll в один каталог и дай в нём команду arc a a -mex5t. у меня: [more]FreeArc 0.60 RC (November 30 2009) Creating archive: a.arc using dict:64mb:80%:l8192:m400:s100+lzp:64mb:90%:65:h20:d1mb:s16+4x4:b7mb:ppmd:8:96mb:c7mb
Memory for compression 800mb, decompression 800mb, cache 64mb
Started: 0.01 secs
Found 2 files: 0.01 secs
Sorted 2 files: 0.01 secs
Joined filelists, 2 files: 0.02 secs
Compressing 2 files of 3,154,944 bytes: 0.02 secs
Using dict:3113kb:80%:l8192:m400:s100+lzp:3113kb:90%:65:h20:d1mb:s16+4x4:b7mb:ppmd:8:96mb:c7mb
Memory for compression 770mb, decompression 7100%
Solid block compression results (0.140 seconds)
dict:3113kb:80%:l8192:m400:s100: 2,430,849 bytes in 0.062 seconds
lzp:3113kb:90%:65:h20:d1mb:s16: 2,430,853 bytes in 0.078 seconds
4x4:b7mb:ppmd:8:96mb:c7mb: 986,302 bytes in 0.000 seconds

Writing directory: 1.01 secs
Found 1 directory names: 1.01 secs
Directory written: 1.01
Compressed 2 files, 3,154,944 => 986,302 bytes. Ratio 31.2%
Compression time: cpu 0.90 secs, real 1.02 secs. Speed 3,084 kB/s
Decoding directory: 0.00 secs
Directory decoded: 0.01 secs
Directory built: 0.01 secs
Solid block decompression results (0.031 seconds)
4x4:b7mb:ppmd:8:96mb:c7mb: 2,430,853 bytes in 0.000 seconds
lzp:3113kb:90%:65:h20:d1mb:s16: 2,430,849 bytes in 0.016 seconds
dict:3113kb:80%:l8192:m400:s100: 3,154,944 bytes in 0.016 sec
Testing time: cpu 0.78 secs, real 0.88 secs. Speed 3,593 kB/s
All OK[/more]

Bulat_Ziganshin

Цитата:

у меня

хм
запустил на Win7 работает
а WinXP не работает

Добавлено:

Цитата:

а WinXP не работает

также не работает и на WinXP x64

new version:

* fixed problem with registering ArcShellExt-64.dll

http://freearc.org/download/research/srep08.zip updated: added Linux executable

насчёт -mex5t: выяснилось что facompress.dll не грузится в xp-32, хотя прекрасно работает в vista64 и win7-32. думаю, в чём может быть дело... может и не в самих ОС, а каких-то конкретных настройках моих экземпляров..

отпишите ваши ос и работает или нет -mex5t

Bulat_Ziganshin
Насчёт srep08 - я правильно понимаю, существует вероятность около 10^-40 (т.е. ~2^-128) для 2x512 mb хеша (+1 gb), что в файле обнаружится некорректное совпадение, и ещё 10^-73 - (2^-256), что и md5 его не заметит, и не сообщит об некорректном блоке в процессе декомпрессии?

Тогда стоит добавить в arc.ini метод не как srep, а srep08 (и вписать на данный момент srep=srep08) - всё таки даже такие бесконечно малые вероятности могут взять и случиться вопреки всему ... Так что в следующих версиях с этим надо что-то сделать.

Проще всего, в качестве быстрой заплатки, сделать проверку на такую ошибку на стадии компрессии - добавив декомпрессию после каждого сжимаемого блока на 8 mb, и сравнив исходного сжимаемый блок, с блоком после компрессии-редекомпрессиии (как оно делается в видео-кодеках, хотя там считается разница).

В таком режиме даже md5 считать не надо. Просто по скорости декомпресии у меня выходило 15-25 Мб/c, а вот скорость компрессии была Cpu 5.332 mb/sec, real 3.800 mb/sec - на тех 23 Гб, с l512 (а декомпрессия давала 15 Мб/с). Впрочем, на прошлых 7.5 Гб данных с с l16kb она могла достигать до Cpu 19.196 mb/sec, real 14.998 mb/sec - при декомпрессии в 20.236 mb/sec. На меньших длинах было вот что:

l128 - Cpu 7.160 mb/sec, real 6.477 mb/sec - компрессия, 21.505 mb/sec - декомпрессия.
l256 - Cpu 7.915 mb/sec, real 6.465 mb/sec - компрессия, 24.134 mb/sec - декомпрессия.
l256 для уже сжатых srep -l256 данных - Cpu 5.335 mb/sec, real 4.661 mb/sec против 27.547 mb/sec
l512 - Cpu 9.948 mb/sec, real 8.859 mb/sec при 23.844 mb/sec декомпрессии.

Так что такой подход уменьшил бы (в теории) скорость сжатия с 9 до 6 Мб/с, а с 3.8 лишь до 3.1 - зато при декомпрессии md5 считать бы не требовалось (и скорость cpu возросла бы со 150 до 400-500 Мб/c - хотя она не особо там важна, разве что для очень быстрых SSD). Но главное, тот бесконечно малый шанс на ошибку пропал бы совсем. Хотя то - временная мера, возможно и правда лучше нечто подобное проделывать не с проверкой md5 8 Мб-ного блока, а на более ранней стадии компрессии, при поиске совпадений... Но это, должно быть, куда труднее сделать. А режим замедленной компрессии (с проверкой не по md5, а побайтовым сравнением) можно вообще включать особым ключом.

С другой стороны, нечто подобное может иметь смысл лишь при интеграции srep в сам freearc в качестве препроцессора - а к тому времени и в srep может появится возможность проверять совпадения точнее. А так srep сейчас только для тестирования - так что хватило бы ключа -t в freearc'е .

Добавлено:
У меня WinXP 32-bit SP2. Пока пробовал со включённым /3G (mex5t не работает), завтра попробую с выключенным. А что ещё нужно описать?

Цитата:

архив. но подожди сегодняшнего обновления проги, попробуешь с новой dll, я там исправил выделение памяти в tta

дык чето не вижу оного обновления... куда смотреть?
как была 3.4 последней так и осталась...

CTACKo
http://forum.ru-board.com/topic.cgi?forum=5&topic=31386&start=0&limit=1&m=1#1


Цитата:

насчёт -mex5t: выяснилось что facompress.dll не грузится в xp-32

я разобрался в чём проблема, хотя пока не нашёл решения


Цитата:

я правильно понимаю, существует вероятность около 10^-40 (т.е. ~2^-128)

sha1: 160 бит, md5: 128 бит. вероятность сбоя в памяти гораздо больше. а то что ты не доверяешь md5, но при этом доверяешь crc-32, вообще наводит на грустные размышления

вообще, я с примерно теми же рассуждениями (только с упором на потребление памяти, а не сбои в sha1) собрался делать следующую версию. если скорость распаковки нас устраивает, то почему бы не делать то же самое при сжатии?

т.е. коротко говоря, я выкидывааю sha1, заменяю crc-32 на crc-64 и тем самым требования к памяти сократятся ещё вдвое. упаковка может стать медленней для больших L, но только в тех случаях, когда и распаковка - не сахар. поэтому нынешний вариант имеет смысл только при упаковке на машине с куда меньшй памятью, чем распаковывающая

Добавлено:
new version:

* fixed attempt to run 64-bit ArcShellExt dll on 32-bit OSes

Bulat_Ziganshin
Star Ocean: The Last Hope [PAL/ENG] [3-DVD9] xbox 360
изначально iso пожаты были rar Скоростной размер в скобочках
s-so1.iso 7475.5МБ - (rar 6826.3МБ)
s-so2.iso 7475.5МБ - (rar 6797.2МБ)
s-so3.iso 7475.5МБ - (rar 6854.9МБ)
итого 22426.5МБ(21.9ГБ) - (rar 20478.4МБ(~20ГБ))

по одиночке
rep:1024m
s-so1.iso - 5716.5МБ
s-so2.iso - 5146.2МБ
s-so3.iso - 5569.2МБ
в сумме = 16431.9МБ

srep
s-so1.iso - 5478.1МБ
s-so2.iso - 4950.5МБ
s-so3.iso - 5415.0МБ
в сумме = 15843.7МБ

вместе
rep:1024m
заtarенные 1+2+3 - 16432.0МБ

srep
заtarенные 1+2+3 - 12528.4МБ

Во время распаковки srep, система упала в BSOD (WinXP SP2)
0x0..0D3
rdbss.sys

тестирование проходило
1. Перезагрузка
2. Запуск bat
3. прошло две упаковки (rep, srep), при распаковке srep получил BSOD, распаковаться успело 2.9ГБ
повторный запуск распакоки srep прошёл нормально

[more=лог заtarенные..]
timer.exe Arc.exe a s-so123_rep_512.arc -mrep:1024m s-so123.tar -di -di+$#

Timer 3.01 Copyright (c) 2002-2003 Igor Pavlov 2003-07-10
FreeArc 0.52 alpha (August 23a 2009) Creating archive: s-so123_rep_512.arc using rep:1gb
Memory for compression 1280mb, decompression 1gb, cache 1mb
Started: 0.00 secs
Compressing 1 file of 23.516.088.832 bytes: 0.02 secs
Using rep:1gb
Memory for compression 1280mb, decompressi100.0%
Solid block compression results (436.063 seconds)
rep:1gb: 17.230.209.677 bytes in 436.063 seconds

Writing directory: 972.7100.0%
Found 1 directory names: 973.52 secs
Directory written: 973.5
Compressed 1 file, 23.516.088.832 => 17.230.209.677 bytes. Ratio 73.2%
Compression time: cpu 617.53 secs, real 973.59 secs. Speed 24.154 kB/s
All OK

Kernel Time = 81.062 = 00:01:21.062 = 8%
User Time = 537.718 = 00:08:57.718 = 55%
Process Time = 618.781 = 00:10:18.781 = 63%
Global Time = 974.093 = 00:16:14.093 = 100%


timer.exe srep.exe s-so123.tar s-so123_512.srep

Timer 3.01 Copyright (c) 2002-2003 Igor Pavlov 2003-07-10
1389 mb used for hash
Compression ratio: 23516088832 -> 13137073424: 55.86%. Cpu 8.262 mb/sec, real 7.618 mb/sec
Kernel Time = 72.843 = 00:01:12.843 = 2%
User Time = 2846.406 = 00:47:26.406 = 92%
Process Time = 2919.250 = 00:48:39.250 = 94%
Global Time = 3087.031 = 00:51:27.031 = 100%


timer.exe srep.exe -d s-so123_512.srep s-so123_512_d

Timer 3.01 Copyright (c) 2002-2003 Igor Pavlov 2003-07-10
Compression ratio: 23516088832 -> 13137073424: 55.86%. Cpu 171.279 mb/sec, real 26.923 mb/sec
Kernel Time = 97.484 = 00:01:37.484 = 11%
User Time = 137.328 = 00:02:17.328 = 15%
Process Time = 234.812 = 00:03:54.812 = 26%
Global Time = 873.515 = 00:14:33.515 = 100%
[/more]


Цитата:

вообще, я с примерно теми же рассуждениями (только с упором на потребление памяти, а не сбои в sha1) собрался делать следующую версию. если скорость распаковки нас устраивает, то почему бы не делать то же самое при сжатии?

что Вы имеете ввиду?
сейчас при упаковке данные по содержимому сравниваются?

Добавлено:
Ghost2004

Цитата:

23516091904 -> 13137095188
22426.693 Мб -> 12518.974 Мб

опечатка
22426.693 Мб -> 12528.51 Мб

Цитата:

сейчас при упаковке данные по содержимому сравниваются?

нет, по sha1


Цитата:

Во время распаковки srep, система упала в BSOD (WinXP SP2)
повторный запуск распакоки srep прошёл нормально

думаю, перегрузка i/o системы, пиши репорт в ms

Добавлено:

Цитата:

заtarенные 1+2+3 - 12528.4МБ

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

Bulat_Ziganshin

Цитата:

но при этом доверяешь crc-32, вообще наводит на грустные размышления

А где я такое говорил, crc32 я eщё больше не доверяю . После тестов декомпрессии я обычно устраивал побайтовое сравнение исходного и распакованного файлов в Total Commander'е с разных физических дисков;). Хотя, конечно, в контрольных суммах я особо не разбираюсь (знаю, что md5 крепче crc32 - но по чистой случайности..) .


Цитата:

вообще, я с примерно теми же рассуждениями (только с упором на потребление памяти, а не сбои в sha1) собрался делать следующую версию. если скорость распаковки нас устраивает, то почему бы не делать то же самое при сжатии?

Да, я заметил подобные планы в todo-list srep08.cpp - хотя уже в процессе написания прошлого сообщения. (Читать-то .cpp я умею, а вот с написанием - проблема, мои знания застряли на том, чему успели научить в продвинутой математической школе - т.е. о c/c++ под дос (т.к. оно было лет 10-15 назад) я кое-что знаю (и даже программы писать умел), хотя и не полностью и не системно...).


Цитата:

sha1: 160 бит, md5: 128 бит. вероятность сбоя в памяти гораздо больше.

Да, точно - о втором (сбое в памяти) я как-то не подумал . Короче с этим я конечно лоханулся по полной программе ...

egor23

Цитата:

что Вы имеете ввиду?
сейчас при упаковке данные по содержимому сравниваются?

Нет, по контрольным суммам - если я правильно понял, то по sha1. Плюс проверка md5 для каждого исходного блока на 8 Мб - так что если при распаковке выйдут другие данные, то srep08 выдаст соответствующую ошибку... но шансы на это порядка 2^-160*filesize/L (скорее действительно файл побьётся при чтении или записи, или сбой в RAM случится).

И спасибо что поймал опечатку - я тогда усталый был, и наверное что-то напутал...

Тогда переставлю сюда и результаты в сравнимом виде
1+3+2 -> rep:1gb:h27:a99 - 16429.324 Мб
1+3+2 -> srep - 12528.510 Мб

Так что с 1+2+3 разница маленькая в обоих случаях - 0.1 Мб для srep и 2.5-3 Мб для rep (тут наверное a99 их выиграли).

сорри, время нашёл