Открытый замер на признанных мировых корпусах (Silesia, enwik8, Canterbury) против стандартных архиваторов. Меньше коэффициент = лучше.
Честная рамка
На опубликованных корпусах Silesia, enwik8 и Canterbury Cubrim v0.3.2 (замер 2026-07-24) занимает первое место по совокупному коэффициенту сжатия без потерь среди 10 протестированных архиваторов общего назначения — и платит за это скоростью и памятью: он сжимает на 0.023 МиБ/с там, где самый быстрый архиватор здесь выдаёт 19.8, и занимает до 18.0 ГиБ памяти там, где gzip обходится 2 МиБ. Выигрывает он тоже не каждый файл: Brotli лидирует на xargs.1, а xz и Brotli — на nci. Тупики и измеренные проигрыши показываем как есть.
агрегат в целом:cubrim 0.1890065868409507 · лидер cubrim 0.1890
Общий рейтинг архиваторов
Места по совокупному коэффициенту на всех корпусах (меньше — лучше). Под каждым именем — уровень сжатия, на котором он запускался.
#1
cubrimcompetitive
0.1890
#2
ppmd7z -m0=PPMd
0.2286
#3
xz-9e
0.2344
#4
7z-m0=LZMA2 -mx9
0.2355
#5
brotli-q 11
0.2408
#6
zstd--ultra -22
0.2490
#7
rara -m5
0.2573
#8
bzip2-9
0.2671
#9
gzip-9
0.3330
#10
lz4-12
0.3822
cubrim
Время и пиковая память
Последовательные замеры из проверяемого журнала. Время — сумма по всему world-корпусу, throughput взвешен по размеру, RSS — максимальный измеренный пик процесса на одном файле. Медленные или требовательные к памяти результаты Cubrim остаются видимыми.
запуск
meta35-public-v032-timing-20260727T0000Z
хост
arcana-devs
происхождение релиза
v0.3.2 · dfb195ef089db738e51153ad4532fdd583f247bf
выборка
3 замера + 1 прогрев
Sequential full-world benchmark; one warmup plus median of three measured samples; GNU time wall clock and peak RSS; every decompression byte-compared.
gzip:
no explicit command-line thread flag; tool default retained
bzip2:
no explicit command-line thread flag; tool default retained
xz:
no explicit command-line thread flag; tool default retained
zstd:
no explicit command-line thread flag; tool default retained
brotli:
no explicit command-line thread flag; tool default retained
lz4:
no explicit command-line thread flag; tool default retained
ppmd:
no explicit command-line thread flag; tool default retained
7z:
no explicit command-line thread flag; tool default retained
rar:
no explicit command-line thread flag; tool default retained
архиватор
коэффициент
сжатие, всего
распаковка, всего
скорость сжатия
скорость распаковки
пик RSS, сжатие
пик RSS, распаковка
cubrim
0.1890
13281.555 s
3227.822 s
0.023 MiB/s
0.093 MiB/s
18439.4 MiB
12561.5 MiB
gzip
0.3330
22.430 s
1.798 s
13.383 MiB/s
166.953 MiB/s
2.0 MiB
1.8 MiB
bzip2
0.2671
22.020 s
8.720 s
13.632 MiB/s
34.424 MiB/s
8.5 MiB
4.9 MiB
xz
0.2344
187.650 s
4.179 s
1.600 MiB/s
71.832 MiB/s
673.8 MiB
66.3 MiB
zstd
0.2490
199.312 s
0.627 s
1.506 MiB/s
478.733 MiB/s
771.5 MiB
98.9 MiB
brotli
0.2408
670.137 s
1.021 s
0.448 MiB/s
294.057 MiB/s
238.1 MiB
19.9 MiB
lz4
0.3822
29.748 s
0.404 s
10.090 MiB/s
742.106 MiB/s
9.1 MiB
9.0 MiB
ppmd
0.2286
32.381 s
35.516 s
9.270 MiB/s
8.452 MiB/s
263.9 MiB
263.3 MiB
7z
0.2355
104.809 s
3.600 s
2.864 MiB/s
83.375 MiB/s
682.5 MiB
125.5 MiB
rar
0.2573
15.152 s
1.167 s
19.810 MiB/s
257.120 MiB/s
584.5 MiB
44.3 MiB
Три рабочие точки
Один кодек, три настройки, измеренные на одном корпусе в одной кампании.
Что можно запустить сегодня
Эти три настройки измерены на сборке разработки 3a13f48. Их нет ни в одном опубликованном релизе, поэтому версия, доступная для загрузки, вообще не принимает такой флаг. Этот раздел сообщает результаты измерений, а не возможность, которой уже можно пользоваться.
Из-за этого ни один Cubrim, доступный сегодня для загрузки, не откроет архив, записанный с настройкой: web.
Почему этим числам можно верить
Пересобранная из исходников на другом железе (dev-ai), настройка max в точности воспроизвела опубликованный коэффициент — каждую цифру числа двойной точности, а не значение, которое округляется так же. Две другие точки измерены в том же прогоне, тем же методом, против тех же конкурентов.
0.1890065868409507
max
лучший коэффициент
Опубликованная конфигурация. Самый маленький результат из всего, что здесь измерено, и самый большой расход памяти на его открытие.
коэффициент · max
0.189007
Против поля
На 17.32% меньше на выходе, чем у ppmd — сильнейшего из остальных архиваторов в этом замере. Место #1.
Пик памяти при распаковке
12.266 ГиБ
Пик памяти при сжатии
18 600 МиБ
Скорость
0.023 MiB/s
Обратный проход
24 из 24 файлов распакованы обратно и побайтово сверены с оригиналом.
Архивы открываются любым декодером Cubrim, в том числе более старым.
balanced
измерена, зависит от данных
Название обещает компромисс, и корпус наконец назвал его цену. На 10 файлах из 24 вывод побайтово совпадает с max — там она не стоит ничего, — а на самом большом из них, enwik8, кодирует всё равно в 2,48× быстрее, и на этом файле она просто лучше. Все +0,47% приходятся на остальные 14, которые платят от +0,06% до +3,9% за ускорение кодирования в 1,2–3,1×. Памяти экономит почти нисколько и декодирование не ускоряет.
коэффициент · balanced
0.189891
(+0.47% к max)
Против поля
На 16.93% меньше на выходе, чем у ppmd — сильнейшего из остальных архиваторов в этом замере. Место #1.
Пик памяти при распаковке
12.077 ГиБ
(в 1.0× меньше, чем у max)
Пик памяти при сжатии
18 090 МиБ
Скорость
0.038 MiB/s
Совпадение с max
10 из 24 файлов побайтово, по хешу архива.
Обратный проход
24 из 24 файлов распакованы обратно и побайтово сверены с оригиналом.
Архивы открываются любым декодером Cubrim, в том числе более старым.
web
web
коэффициент · web
0.206627
(+9.32% к max)
Против поля
На 9.61% меньше на выходе, чем у ppmd — сильнейшего из остальных архиваторов в этом замере. Место #1.
Пик памяти при распаковке
0.216 ГиБ
(в 56.8× меньше, чем у max)
Пик памяти при сжатии
9 349 МиБ
Скорость
0.040 MiB/s
Совпадение с max
6 из 24 файлов побайтово, по хешу архива.
Обратный проход
24 из 24 файлов распакованы обратно и побайтово сверены с оригиналом.
Архив, записанный с настройкой web, не откроется более старым декодером.
Совместимость работает только в одну сторону. Настройка записывает значение, которого не понимают декодеры, выпущенные до неё. Такой декодер не прочитает архив неправильно и не запишет частичный файл — он останавливается с ошибкой и не создаёт ничего:
Error: DecodeError: MODE_CM2: coded stream exhausted before orig_len bytes decoded
Границы этих измерений
Все три точки: одни и те же 24 файлов (314 749 364 байт) из Silesia, enwik8 и Canterbury, на одной машине (dev-ai), в одной кампании, замер от 2026-07-30. Размеры сжатого — точные значения в байтах; каждый архив распакован обратно и сверен с исходником.
Более ранние оценки для этих настроек считались по фрагменту в 2 МБ одного файла и ошибались в обе стороны — однажды в пять раз. Ни одно число из того фрагмента здесь не приведено, и ни одно из этих чисел нельзя с ним сравнивать.
пик памяти измерен как /usr/bin/time -v Maximum resident set size
Агрегат по корпусу
корпус
ранг cubrim
cubrim
gzip
bzip2
xz
zstd
brotli
lz4
ppmd
7z
rar
canterbury
#1/10
0.1285
0.2600
0.1931
0.1754
0.1854
0.1746
0.3328
0.1837
0.1761
0.1818
enwik8
#1/10
0.1955
0.3645
0.2901
0.2483
0.2533
0.2574
0.4199
0.2240
0.2486
0.2735
silesia
#1/10
0.1867
0.3191
0.2572
0.2286
0.2478
0.2339
0.3651
0.2313
0.2301
0.2507
По файлам, сгруппировано по типу данных
Зелёным подсвечен лучший архиватор в строке, красным — худший; #ранг показывает место Cubrim среди всех архиваторов (1 = лучший).
Ранг типа считается по суммарному размеру архива (Σ сжатых байт ÷ Σ исходных байт по файлам типа) — тот же size-weighted метод, что у Silesia/lzbench, а не среднее рангов по файлам. Архиватор может выиграть тип, не будучи первым ни на одном файле, если его суммарный вывод наименьший.
Ранг типа считается по суммарному размеру архива (Σ сжатых байт ÷ Σ исходных байт по файлам типа) — тот же size-weighted метод, что у Silesia/lzbench, а не среднее рангов по файлам. Архиватор может выиграть тип, не будучи первым ни на одном файле, если его суммарный вывод наименьший.
Ранг типа считается по суммарному размеру архива (Σ сжатых байт ÷ Σ исходных байт по файлам типа) — тот же size-weighted метод, что у Silesia/lzbench, а не среднее рангов по файлам. Архиватор может выиграть тип, не будучи первым ни на одном файле, если его суммарный вывод наименьший.
Ранг типа считается по суммарному размеру архива (Σ сжатых байт ÷ Σ исходных байт по файлам типа) — тот же size-weighted метод, что у Silesia/lzbench, а не среднее рангов по файлам. Архиватор может выиграть тип, не будучи первым ни на одном файле, если его суммарный вывод наименьший.
Ранг типа считается по суммарному размеру архива (Σ сжатых байт ÷ Σ исходных байт по файлам типа) — тот же size-weighted метод, что у Silesia/lzbench, а не среднее рангов по файлам. Архиватор может выиграть тип, не будучи первым ни на одном файле, если его суммарный вывод наименьший.
Ранг типа считается по суммарному размеру архива (Σ сжатых байт ÷ Σ исходных байт по файлам типа) — тот же size-weighted метод, что у Silesia/lzbench, а не среднее рангов по файлам. Архиватор может выиграть тип, не будучи первым ни на одном файле, если его суммарный вывод наименьший.
файл
ранг cubrim
cubrim
gzip
bzip2
xz
zstd
brotli
lz4
ppmd
7z
rar
ptt5
#1/10
0.0574
0.1021
0.0970
0.0777
0.0846
0.0798
0.1289
0.0958
0.0822
0.0960
mr
#1/10
0.2078
0.3685
0.2448
0.2760
0.3115
0.2831
0.4204
0.2308
0.2756
0.2784
x-ray
#1/10
0.4292
0.7125
0.4781
0.5300
0.6084
0.5526
0.8473
0.4545
0.5286
0.4912
коэффициент = сжатый / исходный (меньше — лучше); для cubrim проверена побайтовая распаковка. · 7z -m0=LZMA2 -mx9 · xz -9e · lz4 -12 · rar a -m5 · gzip -9 · ppmd 7z -m0=PPMd · zstd --ultra -22 · bzip2 -9 · brotli -q 11 · cubrim v0.3.2 published release binary sha256 b6c3cd251f7148c1895f5b85d30d06df8252a70afbd649e269f673a19e2a5768; tag v0.3.2 = commit 09ef2bbd00c359c5485a0ef4c6fd59f464382270, whose only difference from dfb195ef089db738e51153ad4532fdd583f247bf is the version bump, so both produce byte-identical output; full24 RT cmp=0; exactly five verified cell corrections
Самые слабые классы — ровно там, где начинаются следующие раунды исследования, как колоночный field-split H-29 родился из разрыва на телеметрии-CSV. Отсортировано по отдаче.
Текст: strong-CM validated, первое место
TextDONE
Пол размера MODE_CM2 понижен 256КБ→2КБ: под-гейтовые входы получают сильный бэкенд. asyoulik.txt -27.72%, alice29.txt -28.95%, оба RT cmp=0 и оба переходят на rank 1, обгоняя ppmd. Ноль регрессии (competitive-min), заморозка v1 не тронута.
Двоичные данные: competitive record-CM/CM2, первое место
Binary / numericDONE
RECORDCM per-offset SSE (5-й APM keyed by offset*8+bitpos, competed min(plain,+SSE), флаг в свободном бите width) как режим MODE_RECORDCM: sao -0.76%, RT cmp=0, ноль регрессии, все 6 типов #1.
Исполняемые файлы: strong-CM validated, первое место
ExecutablesDONE
BCJ-фильтр, скомпонованный с бэкендом MODE_CM2 (MODE_BCJ нестит MODE_CM2, arch-gated, competitive-min): ooffice -11.46%, RT cmp=0, ноль регрессии, все 6 типов #1. Композиция была структурно недостижима из-за recursion guard в encode_bcj.