É possível acelerar ./configure?

Question

Para compilar um pacote de software em uma estação de trabalho com muitos núcleos de CPU (digamos 12), o estágio de configuração geralmente demora muito mais do que o estágio de compilação real porque ./configure faz os testes um por um, enquanto make -j runs gcc , bem como outros comandos em paralelo.

Eu sinto que é um grande desperdício de recursos ter os 11 núcleos remanescentes parados durante a maior parte do tempo, esperando que o ./configure lento seja concluído. Por que precisa fazer os testes sequencialmente? Cada teste depende um do outro? Eu posso estar enganado, mas parece que a maioria deles é independente.

Mais importante, existem maneiras de acelerar ./configure ?

Edit: Para ilustrar a situação, aqui está um exemplo com o GNU Coreutils

cd /dev/shm
rm -rf coreutils-8.9
tar -xzf coreutils-8.9.tar.gz
cd coreutils-8.9
time ./configure
time make -j24

Resultados:

# For 'time ./configure'
real    4m39.662s
user    0m26.670s
sys     4m30.495s
# For 'time make -j24'
real    0m42.085s
user    2m35.113s
sys     6m15.050s

Com coreutils-8.9 , ./configure leva 6 vezes mais que make . Embora ./configure use menos tempo de CPU (veja "user" & "sys" vezes), demora muito mais ("real") porque não está em paralelo. Eu repeti o teste algumas vezes (com os arquivos relevantes provavelmente permanecendo no cache de memória) e os tempos estão dentro de 10%.

    

Answer 1

Eu me lembro de discussões na lista de discussão do Autoconf sobre esse assunto há cerca de 10 anos atrás, quando a maioria das pessoas realmente tinha apenas um núcleo de CPU. Mas nada foi feito e suspeito que nada será feito. Seria muito difícil configurar todas as dependências para o processamento paralelo em configure e fazê-lo de maneira portátil e robusta.

Dependendo do seu cenário específico, pode haver algumas maneiras de acelerar as execuções do configure de qualquer maneira. Por exemplo:

• Use um shell mais rápido. Por exemplo, considere usar dash em vez de bash como /bin/sh . (Nota: No Debian, dash é corrigido para que configure não o use, porque usá-lo quebra muitos scripts configure .)
• Se você executar compilações remotamente (por meio de ssh, por exemplo), então descobri que a saída do console pode ser bem lenta. Considere chamar configure -q .
• Se você criar repetidamente o mesmo projeto, considere o uso do arquivo de cache. Chame configure -C . Veja a documentação do Autoconf para detalhes.
• Se você criar muitos projetos diferentes, considere usar um arquivo de site ( config.site ). Mais uma vez, veja a documentação.
• Crie vários projetos em paralelo.

Answer 2

Você tem sido inteligente em usar o ramdrive para que o sourcetree resida, mas pense duas vezes - o que o configure faz? Ele faz o seu trabalho verificando não apenas o seu sourcetree , mas também o sistema para disponibilidades de biblioteca, compiladores, etc. Neste caso, o problema de acesso às vezes reside em Acesso ao disco - Você terá feito isso muito mais rápido se tiver, por exemplo, um sistema de arquivos raiz baseado em SSD.

    

Answer 3

Se você estiver usando o controlador de cpu ondemand, tente usar o desempenho um. Isso ajuda no i7 e no a8-3850 em 40 a 50%. Não faz muita diferença no q9300.

Em uma CPU quad-core, você pode fazer

for cpu in 'seq 0 3'; do sudo cpufreq-set -g performance -c $cpu; done

(A opção -r deve fazer com que você não tenha que fazer cpufreq-set para cada núcleo, mas nos meus computadores não funciona.)

A opção de cache ajuda ainda mais.

    

Answer 4

Existem muitos tipos de scripts ./configure . Existem ferramentas populares ( autconf sendo uma delas) para ajudar um desenvolvedor a criar um script ./configure , mas há nenhuma regra que diga que todo desenvolvedor deve usar essas ferramentas e, mesmo entre essas ferramentas, pode haver grandes variações na maneira como esses scripts são construídos.

Não conheço nenhum script ./configure popular que possa ser executado em paralelo. A maioria dos scripts criados por ferramentas populares armazena pelo menos alguns ou todos os seus resultados, portanto, se você executá-lo novamente (sem fazer um make clean primeiro, de qualquer forma), ele será executado muito mais rápido na segunda vez.

Isso não quer dizer que não poderia ser feito ... mas eu suspeito que há pouca motivação para as pessoas que trabalham em autoconf , por exemplo, fazer isso, já que para maioria pacotes, a fase de configuração é muito rápida em relação às fases reais de compilação e vinculação.

    

Answer 5

O disco rígido é o gargalo neste caso. Para acelerar a compilação, construa em um sistema com drives rápidos (leia-se: baixo tempo de acesso). Há muito barulho sobre os discos SSD, mas houve algumas críticas sobre eles que não afetam o tempo de compilação de forma positiva. Isso quer dizer que construir em SSD não era muito mais rápido do que em uma unidade sata decente. Eu não consigo me lembrar onde eu li isso porque o artigo tem um par de anos.

De qualquer forma ... Untar para ram e construir a partir daí.

mkdir /tmp/tmp 
mount -t tmpfs -o size=400M tmpfs /tmp/tmp 
cd /tmp/tmp
tar xjf somesourcetarball-1.1.33.tar.bz2

    

Answer 6

Sua pergunta pode ser ainda mais relevante hoje, já que temos CPUs de dúzia de núcleos com desempenho (muito baixo) de núcleo único. Construções automatizadas para Integração Contínua (CI) realmente desperdiçam muito tempo / energia da CPU para cada commit. Mesmo com saltos entre filiais.

Então, leia / leia minhas dicas sobre como acelerar o processo em link .

"Por que precisa fazer os testes sequencialmente? ..." Na verdade, existem algumas coisas que podem ser feitas em paralelo, enquanto outras precisam ser seqüenciais. Várias coisas dependem do ambiente de construção - e o próprio script de configuração é independente do sistema. Ele não contém nem mesmo bashisms, então funciona com um shell POSIX puro.

Se você quiser escrever software portátil, não há outro sistema de criação como o autotools. Mas se você não se importar com a portabilidade (ampla), evite autotools - existe uma infinidade de ferramentas de construção rápidas e boas o suficiente.