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

Цитата:

вот такое например:

наверно как в WinUHA параноидальное (пока не отключишь) -
Большой размер словаря выбран, будет использоваться много памяти!! Продолжить?

Bulat_Ziganshin

Цитата:

вот такое например:
Memory for compression 3gb, decompression 2gb, cache 1mb

Трудно сказать.

На самом деле это плохая ситуация. В первую очередь с точки зрения юзабилити и надежности. Должны быть стандартные установки, которые _гарантированно_ будут работать даже на слабых машинах.

Если бы FA был коммерческим приложением, где надежность - требование №1, был бы смысл сделать дефолтными именно "асимметричные" режимы m1x - m9x, причем с использованием на 32-бит системах не более 1 Gb памяти при _любых_ обстоятельствах (даже если в наличии 3 Gb). Тогда была бы гарантия, что даже на стареньких компах с 128 мегабайтами памяти (а при достаточном количестве виртуалки и на еще более слабых) архив _всегда_ распакуется.

Зато при использовании "симметричных" режимов с объемом памяти более 1 Gb писать что-то вроде: "Дорогой архиваторный маньяк ! Пожалуйста учти, что твои знакомые с компьютерами с меньшим объемом доступной памяти рискуют обломаться с распаковкой этого архива. За содержание слов, которыми они тебя за это назовут, автор FA никакой ответственности не несет."

Примерно так

Bulat_Ziganshin

Цитата:

http://www.haskell.org/bz/arc2.arc

Arc.exe a a -mx -di -di+$ wilsoft200.tar
[more=упаковывает нормально..]
[no]
ARC 0.50 (8.01) Creating archive: a.arc using exe+rep:1gb+delta+tempfile+lzma:12
8mb:max:bt4:128, $obj => rep:1gb+delta+tempfile+lzma:128mb:max:bt4:128, $text =>
dict:128mb:80%:l8192:m400:s100+lzp:128mb:92%:225:h24:d1mb+ppmd:24:1536mb, $wav
=> tta, $bmp => mm+grzip:8mb:m1:l:a, $incompressible => rep:8mb:128+tor:2:64kb
Memory for compression 2gb, decompression 2gb, cache 1mb
Started: 0.00 secs
Found 1 files, 0 archives: 0.02 secs
Sorted 1 files: 0.02 secs
Joined filelists: 0.02 secs
$text wilsoft200.tar ["$text","$text","$text"]
Compressing 1 file of 215.283.200 bytes: 0.02 secs
Using dict:128mb:80%:l8192:m400:s100+lzp:128mb:92%:225:h24:d1mb+ppmd:24:1536mb

Memory for compression 2gb, decompressi 97.5%
Solid block compression results (12.859 seconds)
dict:128mb:80%:l8192:m400:s100: 31.731.006 bytes in 9.938 seconds
lzp:128mb:92%:225:h24:d1mb: 8.556.797 bytes in 0.797 seconds
ppmd:24:1536mb: 657.427 bytes in 2.125 seconds

Writing directory: 14.69 secs
Found 1 directory names: 14.69 secs
Directory written: 14.6
Compressed 1 file, 215.283.200 => 657.427 bytes. Ratio 0.3%
Compression time 12.86 secs, speed 16.741 kb/s. Total 14.72 secs
All OK[/no]
[/more]

Arc-gui.exe a a -mx -di -di+$ wilsoft200.tar
вываливается

Microsoft Visual C++ Runtime Library

Runtime Error!

Program: D:\Downloads\Reget Downloads\arc_8.01.08\Arc-gui.exe


This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Цитата:

Arc-gui.exe a a -mx -di -di+$ wilsoft200.tar

-di... пока в gui-версии не поддерживается

Добавлено:
да, кстати, забыл написать, что в этой версии и автодетект улучшен. впрочем, он всё ещё не идеален и не отключабелен

Добавлено:

Цитата:

di... пока в gui-версии не поддерживается

хотя нет, протестировал - работает. выходит, опять проблемы с памятью? -m7 -то пашет?

Benchmark

Цитата:

был бы смысл сделать дефолтными именно "асимметричные" режимы m1x - m9x

дефолтный пресест только один, тот который по-умолчания (вроде m2), а всё остальное пользователь делает своими руками, и то что он не думает головой - это его проблемы, вообщем на ошибках учатся.

Если Вы подразумеваете чтобы в GUI был выбор только m1x - m9x, это не катит, в пример 7-zip выше приводил, убраны словари 128\96Мб, скорее всего из-за проблем с памятью. Но так можно до ограничиваться до ..не могу..

