성능이 중요하다면 musl을 사용하지 마세요
Don't use musl if you care about performance
JVM과 Python에 익숙한 저자가 Rust 프로젝트에서 musl libc를 채택했다가 성능 저하를 발견하고 측정한 결과를 공유합니다. musl의 기본 할당자는 심각하게 느리며, mimalloc으로 교체해도 glibc 대비 26% 느립니다. 또한 할당자 외에도 memcpy, memcmp 등 메모리 루틴이 느려서 일부 작업은 할당과 무관하게 성능이 저하됩니다. 저자는 작은 프로젝트에서는 musl을 유지하되 mimalloc을 추가하고, 성능에 민감한 Bifrost에서는 musl을 제거한다고 밝힙니다.
musl의 할당자는 정말 나쁩니다. 심각할 정도로요.
HN 토론
59- matherial
알고리즘이 할당자(allocator)가 병목이 될 정도로 작은 할당을 많이 한다면, 이미 잘못하고 있는 것입니다. 할당자는 다양한 사용 사례를 수용하고, 단편화를 피하며, 이상적으로는 다양한 보안 검사를 구현해야 하기 때문에 필연적으로 많은 오버헤드가 따릅니다. 할당 집약적인 작업을 하고 있다면, 아마도 동일한 구조를 많이 할당하고 해제하고 있을 것이므로, 연속된 메모리를 확보하여 작업별로 직접 관리하는 것이 더 나을 것입니다.
하지만 현실은 거의 아무도 성능에 신경 쓰지 않는다는 것입니다. 계산이 전문성과 노동보다 저렴하기 때문입니다. 적어도 단기적으로는 그렇습니다. 모든 것이 점점 더 비대해지고 느려지고 있으며, 우리는 CPU 코어, 기가바이트, 기가헤르츠를 추가함으로써 이를 보완할 뿐입니다.
- marssaxman
사람들은 정말로 다양한 관점을 가지고 있군요. 26% 느린 것은 저에게 "끔찍하다"고 들리지 않습니다. 오히려 musl이 제공하는 편의를 위해 기꺼이 지불할 만한 합리적인 대가처럼 들립니다. 만약 musl의 할당자가 2.6배 느리다면, 저는 그것을 "별로 좋지 않다"고 말할 것입니다. 하지만 "끔찍하다"고 하려면 그 차이가 한 자릿수는 되어야 한다고 생각합니다!
- bloppe
이것은 "성능"의 한 측면일 뿐입니다. glibc의 할당자는 더 빠를 수 있지만, 메모리도 더 많이 사용합니다.
훨씬 더 기술적인 논의는 https://github.com/sharkdp/fd/issues/710 을 참조하세요.
- mattrighetti
며칠 전에 올렸지만, musl 할당자 문제는 잘 알려진 것 같습니다 [0]
- grep_it
저는 링크된 바이너리의 크기와 단순함이 항상 주요 특징이었다고 생각합니다.