상대적으로 예상되는 작업 시간을 일정에 통합하는 빌드 시스템이 있습니까?


13

내 질문에 대한 작은 그림이 있습니다.

AD라는 4 개의 독립적 인 작업으로 구성된 빌드 작업을 가정합니다. D는 AC보다 총 시간이 오래 걸립니다.

상대 작업 시간을 통합 할 수없는 빌드 시스템은 다음과 같은 작업을 예약 할 수 있습니다.

---------------------------------------
CPU1: A  |    C   |
---------------------------------------
CPU2: B    | D                        |
---------------------------------------

반대로, 스케줄러가 작업 시간 차이를 인식하면 다음과 같이 훨씬 짧은 스케줄이 나타날 수 있습니다.

---------------------------------------
CPU1: A  |  B    |   C   |
---------------------------------------
CPU2: D                        |
---------------------------------------

내 질문 :

  1. 상대적으로 예상되는 작업 시간을 일정에 통합하는 빌드 시스템이 있습니까?
  2. 이런 종류의 빌드 시스템에 대한 학술 연구는 무엇입니까?
  3. 이러한 빌드 시스템 (있는 경우)은 시간 정보를 어디에서 가져 옵니까? 휴리스틱, 이전 빌드 중에 수집 된 타이밍?
  4. 그러한 빌드 시스템이 존재하지 않는 이유는 무엇입니까? 언뜻보기보다 덜 가치가있는 문제가 있습니까?

3
타사 리소스 또는 도구에 대한 대부분의 질문은 "주제 이외의"항목으로 신속하게 마감되었지만이 질문이이 사이트의 범위에 잘 맞는 것으로 보이는 경우 일 수 있습니다.
Doc Brown

1
나는 이것이 작업을 "빌드"하는 것이 비평 행이라는 잘못된 가정에 근거한다고 생각한다.
dagnelies

대부분의 경우 작업을 빌드하는 것은 실제로 병렬이 아니지만, 예를 들어 멀티 스레드 응용 프로그램의 단위 테스트는 실제로 병렬 일 수 있습니다. 실제로, 내가 일하는 프로젝트에서는 항상 성능 테스트와 관련된 멀티 코어 단위 테스트가 실패하기 때문에 단위 테스트 실행을 위해 항상 "-j1"과 함께 "make"를 호출해야합니다.
juhist

@juhist 좀 더 표현력있는 빌드 시스템으로 전환하고자하는 경우, shake 에는 예를 들어 단위 테스트를 위해 예약 할 CPU 코어 수를 정의 할 수있는 리소스 개념이 있습니다 .
sjakobi

답변:


3

Microsoft Visual Studio Team System (이전의 TFS)은 빌드 작업 시간과 병렬 빌드를 고려합니다. 이전 빌드 히스토리에서 데이터를 가져옵니다. 상자에서 원하는 동작을 얻을 수 있다고 생각하지는 않지만 사용자 정의 할 수 있습니다.

성능 최적화를 위해 작동하는 일부 사용자 지정 작업의 예

https://veegens.wordpress.com/2013/03/26/tfs-2010-build-performance-report/


귀하의 답변과 링크를 올바르게 이해하면 빌드 작업 시간이 보고 되지만 (일반적인 기능 임) 빌드 일정을 개선하기 위해 이러한 타이밍을 사용할 수 있는지 여부는 확실하지 않습니다. 이것은 실제로 내 원래의 질문에 대답하지 않는 것 같으므로 귀하의 답변에 현상금을 수여하지 않습니다.
sjakobi

문제는, 프로그래밍을 통해 빌드 조치 및 빌드 프로세스를 사용자 정의 할 수 있다는 것입니다. 샘플이보고되었지만 언급 된대로 자동 최적화 기록이 사용됩니다. 또한 병렬 빌드를 구성 할 수 있습니다. 그러나 알고리즘에 따라 병렬화되도록하려면 코드로 사용자 정의해야 할 수도 있습니다. 추가 참고 자료 : dotnetcurry.com/visualstudio/1177/…
Bruno Guardia

