Ares Preview 2.0 (Pre-Alpha)

И еще одна программа выходит снова после большого перерыва! Хотя в этот раз перерыв все же не два года, а только год и 3 или 4 месяца. Встречайте - полностью переработанный FileCompressor под кодовым названием Ares Preview 2.0 (в приложенном архиве). Я начал сразу с номера 2.0, так как это, по сути, продолжение существующей программы. Теперь добавились новые методы сжатия, включая мои авторские модификации - "для слов" и SHET, которые сжимают Властелина Колец всего на 19% слабее 7z! Причем другие архиваторы уже не сжимают файлы, сжатые Ares, в отличие от старых, что является аргументом в пользу правдивости этого размера. Также появилась возможность гибко управлять применяемыми инструментами с помощью специальных флажков и переключателя PSB/ARIC. К сожалению, пока нельзя отключить Лемпель-Зив, или наоборот, отключить все, кроме него, но если я не брошу программу, то это будет исправлено. Розовым выделены инструменты, распаковка которых вылетает. Также теперь ни один файл не будет сжиматься два часа (представьте себе!). Если размер файла приемлемый для Ares (например, Властелин Колец - 4 МБ), он сожмет быстро, если неприемлемый (например, 650 МБ) - сдастся сразу. Тесты показали, что на среднем компьютере (я считаю свой компьютер более-менее средним) с базовыми настройками Властелин Колец сжимается 18 секунд (!!!), с экстремальными - 8 минут 11 секунд. Хотя есть одна проблема: почти половину этого времени ни одна полоса загрузки не двигается ни на пиксел, так что создается иллюзия, что программа зависла. Очень надеюсь, что программа улучшилась.

Вложения

Ares Preview 2.0.rar (73.6 Кб, 9 просмотров)

0

0

Сообщение от locm Сначала нужно исправить все имеющиеся ошибки в коде, а потом добавлять новые, иначе потом не разгребете!

Вот эта же работа и направлена на исправление имеющихся ошибок.

0

Etyuhibosecyu, у вас есть выбор размера блока, и последние опции отмечены как "в разработке", однако выбрать я их могу и сжатие вроде проходит. Так и должно быть? И вообще, что такое размер блока и почему там так много опций?

Сообщение от Etyuhibosecyu Вышеупомянутый файл сжимается и распаковывается, проверен

К сожалению не у меня. Пробовал и первый, и третий столбцы, и вместе.

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

0

Etyuhibosecyu, И все таки мне не совсем понятно, почему нельзя протестировать самому на хотя бы на нескольких десятках файлов? Почему это делают все, кто угодно, но не автор программы?
Сколько файлов было сжато перед выкладыванием альфа версии на форум?

0

Pilarentes, очевидно же - достаточно сжать одну небольшую книжку.

0

Pilarentes, ТС тестирует свою программу исключительно на томике "Властелина Колец". Никаких других файлов у него нет. Я думаю, что нужно всем форумом скинуться ему на архив с разными файлами. И ещё нужно его как-то научить отладчиком пользоваться, чтобы не выкладывал приложения, которые просто падают с исключениями типа NRE.

Добавлено через 36 секунд

Сообщение от Kastaneda System.OutOfMemoryException System.NullReferenceException System.StackOverflowException

Первое и третье - дичь, но согласуется с показаниями профилировщика.

Добавлено через 4 минуты
Etyuhibosecyu, соберите своё приложение в x64. Возможно, что OutOfMemoryException станет появляться позже) Но ни в коем случае не пытайтесь исправить код и навести порядок!

0

Сообщение от MrOnlineCoder у вас есть выбор размера блока, и последние опции отмечены как "в разработке", однако выбрать я их могу и сжатие вроде проходит. Так и должно быть? И вообще, что такое размер блока и почему там так много опций?

Размер блока - это для псевдобайт. Сколько байт составляет один непрерывный блок псевдобайт. Там должен быть всего один набор опций, и то, что большой файл на 50000 байтах будет сжимать много лет, уже тоже неправда, я изменил формат. И то, что в разработке - автоматически подставляется ближайший аналог с таким же размером блока.

Сообщение от MrOnlineCoder К сожалению не у меня.

Вы точно скачали последний билд?

