Senhores, estou num mato sem cachorro!
Como várias cabeças pensam mais e melhor do que uma, vou colocar aqui o que descobri até o momento sobre a questão do motivo de se colocar P4 na compilação do kernel ser melhor que Core2! Se o HQ achar que foi "fuga ao tema" eu apago a "redação" que vem a seguir!
Vocês devem ter lido que eu mudei para o Kubuntu 10.10, daí achei que ele poderia usar o GCC 4.5.1, mudei par ao GCC 4.5.1 e coloquei para compilar a arquitetura do processador Core2 para o i7 e Atom para o Atom! Tudo bonitnho como manda o figurino da documentação do GCC quanto a arquitetura dos processadores! Vejam:
http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-OptionsApesar de ser para o 4.5.2 essa parte da documentação não mudou nada em relação ao 4.5.1! De qualquer maneira, o resultado da compilação, em comparação quando uso P4 foi horrível com o i7 e lastimável com o Atom!
Pois bem, a coisa começa a fazer água exatamente aí, na documentação do GCC, quer dizer, não é bem assim, mas depois vocês vão entender! Segundo ela, na teoria, deveríamos ter melhor desempenho ao se colocar a arquitetura correta do processador na hora de compilar! A coisa é tão séria que desde a versão 4.3 (se não estou enganado) existe uma opção de "native" se você não souber a arquitetura correta do seu processador, com essa opção ele mesmo verifica a arquitetura do procecessador e depois faz tudo o que deve! Uma verdadeira mão na roda! Mesmo assim eles não removeram a opção de você mesmo escolher a arquitetura do seu processador!
Até aí tudo claro! Está tudo lá, da documentação do GCC! Tudo muito bom, tudo muito bem, chega na hora de compilar e......
E que alguns "detalhes" me passaram batido! Inconformado com esse fato da arquitetura do processador, fui ler a documentação do Gentoo e do Arch Linux em busca de respostas! Elas são distros feitas para serem compiladas, ao contrário do Debian/Ubuntu que são distros binárias! Eu sei, eu sei, tem o apt-build, mas não chega perto das opções que o Gentoo e Arch Linux têm de compilação! Vou ficar só na parte que nos toca dessa redação, a arquitetura do processador!
Vamos lá! O Gentoo e o Arch Linux possuem um arquivo na pasta /etc chamado make.conf! Esse arquivo, como o nome já diz, contém as configurações de compilação da distro! Pois bem, o Debian/Ubuntu não possuem tal arquivo! É aí que o caldo começa entornar! Dentro deste arquivo você pode dar instruções específicas para o
C e para o
C++ na hora de compilar! Essas opções são passadas pelo CFLAGS (para o
C) e o CXXFLAGS (para o
C++)! Que usa o apt-build vai dizer que o CFLAGS está lá no apt-build.conf! Sim está, mas vamos continuando....
Aqui vou colocar como exemplo, um pequeno pedaço do make.conf do Gentoo:
CFLAGS="-march=athlon64 -O2 -pipe"
CXXFLAGS="${CFLAGS}"
Como podem ver, o CXXFLAGS nada mais é do que uma repetição do CFLAGS, ou seja, o que você colocar no CFLAGS, vai valer para o CXXFLAGS em relação as opções de otimização do GCC! Você ainda pode escolher colocar opções diferentes, mas isso é outro assunto!
Quem já olhou o arquivo do apt-build.conf viu que o padrão, se você não mudar nada, o CFLAGS usa a opção "mtune" ao invés da "march" do Gentoo! E isso não é de graça! E é aí onde está o "problema"! Vou explicar melhor!
Ao utilizar a opção "mtune" implica que
o código a ser compilado vai ser direcionado para otimizações da arquitetura do processador escolhido! Prestaram atenção no negrito anterior?
Tá, quando você usa a opção "march" ele
gera instruções específicas para o tipo de processador selecionado! Prestaram atenção em mais esse negrito né?
Por questões de compatibilidade e segurança, a documentação do GCC chama sua atenção quanto a isso também, ao se usar o "mtune" vai fazer com que ele otimize o código para o processador, mas ele não usa as otimizações das instruções do processador! Ao se utilizar a opção "march", ele usa as otimizações das instruções do processador! E mais, ao se usar a opção "march" implica em dizer que o mtune vai seguir o "march", mas o contrário não é verdadeiro!
Embolou o meio de campo?
Fica fácil entender com um exemplo!
Se eu colocar
mtune = core2, quer dizer que o código a ser compilado vai usar otimizações para o Core2, mas por compatibilidade e segurança ele não vai usar instruções específicas, vai usar instruções genéricas nas instruções! Aí vai depender do desenvolvedor, ele pode colocar a i386 se quiser nas intruções, mas ao que tudo indica, eles usam a nocona (que foi o primeiro pentium 4 com instruções 64bits - lembre-se, eu uso 64bits!). A nocona possui: Pentium4 com extensões 64-bit , MMX, SSE, SSE2 e SSE3!
Se eu usar
march = Core2, quer dizer que ele vai usar as instruções específicas do Core2 ( extensões 64-bit, MMX, SSE, SSE2, SSE3 e SSSE3), ou seja, se o seu processador não suportar tais instruções, o kernel não sobe!!! Ao usar o march = Core2 implica em dizer que o mtune também será Core2! Passaram o cartão agora?
mtune = código otimizado, sem instruções do processador otimizadas!
march = código e instruções do processador otimizadas de acordo com a arquitetura do processador selecionada!
Eu só tive essa luz no fim do túnel porque eu achei um fórum de programadores em C e um Canadense deu uma explicação matadora que eu não tinha lido em canto nenhum ainda!
Leiam o que o cyberfish diz:
mtune=... does NOT affect the instruction sets used, or machines the executable is run on.
For that (eg, enabling SSE), you'll need march=....
If you do march=core2 for example (on a new GCC), it will use all the instruction sets available to Core 2 CPUs. march=x also sets mtune=x. The executable won't run on older CPUs.
If you ONLY use mtune=core2, it will generate code that runs the best on a Core 2, but will still only use instructions available to all x86 CPUs (eg, no SSE), hence it will still run on old CPUs, just a little slower.
As a real world example, I think a few years ago some Linux distribution decides to use -march=pentium3 -mtune=pentium4, or something like that. That means, the code is guaranteed to run on a P3, but optimized for a P4, since they predict most people will be running for a P4.
If you don't use any flag, GCC will assume -march=i386 (lowest x86).
If you want GCC to use all instruction sets on your CPU, and optimize for your CPU (because, for example, the code will only be run on your machine), you can do -march=native (which also sets mtune=native). Only available in newer GCC (it was introduced in 4.3 or 4.4 I THINK).
-m32 and -m64 are only for generating 32-bit code on a 64-bit machine, or generating 64-bit code on a 32-bit machine, respectively. GCC defaults to 32-bit on 32-bit, and 64-bit on 64-bit.
O tópico é este aqui:
http://cboard.cprogramming.com/c-programming/127502-%5Bgcc%5D-compiling-generic-x86-architecture-2.htmlE quanto ao kernel? Tudo indica que ao usar o menuconfig estamos alterando apenas o mtune e não o march!!!! Pois o sistema já foi construído! É uma distro binária! Com o gentoo e o arch linux não, o "normal" deles é você construir o sistema inteiro! Eu estou dizendo tudo indica porque não acho documentação nenhuma e ninguém que saiba responder sobre isso! Estou deduzindo! Ao usar o P4 no processador, casa com a compilação do sistema daí o sistema fica muito mais rápido!
O mais perto que achei para alterar foi o makefile que vem com o kernel vanilla! No 2.6.34 está logo no início:
HOSTCC = gcc
HOSTCXX = g++
HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer
HOSTCXXFLAGS = -O2
Tem um outro doido varrido do Fórum gringo que diz que mexeu aí e deu certo!
Vejam aqui:
http://ubuntuforums.org/showthread.php?t=1579505Eu ainda não testei!
E agora pessoal? O que acham? Eu acho que o Canadense tem razão e que o camarada do fórum gringo chutou! Beta testers para essa possível solução?