2
@BrunoGuardia : 링크의 기사에서 빌드 작업의 예상 작업 시간을 활용하는 데 도움이 될 수있는 사용자 정의 옵션이 어디에 있는지 설명 할 수 있습니까?
Doc Brown

0

이것은 작업을 "빌드"하는 것이 비 병렬이라는 잘못된 가정에 근거합니다.

많은 컴파일러가 멀티 스레드로 작동하므로 단일 작업 A가 모든 CPU를 사용합니다. 따라서 순서는 중요하지 않습니다. 특히 네트워킹과 관련된 I / O 바운드 작업의 경우 처음부터 병렬로 시작하는 것이 좋습니다. 대부분의 시간은 답변을 기다리는 데 소비됩니다.

즉, 개별 작업이 일반적으로 병렬화되므로 순서는 중요하지 않습니다 (예 : 컴파일).


편집하다:

실제로 "CPU 1의 작업 A"라는 개념에도 결함이 있습니다. 단일 스레드 작업의 경우에도 프로세스 / 스레드를 예약하는 OS가 각 컨텍스트 스위치에서 CPU에서 CPU로 홉할 수 있습니다. 대부분의 빌드 시스템은 모든 작업을 병렬로 실행하고 OS가 일정을 수행하게합니다. 긴 작업은 더 오래 걸리고 그에 관한 것입니다.

I / O 바운드되지 않은 장시간 실행되는 단일 스레드 작업이 있다고 가정하면 빌드 시스템이 더 작은 작업을 지연시켜 OS의 컨텍스트 스위치를 줄이기보다 우선 순위 / 중요성을 할당하는 것이 더 쉽습니다.

당신이 그런 경우에도 이상한 실제로는 매우 드문 작업을, 이전 실행을 기반으로 추론에서 작동 멋진 스케줄링 빌드 시스템 (알 수있는 유일한 방법)가, 당신이 그것에서 얻는 이점은 오히려 작은 수 있습니다 .. 그러나 유지 관리해야 할 복잡성이 더해집니다.


"작업 내"병렬 처리는 흥미로운 측면이며 최적화를위한 추가적인 잠재력을 제공하지만, 주어진 작업이 임의의 수의 CPU로 효율적으로 확장된다고 가정하는 것이 각 작업을 실행해야한다고 가정하는 것보다 낫다고 생각하지 않습니다. 단일 코어.
sjakobi

@ sjakobi : 글쎄, 실제로 컴파일러가 효율적이라는 것이 중요합니다. 16 개 코어 중 1 개만 사용되므로 컴파일을 기다리는 데 오랜 시간이 걸린다고 상상할 수 있습니까? 그건 끝이 없습니다. 모든 이론으로 당신은 현실을 간과하는 것 같습니다. 스케줄링은 매우 흥미롭고 의미있는 주제입니다. 빌드 시스템의 맥락에서 IMHO는 상대적으로 쓸모가 없습니다. 다시 말하지만, 오늘날 대부분의 컴파일러는 어쨌든 멀티 스레드입니다 ... 그렇지 않으면 스케줄링 빌드 시스템보다는 노력을 기울여야합니다.
dagnelies

2
C ++ 또는 C 또는 Fortran 또는 Ada를위한 모든 무료 소프트웨어 컴파일러 ( GCC & Clang ...)는 모노 스레드입니다. 빌드 시스템 ( make -j)은 여러 컴파일 프로세스를 병렬로 시작할 수 있습니다.
바 실레 Starynkevitch

@BasileStarynkevitch : ... 사실. 기본적으로 모두 제정신이 사용 -j <nb-cores>하지만 슬프게도 기본값은 여전히 ​​"1"입니다.
dagnelies

@dagnelies : 몇 가지 중요한 종속성이 누락되어 -jN에서 작동하지 않거나 작동하지 않는 수많은 Makefile이 있습니다. 여기서 N> 1입니다.
juhist
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.