Pessoal, continuando aqui com minhas compilações com o Omnislash 2.6.34, fiz uma nova compilação com as dicas do Gentoo para o Buble Bee!
A linha em especial do Makefile do Kernel ficou assim:
TCC = gcc
HOSTCXX = g++
HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -pipe -march=native -mcx16 -msahf -mmovbe --param l1-cache-size=24 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=generic -fstack-protector
HOSTCXXFLAGS = -O2Notem que eu preferi não colocar outras instruções além da saída do comando:
cc -march=native -E -v - </dev/null 2>&1 | grep cc1A saída deste comando para o meu Atom 330 foi:
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/cc1 -E -quiet -v - -D_FORTIFY_SOURCE=2 -march=atom -mcx16 -msahf -mmovbe --param l1-cache-size=24 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=atom -fstack-protectorComo podem ver eu mudei o -march para Native e o -mtune para Generic, também seguindo a dica do Gentoo!
Nos outros arquivos troquei todos os -march por native e -mtune para generic, usei o GCC 4.4.5 no Lubuntu 10.10 64bits!
Nas opções "gerais" do menuconfig do Kernel eu usei: BFS + BFQ + Preempt + 1000Mhz + Ondemand!
O resultado no geral foi o seguinte:
Definitivamente, para quem gosta de resposta imediata desde a primeira vez que você chama programas, a opção P4 (para quem compila em 64bits) do menuconfig para o processador é melhor! Contudo, fiquei realmente impressionado ao ver a carga no processador diminuir quase pela metade quando fico com mais de 15 abas abertas em qualquer navegador aqui! Com o P4 ele fica com um processador sempre em 25-27% e os outros "3" com 12-16%! Quando fiz uso das opções que mostro logo acima, a carga de um deles fica sempre em 10-12% e os outros "3" em 6-9%! É uma queda significativa para um "caroço de azeitona"!
Isso é fantástico para que tem algum Atom em Netbooks! Vai economizar muito mais bateria, e olha que usei 1000Mhz!
O resultado final é que a carga que posso colocar sobre o sistema aumentou antes dele dar" Lag" ou travar! Ele não abre os programas tão rápido da primeira vez como com o P4, mas abre mais rápido da segunda vez! O carregamento das fotos (tanto para abrir como para pré-visualizar a foto em ícone) melhorou consideravelmente! O VirtualBox também melhorou muito! Carregamento de vídeos e pré-visualização deles também melhoraram!
Como também já testei o 2.6.38 aqui, tanto do aptosid como o do Lineduc, posso dizer que a distribuição dos processos realmente melhorou demais no 2.6.38, está melhor que o 2.6.34 Omnislash! Mas com toda a compilação feita "a mão" para o Buble Bee, ele se mostra mais rápido no geral, só não tem a fluidez que o 2.6.38 tem!
Gunss, quanto ao
fstack-protector, o que andei pesquisando é que ele não deve melhorar o desempenho do sistema, mas sim sua segurança! Ele serve para evitar ataques na memória! O interessante é que num documento do linuxfromscratch, ele não recomenda usar "apenas" a opção
fstack-protector, existem 3 opções! É como se essa opção fosse a mais fraca em termos de segurança! Também avisa que se usar a opção -03 na compilação, são esperados problemas com programas escritos em Python!
Sabe que eu não lembro de habilitar a opção CONFIG_CC_STACKPROTECTOR no config do kernel!
Resumindo, se não for para atrapalhar acho que vou deixar essa opção na linha do Makefile!
Então acho que você poderia tentar usar as opções "básicas" da saída do comando
cc -march=native -E -v - </dev/null 2>&1 | grep cc1, sem os -mmx e -SSE... da vida! E mantém os native no resto já que você está usando o GCC 4.6 né?
Obs: Putz, lendo mais aqui da documentação do linuxfromscratch, tería que deixar a opção
-D_FORTIFY_SOURCE=2 na linha do make file por conta do
fstack-protector! E agora?
O próximo teste será com o i7! Vou usar o kernel compilado com as opções acima no Buble Bee no resto da semana para "sentir" mais como ele desempenha!
