build2, 백지 상태 빌드에서 Ninja보다 2.2% 빠른 결과 내놔 논쟁 촉발

2.2% 빨라졌다는 계산 자체가 틀린 거 아냐? 3.355/3.429면 2.2% 정도 맞는데?

(작성자) 맞다, 실수 지적해줘서 고맙다, 고쳐놓을게

(Ninja 저자) 재밌게 읽었다, 근데 왜 build2가 더 빠른지 설명이 좀 부족한 느낌임. 세 가지 이유 중 첫번째는 CMake 비판이라 Ninja랑 상관없고, 두번째 헤더 의존성 멀티스레드 처리는 그럴듯한데 300개 파일 파싱 정도로 그렇게 차이 날까 싶고, 세번째는 컴파일러를 미리 한번 더 돌려서 헤더 모으는 거라 오히려 일이 더 많은 건데 이건 좀 의심스럽다

(build2 저자 답변) 24개 스레드로 병렬 처리하면 1~2% 정도야 충분히 날 수 있다고 봄. 파일 캐시 관련해서는 실제로 격리해서 측정했고 메모리 압박 있을 때 효과가 있더라

Ninja 만든 사람 대단하다, 진짜 좋은 도구임

make/ninja 계열은 output 타임스탬프가 input보다 최신인지만 보는데, 이것보다는 모든 입력의 modstamp를 추적해서 불일치하면 리빌드하는 방식이 더 낫지 않나 싶음, build2도 이 방향 가면 좋겠다

이 글 논조가 좀 깎아내리는 느낌이라 build2 써보고 싶은 마음이 확 줄었음. environment setup, configure, native build, cross build, packaging 단계를 왜 나누는지 이해 못하는 것 같음, 나는 nix + 직접 짠 configure + ninja 조합이 제일 만족스러움

CMake+Ninja는 생성 파일 없으면 꽤 효율적임, 근데 생성 파일이 라이브러리에 섞여 있으면 그 라이브러리 전체 컴파일이 직렬화되는 문제가 있음, Chromium 빌드에서 protoc 기다리는 것도 같은 이유임

meson/ninja나 cmake가 GNU configure한테서 못 배운 게 있는데, 바로 './configure --help'임. man page 설치 끄는 옵션 같은 것도 없어서 불편함

성능 개선 얘기할 때는 왜 빨라졌는지 원인 분석까지 같이 내놔야지, 이유 모르는 개선은 노이즈나 버그일 확률이 높음, 원인 모르면 나중에 그 이득도 유지 못함

autotools는 개발자가 아니라 소프트웨어 받아서 직접 빌드하는 최종 사용자를 더 신경 쓰는 철학이고, 최신 도구들은 개발자 경험 개선에 집중한 거라 관점이 다른 거임

나는 로컬 man page가 편함, 오프라인에서도 되고 소프트웨어 버전이랑 항상 같이 업데이트되니까, 온라인 문서보다 오히려 더 정확할 때가 많음