bzip3: BZip2의 더 강력한 후계자, 텍스트 압축률 대폭 향상
bzip3는 BZip2의 정신적 후계자로, 더 높은 압축률과 더 나은 성능을 제공하는 압축 도구입니다. order-0 컨텍스트 혼합 엔트로피 코더, 접미사 배열 기반의 빠른 Burrows-Wheeler 변환, LZ77 기반 문자열 매칭과 PPM 스타일 컨텍스트 모델링을 결합한 RLE+LZP 패스를 특징으로 합니다. 텍스트나 코드 압축에 특히 뛰어나며, Perl 소스 코드 전체를 압축하는 벤치마크에서 xz, bzip2, Zstandard보다 훨씬 작은 결과물을 생성했습니다. lrzip과 함께 사용하면 더욱 극적인 압축률을 보여줍니다.
bzip3는 텍스트나 코드 압축에 탁월합니다.
HN 토론
122- altairprime
이전:
"안녕하세요, 도구 작성자입니다." bzip3에서 사용하는 Burrows-Wheeler 변환에 대한 유용한 설명: https://news.ycombinator.com/item?id=42902407
"bzip3는 아직 대형 텍스트 압축 벤치마크에 등재되지 않았습니다" 지금은 등재되었습니다: https://mattmahoney.net/dc/text.html
(2년 전, 댓글 176개) https://news.ycombinator.com/item?id=42899713
(4년 전, 댓글 104개) https://news.ycombinator.com/item?id=31324439
- 8organicbits
최근에 압축된 .jsonl 파일(JSON lines 형식)을 처리하고 있었습니다. lzma가 gzip이나 bzip2보다 훨씬 나은 압축률을 제공한다는 것을 발견했습니다. 이는 보관 비용 측면에서 도움이 되지만, 소프트웨어 지원이 부족하여 작업하기 어렵습니다. 저는 gzip을 투명하게 지원하는 duckdb 처리를 합니다. bzip2용 확장이 있지만 lzma나 bzip3용은 없습니다.
결국 제가 사용하는 소프트웨어에서 가장 잘 지원되고 앞으로 채택할 소프트웨어에서도 지원될 가능성이 높기 때문에 gzip을 사용하게 되었습니다. 하지만 시도한 옵션 중 압축 결과가 가장 나빴습니다. 이 bzip3 수치를 보니 확실히 FOMO가 생기네요...
- ot
벤치마크는 벚꽃 고르기처럼 보일 정도로 정직하지 않습니다. bzip3의 블록 크기는 512MB로 설정되어 있지만 zstd의 윈도우 크기는 기본값(높은 수준에서 8MB라고 생각합니다)으로 남겨져 있습니다. 따라서 모든 Perl 소스 코드 버전을 연결한 이 코퍼스에서는 윈도우가 너무 작아서 동일한 파일을 모두 보고 일치시킬 수 없습니다.
또한 매우 긴 반복으로 구성된 코퍼스는 BWT 기반 압축기에 가장 적합한 시나리오입니다.
zstd의 윈도우 크기를 bzip3와 일치시키면 결과가 극적으로 달라집니다:
% gzcat *.gz | time zstd -T8 -16 | wc -c # 기준
2819113884
zstd -T8 -16 2054.50s user 3.47s system 783% cpu 4:22.80 total
% gzcat *.gz | time zstd -T8 -16 --long=29 | wc -c
196405076
zstd -T8 -16 --long=29 1083.06s user 2.41s system 783% cpu 2:18.55 total
기준보다 거의 15배 작고 bzip3보다 2배 이상 작으며 CPU 시간도 절반으로 줄어듭니다(긴 일치 항목이 더 일찍 발견되므로 할 일이 줄어듭니다).
(기준 숫자는 작성자가 사용한 정확한 Perl 버전 세트가 없어 약간 다릅니다)
또한 윈도우 크기를 덜 중요하게 만드는 lrzip을 사용한 벤치마크에서는 zstd가 비교조차 되지 않습니다.
- JdeBP
흥미로운 의도하지 않은 벤치마크는 https://github.com/iczelia/bzip3/releases 에 가서 bzip3가 자체 릴리스 아카이브를 어느 정도 압축하는지 확인하는 것입니다. 또한 https://github.com/iczelia/bzip3/blob/master/.github/workflo... 에 가서 다른 압축기에 대해 어떤 옵션이 선택되었는지 확인하십시오.
- CodesInChaos
이것은 더 큰 윈도우와 long range 모드를 사용한 zstd 벤치마크를 포함해야 한다고 생각합니다. 그들이 사용한 윈도우가 개별 버전 tar 파일보다 작아서 유용한 압축을 방해할 것이라고 놀라지 않을 것입니다.
- amelius
> 그러나 알고리즘의 복잡성, 특히 코드에 매우 낮지만 0이 아닌 확률로 발생하는 다양한 특수 사례로 인해 프로그램에 버그가 남아 있을 가능성을 배제할 수 없습니다.
형식화 + AI를 위한 좋은 테스트 케이스처럼 들리나요?
- whatever1
압축 알고리즘은 LLM으로 상당한 개선이 가능하다고 생각합니다. 폐쇄 루프 평가에서 가질 수 있는 이상적인 후보 문제이며 에이전트가 시도하게 할 수 있습니다.
- charcircuit
bzip 작성자가 만들지 않은 것에 그런 이름을 사용하는 것은 불쾌합니다. 어떤 이유로 오픈 소스 개발자들은 고유한 이름을 만들기보다 상표권을 침해할 수 있는 이름을 사용하는 것을 좋아합니다.