Ninja: 휴리스틱: 입력이 적은 작업보다 입력이 큰 작업 실행

컴파일 시간이 고유하게 파일 크기의 함수인지 확신할 수 없습니다. 컴파일러가 깨기 힘든 작은 파일과 사소한 큰 파일을 상상할 수 있습니다.

컴파일 시간이 고유하게 파일 크기의 함수인지 확실하지 않습니다.

그렇지 않다. 그럼에도 불구하고 컴파일 시간은 확실히 파일 크기와 양의 상관관계가 있습니다. 따라서 이 휴리스틱의 이점.

또한 닌자는 일종의 PGO(프로파일 기반 최적화):+1: 각 파일을 컴파일하는 데 걸린 시간 정보를 수집하고 이 정보를 사용하여 다음 빌드에서 파일의 우선 순위를 정하는 것과 같은 작업을 수행할 수도 있습니다.

그럼에도 불구하고 컴파일 시간은 확실히 파일 크기와 양의 상관관계가 있습니다.

소스 파일을 기반으로 하는 휴리스틱은 의미가 없다고 생각합니다. 예를 들어 거의 1분 동안 컴파일되는 천 줄 미만의 C++ 파일이 있습니다(묻지 않음). 궁극적으로 전처리기용 파일이 얼마나 어려운지와 컴파일 중에 인스턴스화할 템플릿 수에 따라 다릅니다.

물론 30k 라인 파일이 1k 라인보다 더 오래 컴파일될 것이라고 가정할 수 있지만 내 생각에는 닌자가 내려야 할 결정은 아닙니다.

각 파일을 컴파일하는 데 걸리는 시간 정보 수집과 같은...

이것은 이미 .ninja_log에서 수행됩니다. https://github.com/nico/ninjatracing 스크립트를 사용하여 구문 분석하고 크롬에서 로드하여 빌드 프로세스가 어떻게 진행되었는지 확인할 수 있습니다.

...이 정보를 사용하여 다음 빌드에서 파일의 우선 순위를 지정합니다.

그래서 우리는 이미 빌드 시간 정보를 가지고 있기 때문에 닌자는 실제로 다음 빌드에서 그 정보를 사용할 수 있습니다. 실제로 도움이 될 수 있습니다.

편집하다:

좋습니다. 실제로 컴파일 시간을 살펴보았습니다. 가장 오래 컴파일되는 파일은 https://github.com/llvm-mirror/clang/blob/master/lib/ASTMatchers/Dynamic/Registry.cpp 이며 600줄만 있습니다. 따라서 파일 크기 메트릭은 이 특정 파일에 대해 전혀 작동하지 않습니다.

또한 그 과정에서 병목 현상이 보이지 않습니다. 하지만 13개의 스레드로 빌드하는 데 도움이 될 수 있습니다.

안녕하세요, 확실하지 않은 경우를 대비하여 실제로 LLVM 및 clang에서 작업합니다. 나는 지난 몇 주 동안 clang/llvm 백엔드의 속도를 최적화하는 데 시간을 보냈고 사실 이 과정에서 이 문제가 발생했습니다. 당신은 클랜의 깨끗한 재건 팩이 맞습니다. 그러나 특정 헤더를 터치하면 x86 isel lowering(알파벳에서 늦게 나타나 문제를 악화시킴)과 같은 매우 긴 컴파일 중 하나를 쉽게 기다리게 될 수 있습니다.

위의 분석은 하나의 파일만 보기 때문에 통계적으로 의미가 없습니다. 다음은 clang의 깨끗한 빌드를 수행하는 내 컴퓨터에서 cpp 파일 크기(x축) 대 컴파일 시간(y축)의 산점도입니다.

파일 크기와 컴파일 시간 사이에 상관 관계가 없다면 무작위 노이즈처럼 보일 것입니다. 그러나 보시다시피 파일 크기와 컴파일 시간 사이에는 상당한 상관관계가 있습니다.

어쨌든 과거 컴파일 시간을 사용하여 주문을 알리는 것이 좋습니다.

물론 상관관계가 있습니다. 그러나 모든 프로젝트에 보편적일 수 있을 만큼 충분히 결정적이지 않다고 생각합니다. 데이터가 없어서 여기에서 틀릴 수 있습니다.

참조 #60 #376 #232

그러나 모든 프로젝트에 보편적일 수 있을 만큼 충분히 결정적이지 않다고 생각합니다.

아마도 내 제안이 명확하지 않을 수 있습니다.

제안은 _건물 A와 B 사이에서 임의의 선택을 하려는 경우에는 발견적 방법을 사용하여 빌드하는 데 시간이 더 오래 걸리는 대상을 파악하는 것입니다. "지난번에 빌드하는 데 시간이 얼마나 걸렸는지 확인하십시오"라는 경험적 방법은 파일 크기를 확인하는 제 제안보다 훨씬 좋습니다. 그러나 과거 빌드 시간이 없는 경우 파일 크기가 여전히 유용할 것으로 예상합니다.

