É possível acelerar ./configure?


29

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


4
É ridículo e uma pena que não haja boas ferramentas de construção. Todos os que existem existem apenas devido à inércia. Construir binários é uma coisa tão complicada e imprevisível.
Matt Joiner

Ele faz os testes sequencialmente, porque seria um pesadelo descobrir como fazer o paralelismo no sistema específico em que está sendo executado.
Simon Richter

Respostas:


13

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.

2
Você poderia explicar um pouco mais por que makepode ser paralelo, mas configureou autoconfnão?
Netvope

Parece que tenho alguns problemas de desempenho com o shell. Correr sh -c "echo $i" > /dev/null1000 vezes leva cerca de 10s neste sistema, mas apenas 1-2s nos meus outros sistemas.
netvope

1
O GNU make usa código C bastante complicado para iniciar e gerenciar vários processos. Os scripts de configuração são gravados no shell Bourne portátil. Seria possível, mas provavelmente muito difícil.
Peter Eisentraut

4
Classificar as dependências entre os configuretestes é na verdade uma operação de baixa complexidade (classificação topológica) e foi resolvida nos primeiros dias da computação. O verdadeiro problema é que ninguém se preocupou em adicionar o código ao autoconf para fazer isso e o fato de muitos programadores modificarem manualmente os arquivos gerados. Todo o sistema deve ser renovado para que a configuração não seja mais feita por um script de shell, mas por um binário residente lendo arquivos de metadados.
billc.cn

1
Por favor, adicione uma referência à discussão mencionada na lista de discussão (um link para o arquivo).
Karl Richter

3

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.


1
Infelizmente, parece que os SSDs não ajudam muito. Tentei executar ./configurerepetidamente, mas as execuções subsequentes demoram quase o tempo que a primeira. Como há muita memória livre no sistema, acho que o sistema está executando os compiladores e bibliotecas do cache de memória sem acessar o disco.
Netvope 19/06/11

1
se você tentou executar ./configure repetidamente (e se for feito pelo autoconf), todos os resultados devem ser armazenados em cache e devem funcionar muito bem. Você pode postar o script configure para que possamos dar uma olhada, se quiser mais ajuda. Eu tenho certeza que há uma abundância de guru aqui #
1916

Na verdade, eu o limpei entre as execuções ( ./configureestá sempre executando em uma árvore de origem recém-extraída). Vou adicionar mais detalhes no post original (o espaço é limitado aqui).
Netvope

Acabei de testar sem limpar a pasta (ou seja, executando ./configureimediatamente após o outro ./configure) e as duas execuções levam aproximadamente a mesma quantidade de tempo. Isso significa que o cache não está funcionando provavelmente no meu sistema?
Netvope

Vou buscar o coreutils e tentar configurar quando tiver tempo. Fique ligado.
bubu

3

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.


3

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.


2
Há uma boa razão para usar essas ferramentas: elas são maduras e mantêm o controle de muitos pequenos detalhes. Eu acho que o Linux não estaria em uma ótima posição no mundo incorporado se você não pudesse simplesmente apontar o script configure para o seu compilador cruzado e fazê-lo funcionar 90% do tempo.
Simon Richter

2

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

1
Obrigado, mas eu já estava compilando em / dev / shm que é um tmpfs :-)
netvope

0

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.