É possível acelerar ./configure?

Para compilar um pacote de software em uma estação de trabalho com muitos núcleos de CPU (por exemplo, 12), o estágio de configuração geralmente leva muito mais tempo que o estágio de compilação real, porque ./configurefaz os testes um por um, enquanto make -jexecuta gcce outros comandos em paralelo.

Eu sinto que é um enorme desperdício de recursos manter os 11 núcleos restantes ociosos a maior parte do tempo, esperando ./configurea conclusão lenta . Por que ele 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 , ./configureleva 6 vezes mais que make. Embora ./configureuse menos tempo de CPU (veja os tempos de "usuário" e "sys"), leva muito mais tempo ("real") porque não é paralelo. Repeti o teste algumas vezes (com os arquivos relevantes provavelmente ficando no cache da memória) e os tempos estão dentro de 10%.

Lembro-me de discussões na lista de discussão da Autoconf sobre esse problema de 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 processamento paralelo configuree fazê-lo de maneira portátil e robusta.

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

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

Você foi esperto ao usar o ramdrive para o código fonte residir, mas pense duas vezes - o que o configure faz? Ele faz seu trabalho verificando não apenas o código fonte , mas também o sistema quanto às disponibilidades de bibliotecas, compiladores etc. Nesse caso, o problema de acesso às vezes reside no acesso ao disco - você o fará muito mais rapidamente se tiver exemplo, um sistema de arquivos raiz baseado em SSD.

Se você estiver usando o ondemand cpu governador, tente usar o desempenho. Isso ajuda no i7 e no a8-3850 em 40-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 permitir que você não precise fazer o cpufreq-set para cada núcleo, mas nos meus computadores isso não funciona.)

A opção de cache ajuda ainda mais, no entanto.

Existem muitos tipos de ./configurescripts. Existem ferramentas populares ( autconf sendo uma delas) para auxiliar um desenvolvedor na criação de um ./configurescript, mas não existe uma 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 ./configurescript popular que possa ser executado em paralelo. A maioria dos scripts criados por ferramentas populares armazena pelo menos alguns ou todos os resultados, portanto, se você o executar novamente (sem fazer o make cleanprimeiro, pelo menos), ele será executado muito mais rápido na segunda vez.

Isso não quer dizer que não possa ser feito ... mas suspeito que há pouca motivação para as pessoas que trabalham autoconfnisso, por exemplo, uma vez que, para a maioria dos pacotes, a fase de configuração é muito rápida em relação à compilação e vinculação reais fases.

O disco rígido é o gargalo neste caso. Para acelerar a construção, construa em um sistema com unidades rápidas (leia-se: baixo tempo de acesso). Há muita confusão sobre os discos SSD, mas houve algumas críticas a respeito de eles não afetarem o tempo de compilação de maneira positiva. Ou seja, a construção no SSD não foi muito mais rápida do que em uma unidade SATA decente. Não me lembro onde li isso porque o artigo tem alguns anos.

Enfim ... 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

Sua pergunta pode até ser mais relevante hoje em dia, pois temos CPUs de uma dúzia de núcleos com (bastante) baixo desempenho de núcleo único. As compilações automatizadas para integração contínua (IC) realmente desperdiçam muito tempo / energia da CPU para cada confirmação. Mesmo com salto entre os galhos.

Portanto, reveja / leia minhas dicas sobre como acelerar a coisa em https://gitlab.com/gnuwget/wget2/wikis/Developer-hints:-Increasing-speed-of-GNU-toolchain .

"Por que ele 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 nem contém basismos, portanto funciona com um shell POSIX puro.

Se você deseja escrever um software portátil, não há outro sistema de compilação como o autotools. Mas se você não se importa com a portabilidade (ampla), evite as ferramentas automáticas - há uma infinidade de ferramentas de construção rápidas e suficientemente boas.