Roc로 만든 DEFLATE, C의 libdeflate에 2.6% 차이까지 따라붙다
How close can pure functional programming get to C?
Lean 4로 작성된 lean-zip이 Rust의 miniz_oxide를 앞서는 성능을 보였다는 소식에서 출발해, 저자는 함수형 언어 Roc로 작성된 roc-deflate를 C의 최강자 libdeflate와 직접 비교한다. Silesia 코퍼스로 144개 벤치마크를 돌린 결과, 아직 0.1.0도 나오지 않은 언어의 패키지가 M1 MacBook Pro에서 중앙값 2.6%, Ryzen 3900X에서 8.9% 느린 수준까지 도달했다. 순수 함수형 프로그래밍이 C 성능에 얼마나 근접할 수 있는지를 보여주는 실측 기록이다.
roc-deflate는 이 144개 벤치마크에서 평균적으로 libdeflate보다 느리게 돌았고, 중앙값 기준으로 Ryzen 3900X에서는 8.9%, M1 MacBook Pro에서는 2.6% 느렸다.
HN 토론
81- jandrewrogers
최적화 가능성의 차이 중 상당 부분은 C/C++가 상당히 극단적인 복사 생략(copy elision)을 허용한다는 점에 있습니다. 이는 메모리 대역폭이 주요 성능 병목인 경우가 많기 때문에 중요합니다.
C/C++ 코드는 아주 쉽게 멀리 떨어진 어떤 상태 비트에 접근해서 직접 변경할 수 있습니다. 접근 방식이나 패턴이 아무리 추해도 컴파일러는 거의 문제 삼지 않습니다. 불변 조건이 유지되는지 확인하는 것은 프로그래머의 몫이고, 컴파일러가 항상 그걸 꿰뚫어 볼 수는 없습니다. 하지만 이런 생략된 복사들이 쌓이게 되는데, 보통 유지보수성과 안전성 비용을 치르게 됩니다.
이는 함수형 언어들이 이론상 대규모 병렬성에 좋은 특성을 지녔음에도 실제 슈퍼컴퓨팅에서는 평범한 편인 이유와도 관련이 있습니다.
- VorpalWay
> lean-zip이 모든 압축 레벨에서 miniz_oxide를 이긴다
miniz_oxide는 의도적으로 단순한 구현입니다. 더 새로운 zlib-rs[1]와 비교하는 것이 더 공정할 텐데, 이는 심지어 zlib-ng(C에서 가장 빠른 구현)[2]도 이깁니다.
[1]: https://lib.rs/crates/zlib-rs
[2]: https://trifectatech.org/blog/zlib-rs-is-faster-than-c/
- gobdovan
이런 최적화를 라이브러리로 노출해서 프로그래머가 최적화 패스를 요청하고 컴파일러가 사전 조건을 검사하도록 하는 건 고려해 보셨나요?
JS가 얼마나 빨라질 수 있는지에 대한 글을 준비 중인데 같은 걸 발견해서 여쭤봅니다. V8을 충분히 괴롭히면 사실상 어떤 코드든 최적화된 C 코드의 10% 수준까지 끌어올릴 수 있더군요(SIMD는 예외인데, V8에 명백한 경우에도 SIMD로 최적화하지 않는 버그가 있는 것 같습니다). 라이브러리로 추출해서 더 능률적으로 할 수 있겠다고 생각했지만, 수동 변환이 얼마나 일반화될지는 확실치 않습니다.
그리고 roc-deflate 작업하면서 그 모델에 맞는 반복적인 변환을 발견하셨나요, 아니면 대부분의 개선이 압축에 특화된 것이었나요?
- johnny22
"X번 다운로드된 크레이트를 이긴다"고 말하는 건 그저 인기가 많다는 것 외에는 아무 말도 하지 않는 겁니다. 거기에 조금 더 자세한 내용이 있으면 좋겠네요.
- pmkary
이런 종류의 해커 뉴스 글과 댓글을 좋아합니다. 거북이보다 수십억 배 느린 언어에 타입을 수십억 번 추가하는 것도 아니고, 타입 반대하는 지구평평론자들이 백신 맞으라고 하면 기겁하는 그런 글 말고, 극한의 성능과 극한의 기능을 가진 극한의 언어들에 관한 글이요.