Сообщение от MrOnlineCoder Пробовал и первый, и третий столбцы, и вместе.

Вы хотели написать - первый и второй? Третий будто бы ясно горит розовым во второй строке (не считая строки выбора всего столбца).

Сообщение от MrOnlineCoder И да, если я упакую файл одной конфигурацией, а потом попробую распаковать другой конфигурацией чекбоксов, то будет ошибка?

На распаковку конфигурация флажков никак не влияет.

Сообщение от Pilarentes Сколько файлов было сжато перед выкладыванием альфа версии на форум?

Три - Властелин Колец, лог какой-то программы (27.4 КБ) и сохраненная страница с этого форума (230 КБ).

Сообщение от Usaga соберите своё приложение в x64.

Я, будто бы, выставлял x64. Но потом оказалось, что только в Debug. Потом будто бы и в Release. Сейчас, кажется, в Release горит x64.

0

Сообщение от Etyuhibosecyu Я, будто бы, выставлял x64. Но потом оказалось, что только в Debug. Потом будто бы и в Release. Сейчас, кажется, в Release горит x64.

На самом деле это стёб. Проблемы с потреблением памяти решаются исправлением кода, а не увеличение доступной приложению памяти. Потребление более двух гигов при обработки десятка метров - это неадекватное потребление ресурсов.

0

Сообщение от Usaga Потребление более двух гигов при обработки десятка метров - это неадекватное потребление ресурсов.

А знаете ли вы, что, например, тот же 7z при максимальных настройках потребляет больше 72 ГБ при обработке даже 20 байт?

0

Сообщение от Etyuhibosecyu Три - Властелин Колец, лог какой-то программы (27.4 КБ) и сохраненная страница с этого форума (230 КБ).

Вообще, приложение нужно натравить на пару тысяч файлов (хотя бы), затем распаковать все и проверить результат.

0

Etyuhibosecyu, я знаю, что никакие настройки в 7z я никогда не трогал. И, в отличие от вашего творения, он всё равно работает в десятки и сотни раз быстрее, при этом не вылетает и может разархивировать то, что сам сжал.

Не надо ровняться. Более того: если 7z память и потребляет, то под словари и буферы. А ваше приложение просто мусор генерирует. Это не тоже самое. Вообще не тоже самое.

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

Добавлено через 4 минуты
Ваше приложение не занимает много памяти, а именно создаёт огромный трафик: память постоянно выделяется и высвобождается. Это признак создания огромного количества мусора. А 7z может выделить память под словарь и спокойно с ней работать пока не завершит задачу, т.е. память используется под структуру данных целенаправленно.

0

Сообщение от Usaga А ваше приложение просто мусор генерирует.

А что такое, с вашей точки зрения, "мусор"? Списки? Так я просвещу вас, для чего они. Это списки псевдобайт. Один список - один символ / одно слово. Если слово частое, в этом списке два псевдобайта (включая пробел), если очень редкое - четыре. Так понятно?

0

Сообщение от Etyuhibosecyu А что такое, с вашей точки зрения, "мусор"? Списки? Так я просвещу вас, для чего они. Это списки псевдобайт. Один список - один символ / одно слово. Если слово частое, в этом списке два псевдобайта (включая пробел), если очень редкое - четыре. Так понятно?

Мусор - это объект ставший не нужным. Ваше приложение создаёт огромное количество короткоживущих объектов, которые перестают быть нужными и превращаются в мусор почти сразу после их создания. Сборка такого мусора занимает время процессора.

Получается, что ваше приложение большую часть времени не сжатием занимается, а выделением и высвобождением памяти. И пока вы ЭТО не исправите, никакие авторские BWT и псевдобайты, никакая многопоточность ваш код не ускорят. Многопоточность даже хуже сделает, ведь мусор в несколько потоков будет создаваться, а на десктопной машине сборщик мусора работает в один поток.

Ваша реализация очень дерьмовая. Именно ЭТОТ момент нужно исправлять. Не сжатие идёт медленно, а процессор отвлекается на другие задачи.

0

Сообщение от Usaga Ваше приложение создаёт огромное количество короткоживущих объектов, которые перестают быть нужными и превращаются в мусор почти сразу после их создания.

