Compilando GNU / Linux com otimização -O3

-O3 tem várias desvantagens:

1. Em primeiro lugar, geralmente produz código mais lento do que -O2 ou -Os. Às vezes, ele produz código mais longo devido ao desenrolamento do loop, que pode ser, na verdade, mais lento devido ao pior desempenho do cache do código.
2. Como foi dito, às vezes produz um código errado. Pode ser devido a um erro na otimização ou no código (como ignorar o aliasing estrito). Como o código do kernel às vezes é e às vezes tem que ser 'inteligente', eu diria que é possível que algum desenvolvedor do kernel tenha cometido algum erro. Eu experimentei vários problemas estranhos, como travamento de utilitários de espaço do usuário, quando compilei o kernel com o gcc 4.5, que naquele ponto estava estável. Eu ainda uso o gcc 4.4 para kernel e vários utilitários de espaço do usuário selecionados devido a vários bugs. O mesmo pode se aplicar a -O3.
3. Eu não acho que isso oferece muitos benefícios para o kernel Linux. O kernel não faz cálculos pesados ​​e em locais que faz, é otimizado com Assembly. -O3 flag irá não alterar o custo de comutação de contexto ou velocidade de E/S. Não acho que algo como <0,1% de aumento de velocidade do desempenho geral valha a pena.

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

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

Nos últimos 10 anos, tenho executado vários sistemas Gentoo com mais de 1000 pacotes usando -O3 -march=native globalmente e ainda não se deparou com nenhum desses problemas de estabilidade míticos que -O3 é suposto ter. Os benchmarks de aplicativos que usam muita CPU (como aplicativos de matemática/ciências) mostram consistentemente -O3 para produzir código mais rápido, afinal seria inútil se não o fizesse. Para a maioria dos aplicativos de desktop CFLAGS não importa muito, pois eles são IO vinculados, mas é muito importante para as coisas do lado do servidor que são vinculadas à CPU.

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

Embora você possa se safar usando -O3 e outros botões de otimização na maioria dos aplicativos (e isso pode resultar em melhorias de velocidade), eu 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 desempenho de 5% dos subsistemas raid e ext3 compensa travamentos do sistema ou perda potencial de dados e/ou corrupção?

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