Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 15
lz4 -9 декомпрессия 2044.8 МБ/с
bounce декомпрессия ~1.3 ГБ/с
Выделенное жирненьким и измерено в другом масштабе, манипуляция цифрами, и по lz4 -9 понятно почему быстро, с учетом уго Ratio.
В остальном прекрасная статья.
Внимательно посмотрите, что при высокой скорости 2044.8 МБ/с lz4 -9 компрессии почти небыло всего 0.7% поэтому нечего расспаковывать только скопировать и все )
Раз уж зашла тема про эту строку, в вашей таблице 450 Мб -> 468,9 Мб, а коэффициент 99,3%. Что-то из этого не корректно, в совокупности с изменением размерности скорости действительно вызывает сомнения. Исходя из первой строки первоначальный файл весил 471,9 Мб (а не 450). Мне кажется просто стоит результаты бенчмарка чуть причесать, чтобы прям нельзя было за мелочи зацепиться. Это вполне логично, что заявления о том, что написан код, перфоманс, которого превосходит текущие технологии рассматривают под микроскопом и такие мелочи снижают доверие к результатам опубликованным автором.
указал в комменте что с учетом Ratio понятно почему он быстрее, и автор мог сноску, так что Я вполне внимательно посмотрел
Что прекрасного в этом миксе нейрослопа и лжи?
Идея с перетасовкой битов у массивов чисел f16/f32 очень клевая, но немного запоздала: сейчас все большую популярность набирают квантованые модели и есть шанс, что это станет повсеместным стандартом.
Например DeepSeek v4 pro хоть и имеет 1.6Т параметров, но бОльшая часть из них изначально - 4-х битные, так что занимает модель 865Гб. Nvidia вовсю продвигает NVFP4 для которого у нее аппаратное ускорение.
Я занимаюсь компиляцией LLM под разные типы задач в качестве исходных беру например Qwen3.6 27B или Gemma4 31B для сжатия нужны полные модели, как пример сжатия для задач кодинга посмотрите уже сжатые моим способом модели https://huggingface.co/infosave как раз архиватор пригодился для хранения разных видов моделей!
Кто шарит? Это просто byte shuffle и выбор оптимальной стратегии сжатии? А причем здесь космос и золотое сечение?
Скрытый текст
test.tar - 503 089 664
test-1.bnc - 263 804 231 - 00:08.35
test-1.zst - 223 158 066 - 00:02.39
test-2.bnc - 226 225 233 - 00:11.98
test-2.zst - 214 153 311 - 00:02.79
test-3.bnc - 224 360 941 - 00:15.45
test-3.zst - 207 179 976 - 00:05.04
test-4.bnc - 222 771 439 - 00:27.46
test-4.zst - 204 573 434 - 00:09.48
test-5.bnc - 221 303 182 - 00:54.62
test-5.zst - 199 963 125 - 00:08.43
test-6.bnc - 220 119 423 - 01:35.35
test-6.zst - 198 246 347 - 00:10.23
test-7.bnc - 219 385 531 - 02:56.48
test-7.zst - 197 014 432 - 00:11.95
test-8.bnc - 217 921 549 - 05:37.65
test-8.zst - 196 572 104 - 00:14.23
test-9.bnc - 217 366 242 - 09:21.93
test-9.zst - 195 202 138 - 00:15.82
Тестировать распаковку при такой "шустрой" упаковке, посчитал излишним.
А зря вчера не протестировал распаковку, эпичнее бы вышло.
ZSTD -9 справился за 1.53, а bounce...
extracting test.tar: 3.5 / 479.8 MB (0.7%) | 2.9 MB/s | ETA: 02:46 thread ‘’ (1760) panicked at src\codec.rs:2415:72: called Option::unwrap() on a None value note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
Хороший продукт, надежный как швейцарские часы. Вспомнил прикол из эпохи DOS. Тогда тоже был архиватор который умел паковать, но не всегда умел распаковывать. Правда там чистое мошенничество было. Этот кусок в 2 мб распаковывает, он совпадает с началом иходного.
Ну и бред же про физику. Как обычно, у таких "философов": выставили Сложный уровень материала. Патенты. Ну хоть не стали называть это Алгоритмом Кириченко, у вас еще не все потеряно.
Начальная идея про замену 00/01/10/11 на 0/1/01/10 - тоже бред. Код не префиксный. Его однозначно не распаковать. "01" может быть запакованным "10" или "00 01".
Если вводить какие-то хедеры или разметку, то файл раздуется еще больше изначального. Если же делать префиксный код, то будет тупо хаффмановское кодирование в лучшем случае.
Из оставшихся идей в статье есть только две:
1) Выбрать лучший алгоритм кодирования (в том числе не сжимать уже сжатые файлы). Идея старая и тривиальная.
2) Предобработка специфичного бинарного формата из float'ов. Это интересная идея, но физикой никак не навеянная, и практическая польза ее под вопросом.
Вся остальная архивация на чужих стандартных алгоритмах.
Реализация - такая себе. Код надо вылизывать и отлаживать, но не буду придираться.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архиватор рождённый из теории предельного сжатия вселенной