Existem sistemas de construção que incorporam tempos de tarefa relativos esperados no planejamento?

Aqui está uma pequena ilustração da minha pergunta:

Suponha um trabalho de construção que consiste em 4 tarefas independentes denominadas AD. D leva mais tempo que a CA, em suma.

Um sistema de construção que não pode incorporar os tempos relativos das tarefas pode agendar as tarefas da seguinte maneira:

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

Por outro lado, se o planejador estiver ciente das diferenças de tempo da tarefa, poderá criar um cronograma muito mais curto:

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

Minhas perguntas:

Existem sistemas de construção que incorporam tempos de tarefa relativos esperados no planejamento?
Que pesquisa acadêmica sobre sistemas de construção desse tipo existe?
De onde esses sistemas de construção (se eles existem) tiram as informações de tempo? Heurísticas, tempos coletados durante as compilações anteriores?
Se tais sistemas de construção não existem, por quê? Existe uma pegadinha que os tornaria menos dignos do que parecem à primeira vista?

scheduling research build-system

— sjakobi
fonte

A maioria das perguntas sobre recursos ou ferramentas de terceiros são fechadas rapidamente como "fora de tópico", mas acho que esse poderia ser um caso de ponta que parece se encaixar bem no escopo deste site.

— Doc Brown

Eu acho que isso se baseia na suposição errada de que "construir" uma tarefa não é paralelo.

— Dagnelies

Na maioria dos casos, a construção de uma tarefa é de fato não paralela, mas sim, por exemplo, testes de unidade em aplicativos multithread podem de fato ser paralelos. Na verdade, em um projeto em que trabalho, sempre precisamos chamar "make" com "-j1" para a execução do teste de unidade, porque, caso contrário, os testes de unidade multicore relacionados ao desempenho falham.

— juhist

@juhist Caso você esteja interessado em mudar para um sistema de construção mais expressivo, o shake possui um conceito de recursos onde você pode, por exemplo, definir quantos núcleos de CPU devem ser reservados para seus testes de unidade.

— sjakobi

Respostas:

O Microsoft Visual Studio Team System (anteriormente TFS) considera tempos de ação de compilação e compilações paralelas; pega os dados do histórico de compilação anterior; e, embora eu não acredite que você consiga obter o comportamento desejado imediatamente, poderá personalizá-lo.

Um exemplo de algumas tarefas personalizadas para otimizar o desempenho

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

— Bruno Guardia
fonte

Se eu entendo sua resposta e seu link corretamente, os tempos de ação da compilação são relatados (o que é um recurso bastante comum), mas não está claro se ou como esses tempos podem ser usados para melhorar o cronograma da compilação. Isso realmente não parece responder às minhas perguntas originais, por isso não concederei a recompensa à sua resposta.

— sjakobi

Não tem problema, o que você pode ter perdido é que você pode personalizar as ações de construção e o processo de construção, através da programação. A amostra estava relatando, mas, como afirmado, o histórico é usado para otimizações automáticas. Além disso, observe que você pode configurar compilações paralelas. Mas, para garantir que eles estejam paralelos seguindo o seu algoritmo, você pode precisar personalizar o código. Alguma referência adicional: dotnetcurry.com/visualstudio/1177/…

— Bruno Guardia

@BrunoGuardia: você pode explicar onde nesse artigo do seu link há uma opção de personalização mencionada que pode ajudar a utilizar os tempos de tarefa esperados das ações de construção?

— Doc Brown

Isso se baseia na suposição errada de que "construir" uma tarefa não é paralelo.

Muitos compiladores trabalham com vários threads, portanto, uma única tarefa A usará todas as CPUs. Portanto, o pedido não importa. Para tarefas vinculadas de E / S, especialmente envolvendo redes, é melhor iniciá-las todas paralelamente desde o início: será gasto mais tempo aguardando uma resposta.

Em outras palavras, a ordenação não importa, pois as tarefas individuais geralmente são paralelizadas (como compilar, por exemplo)

Editar:

Na verdade, essa concepção de "Tarefa A na CPU 1" também é falha. Mesmo para tarefas de encadeamento único, o SO que agende os processos / encadeamentos pode saltar de CPU para CPU em cada opção de contexto. Eu acho que a maioria dos sistemas de compilação executará todas as tarefas em paralelo e permitirá que o SO faça o agendamento. Tarefas mais longas levarão mais tempo e é isso.

Supondo que você tenha uma tarefa encadeada única de longa execução que não esteja vinculada a E / S , seria muito mais fácil para o sistema de construção atribuir uma prioridade / importância a ele, ao invés de tentar atrasar tarefas menores para reduzir as alternâncias de contexto do sistema operacional.

Mesmo que você tenha tarefas tão estranhas , o que é bastante raro na prática, e tenha um sistema sofisticado de criação de agendamento que funcione com heurísticas com base em execuções anteriores (a única maneira de saber), os benefícios que você obtém dela podem ser bastante pequenos. de qualquer forma, você obtém um monte de complexidade adicional para manter.

— dagnelies
fonte

O paralelismo "dentro da tarefa" é um aspecto interessante e certamente oferece um potencial adicional de otimização, mas não acho que supor que uma determinada tarefa seja dimensionada com eficiência para um número arbitrário de CPUs é melhor do que assumir que cada tarefa deve ser executada um único núcleo.

— sjakobi

@sjakobi: bem, na prática é muito importante que os compiladores sejam eficientes. Você pode imaginar que espera muito tempo para compilar porque apenas 1 de seus 16 núcleos é usado? Isso é proibido. Com toda a teoria, você parece ignorar a realidade. O agendamento é um tópico muito interessante e muito significativo. É apenas IMHO relativamente inútil no contexto de sistemas de construção. Novamente, a maioria dos compiladores hoje em dia é multithread de qualquer maneira ... e, se não forem, deve-se esforçar bastante nesse sistema de construção de agendamento.

— Dagnelies

Todos os compiladores de software livre ( GCC & Clang ...) para C ++ ou C ou Fortran ou Ada são monoencadeados. O sistema de compilação ( make -j) pode iniciar vários processos de compilação em paralelo.

— Basile Starynkevitch 5/02

@BasileStarynkevitch: ... de fato. Basicamente, todo mundo usa, -j <nb-cores>mas infelizmente o padrão ainda é "1" ... Ainda estou surpreso por nunca ter mudado.

— Dagnelies

@ dagnelies: Existe um grande número de Makefiles que perdem algumas dependências críticas e, portanto, não funcionam (ou podem não funcionar) com -jN, em que N> 1.

— juhist