bzip3 벤치마크, zstd 창 크기·메모리 조건을 둘러싼 해커뉴스 논쟁

zstd 기본 설정보다 4배 작다는 벤치마크는 인상적이네.

zstd 레벨 16 기본 딕셔너리 크기와 비교한 거잖아. 제대로 압축하려면 레벨 19 이상과 더 큰 윈도 크기를 써야 하고, 메모리도 bzip3은 12,178MB인데 zstd는 687MB라 공정한 비교인지 모르겠음.

1년 넘게 여러 파일로 시험했는데 bzip3은 영화처럼 압축하기 어려운 파일에서 아주 좋을 때가 있었음. 하지만 다른 데이터에서는 zstd보다 나빠서 데이터 의존성이 너무 컸고, 미리 어느 쪽이 유리한지 알 수 없더라.

이 벤치마크는 bzip3의 -b 256과 512 외에는 설정을 거의 비교하지 않고 압축 시간과 메모리도 안 재네. 병렬인지 단일 스레드인지도 불명확해서 수치를 판단하기 어려움.

xz랑 같은 계열인가 했는데, LZMA2를 떠올린 거고 bzip3은 관련 없는 알고리즘임.

예전 도구 작성자가 bzip3의 Burrows-Wheeler 변환을 설명한 글이 있었고, 당시엔 대형 텍스트 압축 벤치마크에 없었는데 지금은 mattmahoney.net 목록에 올라가 있음.

최근 릴리스는 1년 전이고 마지막 커밋은 2개월 전인데 빌드도 실패 중이네. 'bzip2보다 강하다'는 표현도 무엇을 뜻하는지 모호하고, 병렬 해제 수치를 bzip2와 비교한 건 불공정해 보임.

2025년 벤치마크 설명에는 공정성을 위해 단일 스레드 모드로 측정했다고 적혀 있음.

병렬 해제가 모든 bzip3 아카이브에서 되는지, 생성할 때 별도 플래그가 필요한지가 관건임. pbzip2는 pbzip2로 만든 아카이브만 병렬 해제하고, 일반 bzip2 파일은 단일 스레드로 돌아가더라.

bzip3 블록 크기는 512MB인데 zstd 윈도는 기본값으로 둔 비교라서 체리피킹에 가까움. Perl 소스 버전을 이어 붙인 코퍼스는 긴 반복이 많아 BWT 압축기에 특히 유리하고, zstd에 --long=29를 주니 출력이 196,405,076바이트로 bzip3보다 2배 넘게 작았음.

두 zstd 실행의 메모리 사용량은 얼마였는지 궁금함. 원 벤치마크는 zstd 687MB, bzip3은 12,178MB와 18,301MB라고 적었는데 차이가 너무 큼.

zstd 고레벨 기본 윈도는 실제로 8MB임. 긴 윈도를 쓰면 해제할 때 --long=windowLog나 --memory를 따로 줘야 하는 점은 불편하긴 함.

zstd에 더 큰 윈도와 장거리 모드를 넣은 비교가 필요함. 저 설정이면 윈도가 개별 버전 tar 파일보다 작아서 유용한 중복을 못 잡을 수도 있음.

낮은 확률로 발생하는 특수 사례 때문에 버그를 완전히 배제할 수 없다는 설명은 형식 검증과 AI 기반 테스트의 좋은 대상 같음.

JSONL 아카이브에서 lzma가 gzip과 bzip2보다 훨씬 작았지만 DuckDB 같은 도구 지원이 부족해서 결국 gzip을 썼음. DuckDB는 zstd도 지원하니 지금은 zstd가 실용적인 선택 같음.