How close can pure FP get to C?
순수 함수형 프로그래밍은 C에 얼마나 가까워질 수 있을까?
Roc으로 작성한 DEFLATE 압축기 roc-deflate를 C 라이브러리 libdeflate와 비교한 결과, 144개 벤치마크의 중앙값에서 Ryzen 9 3900X는 8.9%, M1 MacBook Pro는 2.6% 느렸습니다. 글쓴이는 메모리 안전성과 순수성 같은 보장을 유지하면서 C에 근접한 성능을 얻은 사례라고 설명하고, Roc의 최적화 방법을 공유합니다.
- 주제
에디터 노트
이번 수치는 Roc의 성능 가능성을 보여주지만, 144개 테스트가 한 압축기와 두 시스템에 한정되고 스트리밍 API도 제외됐습니다. 글쓴이 역시 다른 Roc 코드베이스로 일반화하기 이르다고 선을 긋습니다. 따라서 한 자릿수 성능 차이는 이 사례에서 확인한 결과로 보는 편이 정확합니다. 글쓴이는 안전성 보장과 성능 비용을 함께 설명하고, 컴파일러가 검사와 참조 계수 작업을 제거할 수 있도록 코드를 구성한 방법도 공개합니다. Reddit에서는 Weissman 점수를 묻는 댓글이 있지만 답변이나 점수는 제공되지 않았습니다. 해당 질문만으로 이 벤치마크의 압축 품질을 판단할 수는 없습니다.
AI 요약
함수형 언어 Roc으로 작성한 DEFLATE 압축기 roc-deflate가 C 라이브러리 libdeflate에 어느 정도 가까운 성능을 내는지 비교합니다. 글쓴이는 Silesia 압축 벤치마크에서 두 구현이 같은 결과를 내는지 확인하고, 비스트리밍 API를 대상으로 성능을 측정했습니다.
벤치마크 결과
144개 테스트에서 roc-deflate는 libdeflate보다 중앙값 기준 Ryzen 9 3900X에서 8.9%, M1 MacBook Pro에서 2.6% 느렸습니다. 가장 느린 입력에서는 18% 뒤졌지만, 일부 입력에서는 18% 넘게 앞섰습니다. 글쓴이는 구현 방식과 입력에 따라 차이가 달라진 결과라며, 평균적으로 roc-deflate를 선택해 속도 향상을 기대해서는 안 된다고 설명합니다. 이번 비교는 단일 압축기와 두 시스템에 한정되며 스트리밍 API는 다루지 않습니다.
성능과 언어의 보장
글쓴이는 Roc이 C보다 높은 성능 한계를 갖지는 않는다고 봅니다. Roc은 메모리 안전성, 자동 참조 계수 관리, 경계 검사, 순수 함수의 부수 효과 제한을 언어 차원에서 보장하며, C처럼 검사를 끄거나 임의의 FFI를 호출하는 기능도 제공하지 않는다고 설명합니다. 글쓴이의 주장은 이런 제약이 성능 비용을 만들지만, 이번 구현에서는 그 비용을 한 자릿수 수준의 차이로 좁혔다는 것입니다. Roc 패키지에는 빌드 스크립트도 없다고 덧붙입니다. 순수 함수는 같은 입력에 같은 결과를 내도록 설계됐으며, 대상 시스템이 달라도 결과가 같아야 한다는 이식성도 장점으로 제시합니다.
Roc에서 적용한 최적화
roc-deflate의 성능 개선에는 여러 언어에서 쓰이는 일반적인 최적화와 Roc에 특화된 방법이 함께 쓰였습니다. 값이 불필요하게 공유되지 않도록 해 opportunistic mutation, 즉 값이 고유할 때 내부에서 제자리 변경하는 최적화가 가능하게 합니다. 반복문 앞에서 컬렉션 길이를 검사하면 반복문 안의 경계 검사를 안전하게 없앨 여지가 생깁니다. 컴파일 시점에 만들 수 있는 조회 테이블은 길이가 고정되므로 런타임 경계 검사도 줄입니다. 정수 오버플로 검사가 필요 없는 연산에는 plus 대신 plus_wrap을 고려할 수 있습니다. 컴파일러가 오버플로가 없음을 증명하면 두 연산이 같은 명령으로 최적화될 수도 있습니다.
Reddit 반응
- @bosyluke — 순수 함수형 언어 Roc도 뛰어난 성능을 낼 수 있습니다. 순수 Roc으로 libdeflate를 구현한 이 글도 읽어보면 좋겠습니다. (링크를 제출했습니다.)
- @Smallpaul — 정말 멋집니다. 다음 릴리스도 잘 되길 바랍니다.
- @bosyluke — 감사합니다.
- @GoAwayLurkin — Weissman 점수는 얼마인가요?
원문: rtfeldman.com / 번역·요약: Trawling