Не такое уже и "огромное". Классический Хаффман, например, ни одного такого, который одновременно является короткоживущим (превращается в мусор при выходе из блока) и объектом (а не byte, int и т. д.). Хаффман для слов - шесть, из которых три являются "огромными". Лемпель-Зив - три, из которых один "огромный" (точнее, он небольшой, но имеет миллионы копий). Считал только что. Это "огромное" количество?

0

Сообщение от Etyuhibosecyu Не такое уже и "огромное"

2.3Гб на 12Мб сжимаемых данных "не огромное" ? Это конская дичь, настолько "огромное".

Сообщение от Etyuhibosecyu Считал только что.

Мне всё равно, чего вы там насчитали для себя. Ваше приложение тормозит и вылетает. И профилировщик показал почему. Вы игнорируете его показания?

0

Сообщение от Pilarentes мне не совсем понятно, почему нельзя протестировать самому на хотя бы на нескольких десятках файлов?

Зачем самому если другие сделают?

Сообщение от Usaga И ещё нужно его как-то научить отладчиком пользоваться, чтобы не выкладывал приложения, которые просто падают с исключениями типа NRE.

Думаете получится? Я уже писал что из ТС не выйдет программист. Если он за это время так и не научился правильно писать программы, то уже не научится. То что у него в универе были хорошие оценки (с его слов) как видим ни чего не значит.

Сообщение от Usaga Etyuhibosecyu, соберите своё приложение в x64.

Приложение уже x64.

Сообщение от Etyuhibosecyu А что такое, с вашей точки зрения, "мусор"?

Миллиарды объектов там где хватило бы одного! Каждое создание объекта (даже неявное) это выделение памяти. Не создавайте новых объектов если можно использовать те что уже есть.
Хорошо изучите все нюансы используемого ЯП. Это позволит оптимально писать проги.

Сообщение от Etyuhibosecyu Это списки псевдобайт.

Вы каждый байт храните в отдельном элементе списка? Неудивительно для для 4 МБ сжимаемого файла нужно 4 ГБ оперативки!
В этом плане неуправляемый код имеет преимущество - массив может быть непрерывной последовательностью байт в памяти, а не списком указателей на объекты разбросанные по все оперативке и требующие гораздо больше памяти чем хранится данных.

Сообщение от Usaga Многопоточность даже хуже сделает, ведь мусор в несколько потоков будет создаваться, а на десктопной машине сборщик мусора работает в один поток.

Да, и во время очистки мусора все потоки останавливаются. Чем больше мусора, тем дольше простаивают - тем больше время упаковки/распаковки файла.
Это типа защитный механизм программы чтобы неконтролируемо не росло число объектов!

0

Сообщение от locm Думаете получится?

Нет, не получится. Прогресс нулевой...

0

Сообщение от Etyuhibosecyu 7z при максимальных настройках потребляет больше 72 ГБ при обработке даже 20 байт?

Че? У меня на компе с 1гб памяти справился. А у вас 72гб оперативы установлено?

0

0

Сообщение от locm То что у него в универе были хорошие оценки (с его слов)

Вот скриншот. Надеюсь, не зацепил реальную фамилию и другие конфиденциальные данные. Есть и тройки, но по профильным предметам хорошие оценки.

Сообщение от locm Миллиарды объектов там где хватило бы одного!

Что миллионы - правда, что миллиарды - нет.

Сообщение от locm Вы каждый байт храните в отдельном элементе списка?

Иногда даже в трех. И 4.3 бита полезной информации (в среднем столько несет буква русского языка по формуле Шеннона) занимают 192 бита. Но хорошо, хоть не 384, так как я переделал псевдобайт из класса в структуру.

Сообщение от Pilarentes Че? У меня на компе с 1гб памяти справился. А у вас 72гб оперативы установлено?

Написано же - при максимальных настройках. У меня - не установлено. Так пишет сам 7z, а значит, на самом деле еще больше.
Usaga, а вы уверены, что имеете право плевать на то, что я не поленился, подсчитал, затратил время, память и ресурсы клавиатуры, чтобы написать об этом? Вы, наверное, считаете себя каким-то гением, а меня - годным только "двор подмести"?

Миниатюры

 

0