Wild vs Mold 벤치마킹 — 두 링커의 성능 측정 결과가 엇갈린 이유를 파헤치다
Mold가 링커 벤치마크에 Wild를 처음 포함하면서 Wild가 상당히 느린 것으로 나타났고, 이는 Wild 측이 8월 초에 공개한 결과와 정면으로 배치됩니다. Wild의 저자 David Lattimore가 두 벤치마크의 설정 차이를 하나씩 통제해가며 재현 실험을 한 결과, 출력 파일 삭제 여부·파일시스템·fork 동작 같은 측정 조건과 Mold 자체의 최근 성능 개선이 차이의 대부분을 설명했습니다.
본문
Mold가 최근 링커 벤치마크를 갱신하면서 Rust 기반 링커인 Wild를 처음 비교 대상에 포함했고, 그 결과에서 Wild가 Mold보다 상당히 느린 것으로 나타났습니다. 이는 Wild가 지난 8월 4일 릴리스에서 공개한 자체 벤치마크와 상충하는 결과였고, Wild의 저자인 David Lattimore가 왜 이런 차이가 발생하는지를 직접 분석한 글입니다.
벤치마크 환경의 차이
Mold의 벤치마크는 64코어(128스레드) Threadripper의 Ubuntu 24.04와 16개 성능 코어를 가진 Apple M1 Ultra의 Asahi Linux, 두 대의 머신에서 실행됐습니다. 반면 Wild의 최근 벤치마크는 16코어(32스레드) Ryzen 9955hx의 Ubuntu 26.04 한 대에서 실행됐습니다. 하드웨어 외에도 설정상의 중요한 차이가 두 가지 있었습니다. 첫째는 출력 파일 처리로, Wild의 벤치마크는 이전 링커 실행 결과물이 이미 존재하는 상태에서 측정하는 반면 Mold는 매 실행 사이에 출력 파일을 삭제합니다. 이 차이는 파일시스템에 따라 성능에 큰 영향을 줍니다. Wild는 벤치마크 노이즈를 줄이고 SSD 수명을 아끼려는 목적으로 historically tmpfs 위에서 측정해왔는데, 저자는 대부분의 사용자가 tmpfs에서 빌드하지 않는다는 점에서 이 선택이 실수였다고 돌아봅니다. Mold는 더 합리적인 선택인 ext4를 사용했으며, 앞으로는 둘을 섞어 측정할 예정이라고 합니다. 둘째는 --no-fork 플래그로, Mold의 벤치마크는 종료 비용을 줄이기 위한 기본 동작인 시작 시 fork를 비활성화하고 측정했지만, Wild는 시간 측정 시 기본값을 그대로 두고 메모리 측정 시에만 --no-fork를 사용했습니다.
M1 환경에서의 재현 실험
저자는 먼저 Mold의 Apple M1 결과와 유사한 조건을 16코어 머신에서 재현했습니다. 2026-08-28 기준으로 두 링커를 모두 release 빌드하고, 출력 파일을 ext4에 두고 매 실행마다 삭제하며 --no-fork를 전달했습니다. 그 결과 Wild/Mold 비율이 blender-debug 1.2x, godot-debug 1.2x, blender-release 0.9x, clang-release 1.0x로 나타나, Mold가 발표한 1.2x·1.3x·0.8x·1.0x와 거의 일치했습니다. CPU 아키텍처와 캐시 크기, RAM이 다른 점을 고려하면 기대할 수 있는 수준만큼 근접한 결과라고 저자는 평가합니다.
설정 조합별 비교
차이의 원인을 분리하기 위해 clang-release 벤치마크를 다섯 가지 설정으로 측정했습니다. Mold 방식인 ext4+삭제+no-fork에서는 1.0x로 동률이었지만, 출력 파일을 지우지 않으면(ext4) 0.7x로 Wild가 빨라졌고, tmpfs+삭제+no-fork 0.8x, tmpfs+유지+no-fork 0.7x를 거쳐 Wild가 historically 사용하던 tmpfs+유지+fork 조합에서는 0.6x까지 내려갔습니다. 즉 이 버전의 Wild는 fork가 허용되고 출력 파일이 tmpfs에 이미 존재하는, Mold 벤치마크와 정반대의 조건에서 가장 좋은 성능을 냅니다. 저자는 그 이유가 tmpfs가 아닌 파일시스템에서 새 파일을 빠르게 생성하고 쓰기 위한 OS 특화 최적화가 Wild에 없기 때문이라고 설명합니다. Mold 저자의 논문 'mold: A Massively Parallel Linker'에 소개된 기법으로, fallocate로 파일 공간을 미리 할당하고 hugepage로 파일을 매핑하는 두 가지 변경이 이미 Wild에 적용되어 다음 릴리스에 포함될 예정입니다.
Mold 자체가 빨라졌다
설정 차이만으로는 설명이 안 되는 격차가 남아 있어, 저자는 지난 1년여간 두 링커의 각 릴리스를 모두 다시 벤치마크했습니다. Wild 0.6.0이 argument file과 일반 커맨드라인 인자의 혼용을 지원하지 않아 자체 빌드한 clang을 사용했고, 빈 sframe에서의 실패를 우회하기 위해 mold에는 --discard-section=.sframe을 전달했습니다. 그 결과 Mold가 최근 상당히 빨라진 것이 확인됐는데, 특히 Wild의 8월 4일 벤치마크가 Mold 2.42.0과 2.42.1 릴리스 이전에 측정됐고 주요 성능 향상이 바로 그 릴리스들에서 발생했다는 점이 핵심입니다.
재현하지 못한 Threadripper 결과
다만 64코어 Threadripper에서의 큰 격차는 재현하지 못했습니다. 저자의 16코어·92GiB RAM 머신으로는 64코어·384GiB RAM 환경을 흉내 낼 수 없기 때문입니다. 저자는 여분의 차이가 Wild가 128스레드로 동작하는 반면 Mold는 32스레드로 동작한 데서 비롯됐을 가능성을 추측으로 제시합니다. 자신의 32스레드 머신에서는 24에서 32스레드로 늘려도 미미하게나마 계속 빨라졌기 때문에 스레드 상한을 두지 않았다고 밝히며, Threadripper를 가진 사람이 스레드 수를 바꿔가며 벤치마크해주면 알려달라고 요청합니다.
원문: David Lattimore's blog / 번역·요약: Trawling