-j를 만들기 위해 전달된 최대 옵션 수를 결정하는 방법은 무엇입니까?

nproc사용 가능한 CPU 코어/스레드 수를 제공합니다.예를 들어8 양방향 SMT를 지원하는 쿼드 코어 CPU.

make이 옵션을 사용하여 병렬로 실행할 수 있는 작업 수는 -j다양한 요인에 따라 달라집니다.

• 사용 가능한 메모리 양
• make각 작업에 사용되는 메모리 양
• make작업이 I/O 또는 CPU에 바인딩된 정도

make -j$(nproc)좋은 출발점이지만 사용 가능한 메모리를 모두 소모하고 스래싱을 ​​시작하지 않는 한 일반적으로 더 높은 값을 사용할 수 있습니다.

매우 빠른 빌드를 위해 메모리가 충분하다면 를 사용하는 것이 좋습니다. tmpfs그러면 대부분의 작업이 CPU에 바인딩되어 make -j$(nproc)최대한 빠르게 실행됩니다.

가장 간단한 방법은 nproc다음과 같이 사용하는 것입니다.

make -j`nproc`

이 명령은 nproc머신의 코어 수를 반환합니다. 틱으로 래핑하면 nproc명령이 먼저 실행되고 에 전달될 숫자가 반환됩니다 make.

코어 수 + 1을 수행하면 컴파일 시간이 더 빨라진다는 일화적인 경험이 있을 수 있습니다. 이는 I/O 대기 시간, 기타 리소스 대기 시간 및 기타 리소스 가용성 제약 조건과 더 많은 관련이 있습니다.

이를 수행하려면 다음을 사용하십시오 nproc+1.

make -j$((`nproc`+1))

불행하게도 동일한 빌드의 서로 다른 부분이라도 빌드 중인 항목, 방법, 당시 병목 현상이 발생하는 시스템 리소스, 빌드 시스템에서 진행 중인 다른 작업, 무엇이 발생하는지에 따라 J-인자 값이 충돌하는 최적의 선택이 될 수 있습니다. 진행 중인 네트워크(분산 빌드 기술을 사용하는 경우), 빌드에 관련된 여러 캐시 시스템의 상태/위치/성능 등

100개의 작은 C 파일을 컴파일하는 것이 하나의 거대한 C 파일을 컴파일하는 것보다 빠를 수 있으며 그 반대의 경우도 마찬가지입니다. 매우 복잡한 작은 코드를 작성하는 것은 대량의 단순/선형 코드를 작성하는 것보다 속도가 느릴 수 있습니다.

빌드의 컨텍스트도 중요합니다. 전용 서버의 빌드에 최적화된 aj 요소를 사용하고, 겹치지 않는 독점 빌드에 대한 미세 조정은 개발자가 동일한 공유 서버에서 병렬로 빌드할 때 매우 혼란스러운 결과를 생성할 수 있습니다(각각의 이러한 빌드). 모든 직렬화를 합친 것보다 시간이 더 걸릴 수 있음) 또는 하드웨어 구성이나 가상화가 다른 서버의 경우.

건물 사양의 정확성 측면도 있습니다. 매우 복잡한 빌드에는 간헐적인 빌드 실패를 유발하는 경합 조건이 있을 수 있으며, 그 발생률은 j-인자가 증가하거나 감소함에 따라 크게 달라질 수 있습니다.

나는 계속해서 갈 수 있었다. 관건은 현실적으로 평가해야 한다는 것이다.당신의내장당신의 배경j 인자를 최적화하고 싶습니다. @Jeff Schaller의 의견이 적용됩니다. 가장 적합한 것을 찾을 때까지 반복하십시오. 개인적으로 저는 nproc 값으로 시작하여 먼저 시도한 다음, 위로 시도한 결과 즉각적인 성능 저하가 나타나는 경우에만 시도합니다.

측정의 변동성에 대한 아이디어를 얻기 위해 먼저 동일한 환경에서 몇 개의 동일한 빌드를 측정하는 것이 좋습니다. 측정값이 너무 높으면 전체 최적화 노력이 위태로워질 수 있습니다(20% 변동성은 완전히 j-요인 검색에서 판독값을 10% 개선/퇴화시킵니다.)

마지막으로 IMHO (적응형)를 사용하는 것이 더 좋습니다.작동 중인 서버고정된 j 인자가 아닌 지원되고 사용 가능한 경우 더 넓은 맥락에서 지속적으로 더 나은 빌드 성능을 제공할 수 있습니다.

make가상 CPU 수만큼 병렬 작업자 스레드를 사용하는 명령을 작성하려면 다음을 사용하는 것이 좋습니다.

nproc | xargs -I % make -j%

RUN독립 실행형 명령이나 내부 지시문으로 작성할 수 있습니다 Dockerfile(Docker는 중첩 명령을 지원하지 않기 때문).