당신의 코드는 빠르다 - 운이 좋다면: 왜 마이크로 벤치마크가 거짓말을 하는지

바이럴 게시물이 마이크로 벤치마크의 신뢰성을 cuestion 하게 합니다: 동일한 코드가 기호의 순서, 메모리 위치 또는 사용자 이름에 따라 최대 30%까지 달라질 수 있습니다. 이것이 크래프트에 미치는 영향.

간단히 말해

개발자가 동일한 코드 조각이 링크 타임의 심볼 순서, 환경 변수 크기, 메모리 정렬과 같은 알고리즘과 무관한 매개변수에 따라 30% 더 빠르거나 느려질 수 있음을 보여주었습니다. 다시 말해, 마이크로초 단위로 측정하는 많은 부분이 순전히 운에 좌우됩니다.

배경

저자는 tiki.li/blog/lucky_code에서 컴파일러(에머리 버거, Stabilizer, ASPLOS 2013)에서 이미 잘 알려진 내용을 현대적으로 재조명한 글에서 동일한 바이너리를 수정하지 않고 빌드 디렉토리 이름, 오브젝트 파일 링크 순서, $PATH 크기와 같은 주변 매개변수를 변경하여 실행했습니다. 결과적으로 L1i/uop 캐시, x86 디코더, 분기 예측과 같은 인스트럭션 정렬이 가상 주소에 민감하게 반응하면서 런타임이 최대 30%까지 크게 변화했습니다.

문제는 이겁니다: 실제로는 PR을 비교할 때 8%의 성능 향상을 기록하고 머지합니다. 이 중 몇 퍼센트가 진짜 신호이고, 몇 퍼센트가 정렬 노이즈일까요?

내부 메커니즘

• Stabilizer (버거 2013)는 매 실행 시 스택, 힙, 코드 할당을 무작위로 변경하여 측정값을 분포로 만듭니다.
• Hyperfine + -warmup + -runs 50은 문제를 해결하지 못합니다. 동일한 바이너리의 각 실행에서 정렬이 동일하기 때문에 평균을 내도 해결되지 않습니다.
• 올바른 방법: Stabilizer로 무작위 오프셋을 재컴파일하거나 -randomize-address로 실행하고 95% 신뢰 구간(IC)을 보고해야 합니다.

결론

세 가지 실무적 결과: 첫째, 단일 마이크로벤치마크에서 10% 미만의 성능 향상은 대부분 노이즈입니다. 이를 거부하거나 무작위화하여 재측정하세요. 둘째, CI 성능 회귀 테스트(예: Codspeed)는 무작위화를 도입해야 합니다. 그렇지 않으면 진짜 회귀를 놓치고 노이즈에 당황할 수 있습니다. 셋째, 컴파일러 및 런타임 벤치마크(예: Bun vs Node, Zig vs C…)는 이 필터로 읽어야 합니다. 이 수준의 성능은 빌드 엔지니어링과 알고리즘만큼이나 중요합니다.