Compilando GNU / Linux com otimização -O3

Dizem que a compilação de ferramentas GNU e kernel Linux com a -O3opção de otimização gcc produzirá bugs estranhos e descolados. É verdade? Alguém já tentou ou é apenas uma farsa?

É usado no Gentoo, e eu não notei nada incomum.

-O3 tem várias desvantagens:

1. Primeiro de tudo, muitas vezes produz código mais lento que -O2ou -Os. Às vezes, ele produz código mais longo devido ao desenrolar do loop, que pode ser mais lento devido ao desempenho pior do cache do código.
2. Como foi dito, às vezes produz código errado. Pode ser devido a erro na otimização ou erro no código (como ignorar o aliasing estrito). Como o código do kernel às vezes é e às vezes precisa ser 'inteligente', eu diria que é possível que algum desenvolvedor do kernel tenha cometido algum erro. Eu experimentei vários problemas estranhos, como travar os utilitários do espaço do usuário, quando compilei o kernel com o gcc 4.5, que naquele momento era estável. Eu ainda uso o gcc 4.4 para o kernel e vários utilitários de espaço de usuário selecionados devido a vários bugs. O mesmo pode se aplicar -O3.
3. Eu não acho que ele oferece muitos benefícios para o kernel do Linux. O kernel não faz cálculos pesados ​​e, em alguns locais, é otimizado com montagem. -O3O sinalizador não alterará o custo da alternância de contexto ou a velocidade da E / S. Não acho que algo como uma aceleração <0,1% do desempenho geral valha a pena.

Observe que grandes partes da cadeia de ferramentas (em particular a glibc) não compilam se você alterar os níveis de otimização. O sistema de compilação está configurado para ignorar suas preferências -O para essas seções na maioria das distribuições sãs.

Simplificando, certas funcionalidades fundamentais da biblioteca e do sistema operacional dependem do código que está realmente fazendo o que diz, e não do que seria mais rápido em muitos casos. -fgcse-after-reload em particular (ativado por -O3) pode causar problemas estranhos.

Nos últimos 10 anos, eu tenho executado vários sistemas Gentoo com mais de 1000 pacotes usando -O3 -march=nativeglobalmente e ainda não encontrei nenhum desses problemas míticos de estabilidade que -O3deveriam ter. Os benchmarks de aplicativos intensivos de CPU (como aplicativos de matemática / ciências) mostram consistentemente -O3produzir código mais rápido, afinal, seria inútil se não o fizessem. De qualquer maneira, para a maioria dos aplicativos de desktop CFLAGS, não importa tanto, pois eles são vinculados à IO, mas isso importa muito para as coisas do lado do servidor vinculadas à CPU.

-O3 usa otimizações agressivas que só são seguras se certas suposições sobre o uso de registros, como os quadros de pilha forem interagidos e a reentrada de funções forem verdadeiras, e não é garantido que essas suposições sejam verdadeiras em alguns códigos como o kernel, especialmente quando a montagem em linha é usado (como em algumas partes de nível muito baixo do kernel e de seus módulos de driver).

Embora você possa usar o -O3 e outros botões de otimização na maioria dos aplicativos (e isso pode resultar em melhorias de velocidade), hesitaria em usar esses ajustes no próprio kernel ou na cadeia de ferramentas necessária para construí-lo (compilador, binutils, etc.)

Pense nisso: um ganho de 5% no desempenho dos subsistemas raid e ext3 vale a pena travar o sistema ou potencial perda de dados e / ou corrupção?

Ajuste todos os botões desejados para a porta do Quake que você está reproduzindo ou os codecs de áudio / vídeo que você usa para copiar sua coleção de DVD para arquivos divx. Você provavelmente verá uma melhoria. Apenas não mexa com o kernel, a menos que você tenha tempo a perder e dados que pode suportar perder.