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

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

간단히 말해

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

배경

작가는 tiki.li/blog/lucky_code에서 컴파일러(에머리 버거, Stabilizer, ASPLOS 2013)에서 이미 잘 알려진 내용을 현대적으로 재조명합니다. 그는 동일한 바이너리를 수정하지 않고 빌드 디렉터리 이름, 오브젝트 파일 링크 순서, $PATH 크기 등 주변 매개변수를 변화시키며 실행합니다. 이 결과 런타임이 크게 변동하며, 마이크로 벤치마크에서는 30% 이상 차이가 발생하기도 합니다. 원인은 L1i/uop 캐시, x86 디코더, 그리고 분기 예측이 코드의 가상 주소에 민감하기 때문입니다.

모든 사람을 불안하게 해야 할 점: 실생활에서 PR을 비교할 때 8% 성능 향상을 확인하고 머지합니다. 이 중 실제 신호는 몇 퍼센트고, 정렬 노이즈는 몇 퍼센트일까요?

내부 메커니즘

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

결론

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