Fonte da maior otimização de código de máquina

Question

Li em algum lugar que recompilar libc com os sinalizadores -march=native e -mtune=native fornecerá o benefício máximo para programas, em que bibliotecas compartilhadas são usadas em vez de bibliotecas estáticas. Isso é verdade e pode haver algum benefício adicional ao recompilar outros programas?

    

Answer 1

As opções -march=native e -mtune=native garantirão que os binários gerados usem melhor os conjuntos de recursos e o agendamento de processadores disponíveis. Qualquer ganho no desempenho se relacionará com quanto do código do aplicativo pode ser otimizado usando os conjuntos de recursos adicionais do processador. (YMMV) Bibliotecas e binários otimizados devem ser executados mais rapidamente em comparação com binários genéricos, mas quanto é difícil quantificar sem testar. Assim, a resposta curta é sim, pode haver um ganho de desempenho recompilando seus aplicativos com otimizações de CPU, no entanto, manter suas próprias compilações otimizadas e acompanhar atualizações de segurança, etc., provavelmente será um pesadelo.

Mais informações sobre GCC 4.4.4 Opções de arquitetura i386 e amd64 aqui.

    

Answer 2

Não há respostas curtas e fáceis.

1.

Existem muitos parâmetros como cache de código / tamanho do pipeline, diferença entre velocidade do cache e velocidade da memória principal, tamanho do código com "-Os" vs "-O2", "-O3", tamanho do código usando alguns genéricos "march = X / mtune = Y "configurações vs" = nativo ".

Quando mais código cabe no cache, esse ganho de desempenho pode superar algumas outras otimizações. Algumas otimizações aumentam o tamanho do código ...

Se mais código se encaixa no cache, mais código de diferentes tarefas em execução em ajustes paralelos no cache, isso pode ser um aspecto desejado também ...

Será preciso muita pesquisa para fornecer uma resposta exaustiva.

2.

O uso de diferentes flags e opções do compilador pode desencadear diferentes erros e erros de comportamento.

Então, recompilar uma parte central como libc ou até mesmo toda a distribuição tornará seus relatórios de erros inutilizáveis para outros, eles simplesmente não serão capazes de reproduzir seus problemas facilmente. Sua configuração se transforma em uma ilha solitária ...

3.

O aspecto social: Se você não otimizar partes de sua distribuição, os relatórios de erros de suas instalações podem ser reproduzidos pelos mantenedores e o envio de relatórios de erros ajudará a evoluir essa distribuição.

4.

E, provavelmente, o ganho de velocidade não vale as semanas de recompilação (se otimizar não apenas a libc) e se afastar do mainstream.

...

Se você tiver problemas de velocidade para resolver, um sistema mais rápido provavelmente é a solução eficiente.

    

Answer 3

Existem benefícios de desempenho, mas eles são pequenos o suficiente para que você não os perceba, a menos que os compare uns contra os outros. E como o yeti escreveu, há muito mais variáveis que afetam a velocidade. Em geral, não vale a pena criar versões personalizadas de bibliotecas individuais se você estiver na distribuição binária, pois o ônus de manter essa biblioteca atualizada cairá sobre você e será fácil esquecer de atualizá-la.

Alguns programas podem se beneficiar mais que outros. Especialmente programas pesados como o folding @ home ou similar, a mineração cryptocoin, criptografia, codificação de mídia. Também ajudará na decodificação de mídia, mas as coisas mais importantes, como MMX, AVX e similares, serão compiladas independentemente de seu -march , por isso é provável que você não perceba a diferença de assistir a filmes. O áudio em tempo real (como o JACK), por outro lado, pode ser beneficiado, pois os menores atrasos afetam a qualidade do som. Estes também são menos importantes para atualizar imediatamente caso uma vulnerabilidade seja detectada em comparação com bibliotecas básicas como libc, uma vez que você pode simplesmente não usá-las até ter feito o upgrade.

Se estiver interessado, tente distribuição baseada em código-fonte , onde tudo será compilado com sinalizadores de sua escolha. O código compila muito rápido em processadores contemporâneos, portanto não é tão doloroso quanto antes. O Gentoo é o mais usado deles.

Além disso, você pode brincar com muitos parâmetros que provavelmente afetam o desempenho mais do que o código fonte -march via / sys filesystem. Por exemplo, /sys/block/sd?/queue/ hospeda muitas configurações do agendador, o que pode afetar muito o desempenho geral. Eu mudei de CFQ para prazo e melhorou o desempenho interativo noticably na minha carga de trabalho específica. Deve-se dizer que CFQ tem um monte de configurações que eu poderia ter ajustado para o meu gosto também.

Outro 'tesouro' é /proc/sys/ . Por exemplo, ajuste /proc/sys/vm/swappiness para alterar a rapidez com que a memória é liberada movendo coisas antigas para swap. A Red Hat tem um bom manual para os parâmetros.

EDIT: Adicionado alguns exemplos de programas com maior probabilidade de se beneficiarem de -march