Добавлено:
Bulat_Ziganshin

Цитата:

хотя нет, протестировал - работает. выходит, опять проблемы с памятью? -m7 -то пашет?

Ды проблемы с памятью. Нужно определение доступной виртуальной памяти, иначе под каждую машину не подобрать настройки.
m7 работает.

Цитата:

что конкретно происходит - загрузка процессора, трешинг винта? ОС? попробуй -m=lzma:128mb - что получается? сколько ОЗУ свободно, работает ли 7-zip в аналогичном режиме (7z a a -md27)?

Загрузка процессора - минимальная, 5-10% (правда, процессор двуядерный). На винт ничего не пишет и ничего не читает (после создания tempfile'а) - в диспетчере задач смотрел. Насчёт свободного ОЗУ сейчас точно не скажу, но выделение памяти (и виртуальной памяти) для процесса arc после создания tempfile'а вдруг становится лишь 20-50 Мб (тогда как для rep:1gb оно было в районе 1300 Мб)... Короче, arc застревает на 10% (т.е. после rep'а) и судя по всему ничего не делает. Далее, насчёт 7-zip'а не знаю, но при сжатии fa аж -mlzma:159mb проходит без проблем (разве что с тормозами, если что-либо ещё запущено, но это не серьёзная проблема, к тому же оно лечится установкой лишнего 1 Гб - просто сейчас у меня 3 Гб работают в лучшем случае как DDR333 (а то и DDR314) вместо DDR400, а для архиваторов как раз скорсть памяти критична - т.е. для всех режимов требующих менее 1.5 Гб конфигурация с 2 Гб наверняка должна оказаться быстрее). Да, и кстати говоря, максимально возможный объём виртуальной (да я думаю и не только виртуальной, могу поставить 3 Гб если надо проверить) памяти, используемый arc'ом оказывается порядка 1830 mb (даже положенные WinXP32 2 Гб не удаётся до конца использовать) - если больше, то либо просто вылетает, либо выдаёт "thread blocked indefinitly" или ещё что-то в этом роде.

Ghost2004

Цитата:

используемый arc'ом оказывается порядка 1830 mb

Это у Вас система не сильно загажена, на свеже установленной 1900 с копеньками будет.

Добавлено:
Bulat_Ziganshin

Цитата:

для lzma словарь 128Мб предел?

забыл проверить на финальной версии, 128 не предел.

Добавлено:
Bulat_Ziganshin
Arc-gui.exe

предел работы:

ppmd:1201m - (Вирт. память - 1 245 584кб)
lzp:600m - (Вирт. память - 1 245 444кб)
rep:945m - (Вирт. память - 1 245 804кб)
lzma:128m - (Вирт. память - 1 392 596кб)

Вирт. память - По диспетчеру задач.

lzma выше 128m, rep выше 945m - не работает, запускается, но через некоторое время закрывается окно.

ppmd, lzp выше m - вываливаются с ошибкой.
для lzp:
Arc-gui.exe - Ошибка приложения

Инструкция по адресу "0x00517e78" обратилась к памяти по адресу "0x00000000". Память не может быть "written".

А проблема не старая случаем?

Цитата:

Это у Вас система не сильно загажена, на свеже установленной 1900 с копеньками будет.

Ясно, то есть это в 32-битной системе особо не лечится... Кстати, а 64-битная тут может помочь? Хотя бы полностью 2 Гб на 32-битную программу использовать...

А вообще я тут ещё одну ошибку из этой же серии обнаружил - если сжимать с настройкой
-m=rep:1gb:h25+delta+lzma:80mb, при этом не выставив размер солид-блока на максимум, то первый солид блок на 1.5 Гб сожмётся нормально (т.е. как rep:1gb:h25+delta+tempfile+lzma:80mb), а вот следующие 400 Мб начнут сжиматься по принципу rep:401mb:h25+delta+lzma:80mb без tempfile, и в результате выдадут ошибку "thread blocked indefinitly". Хотя если с самого начала сжимать rep:401mb:h25+delta+lzma:80mb, то всё и без tempfile'а проходит нормально.

Такое впечатление будто что-то не так с освобождением/запросом памяти при использовании tempfile (а может rep).

Ghost2004

Цитата:

Хотя бы полностью 2 Гб на 32-битную программу использовать...

тоже самое будет, примерно.

Добавлено:
Ghost2004
кстати что за данные сжимаете?

Цитата:

кстати что за данные сжимаете?

Образы дисков приставочной игры Lunar для PS1 - вернее сказать, сейчас развлекаюсь с тестированием - извлёк с дисков все файлы и звуковые треки (кстати, по размеру получилось даже чуть больше, чем если жать ecm - вообще сжатый freearc'ом c помощью ecm и есть основной файл для тестирований и поиска оптимально цепочки алгоритмов) и смотрю насколько лучше становится от сортировки (кстати для 7-zip'а оно и правда лучше - 883 вместо 979 Мб (после ecm)), но вообще самое интересное начнётся когда соберусь сжимать Star Ocean 3, который мало того что на двух ДВД-дисках с большим количеством совпадений, так ещё у меня в трёх вариантах - PAL, NTSC и NTSC-undub (т.е. с японским звуком и английским текстом) - вся эта радость ужатая rar'ом занимает аж 18 Гб... Тут уж пожелаешь чтобы можно было запустить rep:4gb, да ещё пару раз для верности . А так скорее всего придётся эту штуку разбить на куски rar'ом там или Total Commander'ом и подобрать подходящую последовательность и размер... Впрочем, это самый тяжёлый случай - но вообще у меня полно игр для PS2 на двух ДВД, и там наверняка полно совпадений между дисками - ведь чаще всего на втором диске можно побывать на всех местах из первого, да и плюс данные игрового движка копируются...

Да, и всё же скорее дело не в tempfile, а rep - потому как последовательность -m=lzma:256mb:fastest+lzma:256mb:fastest спокойно прошла. При этом потребовав виртуальной памяти где-то 1720-1730 тысяч kб... А даже rep:96mb+tempfile+lzma:256mb:fastest застревает после создания tempfile'а... Вот rep:64mb+tempfile+lzma:256mb:fastest - проходит (правда, памяти требуется уже почти 1750 тысяч kb) но подозреваю что она и без tempfile'а пройдёт.

Ghost2004

Цитата:

А так скорее всего придётся эту штуку разбить на куски rar'ом там или Total Commander'ом и подобрать подходящую последовательность и размер...

А зачем разбивать?

Добавлено:
Bulat_Ziganshin
А возможно добавить возможность наподобие *.tar.gz
т.е. сначала файлы загоняются в один файл без сжатия, а после пакаются, даже наверно на лету прокатит?

вот, кстати, народ сделал поный архив: http://www.megaupload.com/?d=57AI2RJR
если кто выложит прямую ссылку на скачивание - будет тоже неплохо

пожелания ес-но принимаются, чтоб не повторяться вот мой нынешний спсиок to-do на данный момент:
ИНТЕРНЕТ!
архивы с русскими именами
закрытие диалога прогресса не должно приводить к закрытию программы
ускорить переходы - обновлять данные в модели вместо её переназначения
ставить курсор на каталог/архив при выходе наверх
очищать диалог прогресса в начале работы команды (сейчас он показывает старые данные )
диалог распаковки
пароль/keyfile
выбор выходного каталога
фрейм вокруг опций перезаписи
"Extract 5 file(s) from a.arc" если выбраны файлы
каталоги в архиве
время/дата в locale format
использовать массивы вместо списков файлов для нормального времени работы
комбобокс над списком для навигации по структуре диска/архива
формировать команду внизу диалогов распаковки/сжатия/модификации и выполнять её (так чтобы пользователь мог отредактировать)
сортировка нажатием на заголовок столбца
тестирование/распаковка всех выбранных архивов (+галочка "добавить имя архива к пути распаковки")
команды Run, View, Add, Modify, Info; d&d support
использовать уже открытый архив для ускорения выполнения операций view/test/extract
рекурсивное удаление для каталогов (упереть removeDirectoryRecursive)

Цитата:

А возможно добавить возможность наподобие *.tar.gz

походу тупить стал, пойду спать...

добавил http://www.haskell.org/bz/arc-linux-gui.bz2


Цитата:

А возможно добавить возможность наподобие *.tar.gz
т.е. сначала файлы загоняются в один файл без сжатия, а после пакаются, даже наверно на лету прокатит?

а сейчас что - не так делается? ты вроде как солид-сжатие переоткрыл? или имеешь в виду one-file stdin-to-stdout compression? формат .arc с ним не совместим, придётся что-то добавлять

насчёт виртуальной памяти и проблем у тех, кто имеет 2+ gb - разумееется, разбираться буду. просто я сейчас занялся вплотную этим gui..

кстати, у тебя какая ОС там где 2.5 гб? /3g используешь?

Цитата:

насчёт виртуальной памяти и проблем у тех, кто имеет 2+ gb - разумееется, разбираться буду. просто я сейчас занялся вплотную этим gui..

Ясно, придётся подождать...


Цитата:

кстати, у тебя какая ОС там где 2.5 гб? /3g используешь?

WinXP 32-bit . Вот думаю, поможет ли 64-битная WinXP... А то ставить и настраивать её - утомительное занятие...

З.Ы. Да, кстати таки и без tempfile'а прошло rep:64mb+lzma:256mb:fastest (а уже 96 mb - нет). И наоборот, lzma:256mb:fastest+tempfile+rep:900mb:32:h26:a99 тоже прокатило без проблем .

кстати, раз уж разговор вертится вокруг rep с большими словарями. по умолчанию в нём используется скажем 1гб для самих данных и вчетверо меньше - для индекса. хранить историю данных приходится только потому, что простенький 4-байтный хеш, который вычисляется от этих 512 байт - ненадёжен в смысле коллизий. теперь представьте себе, что мы храним вместо него 16-байтный cryptographically strong hash - типа md5. тогда историю можно вычеркнуть нафиг. более того, то что хеш-таблица занимает четверть от объёма индексированных данных - это необязательно. если хранить такой хеш для каждого 256-байтного блока данных, то это гарантирует нам нахождение всех матчей длины от 511 (поскольку любой такой матч включает как минимум один полный 256-байтный блок, начинающийся с 256-байтной границы). т.е. для поиска строк длины 511+ c N-гб историей достаточно памяти в N/16 гб

проблемы возникнут только при распаковке если при упаковке старые данные нам и не нужны - достаточно иметь 100% уверенность в их совпадении, то при распаковке нам как никак надо их копировать со старого места если считать, что мы все эти данные будем хранить на диске вместо ОЗУ, то копирование каждой строки потребует операции чтения с диска, накладные расходы на которую практически равны disk seek time - т.е. 10 мс для винта и 1 мс для очень хорошей флешки

представим себе, что мы хотим обеспечить скорость распаковки скажем 1 мб/с. это означает, что каждые 10 мс мы должны распаковывать как минимум 10 кб, что в свою очередь гарантировано только если у нас rep кодирует только совпадения длины 10кб+

скажем, если остановиться на кодировании строк длины 4кб+, то для сжатия потребуется N/128 гб памяти (т.е. твои 18 гиг можно прошерстить, используя всего 160 мег озу) и скорость распаковки будет ограничена 400 кб/с. вот только винт жалко

Ghost, попробуй для интереса - как меняется сжатие твоих данных при переходе от rep:512 (по умолчанию) к rep:4096? с дальнейшей обработкой lzma и без оной. понятно, это лишь прикидка, поскольку реально rep сейчас окучивать большие истанции не умеет может, мне это дело добавить на быструю руку, без возможности распаковки...

Цитата:

если кто выложит прямую ссылку на скачивание - будет тоже неплохо

Здесь

ну вот - сам нашёл наиболее серьёзную ошибку. freearc-gui сбоит после того, как выполнено несколько операций. так что перезпаускайте его между операицями


Цитата:

WinXP 32-bit .

/3g используешь? т.е. опцию загрузки, которая позволяет использовать больше 2 гиг отдельной программе


Добавлено:

Цитата:

Здесь

прмая ссылка - это http://www.haskell.org/bz/arc-linux-gui.bz2 к примеру

Добавлено:
Егор, напомни плиз - для тебя 0.40 release и pre-3 одинаковы в плане проблем с памятью или есть разница?

Bulat_Ziganshin

Цитата:

а сейчас что - не так делается? ты вроде как солид-сжатие переоткрыл? или имеешь в виду one-file stdin-to-stdout compression? формат .arc с ним не совместим, придётся что-то добавлять

что-то на подобии tar хотелось... но в моём случае не катит:
есть тестовый набор - папка wilsoft 1.84Гб (1 985 002 358)(57931 файлов html)
имена файлов присутствуют по тексту в файлах html.
папка wilsoft жмётся примерно до 6Мб, список файлов (каталога архива) имеет размер 450кб, что примерно 8-10% от размера архива, вот и захотелось от него избавиться, но в ближайшем рассмотрении больше половины это контрольные суммы - примерно 280кб, остаётся 170кб примерно 3.5% от размера архива, что не так привлекательно как 10%.

Цитата:

кстати, у тебя какая ОС там где 2.5 гб? /3g используешь?

WinXP Pro SP2 rus 32bit
/3g - тоже ничего не менялось с этим ключом, да и вроде ничего не обещала Microsoft для WinXP Pro для режима пользователя.

Добавлено:

Цитата:

Егор, напомни плиз - для тебя 0.40 release и pre-3 одинаковы в плане проблем с памятью или есть разница?

Вроде проблем нет у 0.40 release.
Если вопрос про /LARGEADDRESSAWARE - то не работало на Win64.

Nikolai2004

Цитата:

может кто-нибудь сформулировать в чём секрет успеха winrar?

Да какой там успех, на западе как юзали winzip да pkzip, так и юзают. =)

Цитата:

предел работы:

а вот эта версия - http://www.haskell.org/bz/arc040-no-http.7z ?

насчёт использования двух rep - tempfile никогда не рассчитывался на более чем олнократное применение в одной цепочке. я сейчас на него взглянул - имхо проблемы здесь. даже -m=tempfile+tempfile будет вероятно сбоить

Bulat_Ziganshin

Цитата:

а вот эта версия - http://www.haskell.org/bz/arc040-no-http.7z ?

не совсем понятно...
предел работы: - если по тексту выше, то там Arc-gui.exe 0.50 косячит.

arc040-no-http.7z

пределы:
ppmd:1562m
lzp:780m
rep:1024m (rep:1049m)
lzma:145m



Добавлено:
4Гб памяти. Реально?
http://forums.overclockers.ru/viewtopic.php?t=87680

Цитата:

В общем, по моим последним тестам - последние сведения
Ключ /3GB сработал на WinXP SP2 на 3х Гигабайтах оперативной памяти. При этом оному приложению я смог выделить 3071 Мегабайт (т.е. ~3Гб) памяти !!!
Таким образом ключ /3GB эффективен/имеет смысл на машинах с объёмом памяти строго больше 2х гигабайт!
Т.е. если вы счастливый обледатель памяти в 3 и более гигабайт, то ставьте это ключ и приложения увидят до 3х гигабайт виртуальной памяти*.

*Для этого каждое приложение (*.ехе) должно иметь ключ LARGEADDRESSAWARE в своём заголовке (в поле Сharacteristics если быть точным). Собственно что и сделано для игры сталкер.
Ключ можно выставить утилитами из пакета Visual Studio От MS или другими утилитами, работающими с исполняемыми файлами.

Добавлено:
Bulat_Ziganshin

Цитата:

Егор, а у тебя вообще другие программы больше чем 2 гига могут использовать?

оказувается могут, про Photoshop 10 совсем забыл:
WinXP SP2 Pro rus 32bit
2.5Гб+2Гб(файл подкачки, на всяк случай)
boot.ini - /3GB /USERVA=3000

Если верить Photoshop:
Доступная память RAM: 2172 МБ

В диспетчере задач - Вирт.память - 2 280 636кб (2 227Мб)

Добавлено:
WinXP SP2 Pro rus 32bit
2.5Гб
boot.ini - /3GB /USERVA=2400

Если верить Photoshop:
Доступная память RAM: 2076 МБ

В диспетчере задач - Вирт.память - 2 134 064кб (2 084Мб)

Добавлено:
WinXP SP2 Pro rus 32bit
2.5Гб
boot.ini - /3GB /USERVA=3000

Если верить Photoshop:
Доступная память RAM: 2172 МБ

В диспетчере задач - Вирт.память - 2 279 768кб (2 226Мб)

PS: Bulat_Ziganshin ждём от Вас FreeArc с /LARGEADDRESSAWARE

Цитата:

Bulat_Ziganshin ждём от Вас FreeArc с /LARGEADDRESSAWARE

так была уже, и pre-4 и release. осталось только попробовать no-http версию ( http://www.haskell.org/bz/arc040-no-http.7z )с /LARGEADDRESSAWARE скрестить

кстати, ты сам не можешь эту тулзу микрософтовскую найти и попробовать?

Цитата:

вот, кстати, народ сделал поный архив: http://www.megaupload.com/?d=57AI2RJR

Открывается и сразу закрывается.

Цитата:

ткрывается и сразу закрывается.

"в настоящее время все ресурсы загрузки, выделенные для вашей страны (Russian Federation) уже используются"
я же говорюте - отзеркальте сами. неужто ни у кого нет сервера под боком чтобы пару закачек выдержал?

Bulat_Ziganshin

Цитата:

кстати, ты сам не можешь эту тулзу микрософтовскую найти и попробовать?

http://forum.ixbt.com/topic.cgi?id=25:19500
ссылка в шапке есть edit-bin.7z 25Мб, сейчас мне столько не скачать.


Цитата:

Здесь

Если это было зеркало http://www.megaupload.com/?d=57AI2RJR
то там FreeArcGUI.7z, то что на офф.сайте - содержимое arc.arc+arc2.arc

Всё таки оглавление (каталог архива) вначале архива нужен, а то тянуть с обменников неизвестно что достало.


Добавлено:
есть ещё editbin.exe в masm32
http://website.assemblercode.com/masm32/m32v9r.zip 3.5Мб
пробывал на: release, no-http - не катит, то ли из-за того что старый editbin.exe 29.03.02, то ли ещё что...

ещё здесь есть комплект
http://live.cnews.ru/forum/index.php?showtopic=23688&st=20
Large_Memory_Enabler.zip 347кб

Думаю всё таки что-то не до делано во FreeArc.

Добавлено:
4Гб памяти. Реально?
http://forums.overclockers.ru/viewtopic.php?t=87680

Цитата:

Free RAM Tester & Speed
http://rapidshare.com/files/33079877/RAM.rar.html 1кб
Первая показывае общее количество свободной физической памяти, которое реально может использовать приложение. (Т.е. Если стоит клю /3GB для виртуального простарнства и физической памяти больше чем 2 Гб то программа сможет использовать вплоть до 3х гигабайт памяти, так же как и сделает сталкер.)
Вторая находит самый большой непрерывный кусок вирт. пространства внутри 3х Гигабайтного (если /3GB) или 2х гигабайтного пространства свободной памяти и тестирует скорость записи в это самы большой кусок.

Добавлено:
А нет катит...

2.5Гб+2Гб(файл подкачки)
FreeArc-0.40 final + Large_Memory_Enabler(то что оказалось под рукой)
EDITBIN.EXE /LARGEADDRESSAWARE Arc.exe

(WinXP Pro SP2 32bit)
boot.ini /3GB /USERVA=3000
RAM Speed Test.exe 1659Мб
Available Physical Memory.exe 2274Мб
ppmd:1562m
lzp:951m
rep:1562m (но начиная с 1025m расход памяти не 1.25*словарь, потом выравнивается с кагого момента не смотрел)
lzma:145m

(WinXP Pro SP2 64bit)
RAM Speed Test.exe 2046Мб
Available Physical Memory.exe 2201Мб
ppmd:2047m
lzp:1647m (дальше упираемся в другое ограничение в 3.4Гб или типа того)
rep:2047m (но начиная с 1025m расход памяти не 1.25*словарь, потом выравнивается с кагого момента не смотрел)
lzma:223m

Цитата:

http://live.cnews.ru/forum/index.php?showtopic=23688&st=20

ну так примени "editbin /LARGEADDRESSAWARE Arc.exe" к no-http версии и посмотри как он после этого будет работать (под xp/3g или вистой)

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

Добавлено:

Цитата:

FreeArc-0.40 final

эта версия использует wininet, он ограничивает кол-во используемой памяти. проэкспериментируй с no-http версией. но в целом похоже работает, будем дальше ращзбираться

да, ты проверь реальное сжатие, хотя бы с 2.1gb используемой памяти. скажем, ppmd:32:2100m или rep:2000m:h128m (rep использует хеш размером четверть от объёма окна, округлённого вверх до ближайшей степени двойки. поэтому его расход памяти реко вырастает после окна 512m, 1024m и т.д.) на большом файле - посмотри по task man что вся выделенная память действительно была использована

Bulat_Ziganshin

Цитата:

эта версия использует wininet, он ограничивает кол-во используемой памяти. проэкспериментируй с no-http версией. но в целом похоже работает, будем дальше ращзбираться

это уже вечером, сейчас уже я не в "фокусе".

Цитата:

да, ты проверь реальное сжатие, хотя бы с 2.1gb используемой памяти. скажем, ppmd:32:2100m или rep:2000m:h128m

пределы выше указал для Win64\Win32

нужно чтобы ещё кто-то потестил у кого памяти больше, а также чтобы посмотрел что показывают:
RAM Speed Test.exe
Available Physical Memory.exe

Ghost2004
По способствуете изысканиям с 3Гб памяти?