다시 말하지만, 더 나은 휴리스틱(예: 언급한 것 중 하나)이 적용되는 경우 이를 사용해야 합니다. 그러나 나는 이 휴리스틱을 최후의 수단으로 적용할 것을 제안하는 것일 뿐이므로 "보편적"이 아니라는 사실이 차이를 만들지 않는다고 생각합니다. 우리는 자의적인 선택을 하려고 했고, 이제는 조금 덜 자의적인 선택을 합니다.

어쨌든 과거 빌드 시간을 보는 것이 훨씬 낫습니다. 파일 크기를 보면 크게 신경 쓰지 않습니다. :)

Ninja는 건물 A와 B 사이에서 임의의 선택을 하기 위한 휴리스틱을 가지고 있습니다. 즉, 매니페스트에서 먼저 빌드하는 것입니다. 대신 build.ninja 생성기에 휴리스틱을 넣을 수 있습니까?

@colincross 초기 주문에는 문제가 없지만 후속 주문은 타이밍을 사용하여 생성자가 기대할 수 있는 것보다 더 정확할 수 있습니다. 개인적으로 초기 빌드 시간에 대해 크게 걱정하지 않지만 생성기는 그런 식으로 최적화할 수 있습니다.

파일 크기를 사용하는 것이 "프로파일링"에 충분하지 않을 수 있다고 생각합니다. 예를 들어, 포함이 많은 아주 작은 cpp 파일은 처리하는 데 정말 오래 걸릴 수 있습니다. 그리고 비 컴파일 프로세스(파싱, 복사, 파일 생성...)는 파일 크기와 관련이 없습니다.
그래도 일부 빌드 단위에는 좋은 접근 방식입니다.
두 번째 접근 방식은 일부 파일을 빌드하는 데 필요한 시간을 캐시에 저장하는 것입니다. 이 캐시를 분석하여 재구축을 최적화할 수 있습니다.

Ninja는 작업 시간을 절약하므로 해당 정보가 있습니다. 첫 번째 빌드가 최적이 아닐 수도 있지만 ninja deps 로그도 채워지지 않았기 때문에 이미 그렇습니다.

https://github.com/ninja-build/ninja/issues/232
https://github.com/ninja-build/ninja/issues/376

@jlebar ,
https://go.googlesource.com/gollvm/과 비슷한 것이 있습니다. 특정 파일이 "메모리 부족" 오류를 특징으로 하는 컴파일러 충돌을 시행하기 전에 수천 개의 컴파일된 소스 파일을 얻었습니다.
현재 두 개의 파일로 인해 이러한 오류가 발생합니다.
https://github.com/llvm/llvm-project/blob/7d3aace3f52f6b3f87aac432aa41ae1cdeb348eb/llvm/lib/Target/AMDGPU/AMDGPULowerIntrinsics.cpp
https://github.com/llvm/llvm-project/blob/7d3aace3f52f6b3f87aac432aa41ae1cdeb348eb/llvm/lib/Target/AArch64/AArch64PreLegalizerCombiner.cpp
Golang의 컴파일러 프론트엔드가 OpenCL 또는 OpenGL과 관련이 있다는 사실에 약간의 의구심이 있지만(현재 백엔드에는 관련 기존 이벤트가 없음) 일반 CPU 프로그래밍을 위한 ARM64 지원이 존재합니다.
어떤 경우에도 CMake의 구성에서 LLVM 프로젝트의 일부를 비활성화해야 합니다.
그러나 첫 번째 파일은 2934개 파일 중 697개(과거 컴파일 프로세스는 컴파일된 .o 파일을 보존함)이고 두 번째 파일(클린 빌드 내)은 3214개 파일 중 817개입니다.
다른 파일을 먼저 컴파일하는 것이 가장 좋으므로 RAM을 가장 많이 소비하는 파일에 예상대로 고정됩니다. 그래서 나는 그것들을 마지막으로 얻는 데 관심이 있을 것입니다. 그리고 시도하기 전에는 알 수 없기 때문에 어떤 문제가 있는지 확인합니다. 아니면 내가 할 수 있습니까?

이반

@advancedwebdeveloper 실제로 Ninja에는 선택한 -jN 설정과 병렬로 모든 것을 컴파일하기에 충분한 RAM이 있다는 가정이 있습니다. 근본적으로 이 문제는 Ninja가 선택한 순서로 인해 발생하는 것이 아니라 Ninja(및 내가 알고 있는 다른 모든 빌드 도구)가 병렬 처리를 제한하는 매우 거친 방법만 제공한다는 사실 때문에 발생합니다. -j 플래그입니다.