Planeta Gentoo Linux Brasil

Notei que algumas CFLAGS se comportam melhor no ambiente 64 bits e podem proporcionar, de forma geral, um desempenho maior aos pacotes compilados. As flags são -ftree-vectorize e -ftracer.

A primeira permite fazer a vetorização de loops e a segunda torna as otimizações mais eficientes. Estas flags, em especial a -ftree-vectorize, possuem uma reputação ruim, devido a problemas em sua implementação e seu comportamento em ambientes 32 bits, onde ainda hoje causam problemas isolados.

Entretanto, tudo indica que o cenário no ambiente 64 bits é mais animador, permitindo inclusive o uso delas globalmente, definindo-as no make.conf. O meu atual Gentoo (~amd64) utiliza estas flags mesmo em pacotes problemáticos (ex: Mozilla Firefox) e não apresentou nenhum problema até o momento, sendo que se fosse 32 bits, normalmente eu receberia um Segmentation Fault bem bonito .

Com relação ao desempenho, geralmente leva a ganhos consideráveis, tendo observado algo em torno de 2% em compactadores. Possui efeito negativo em algumas aplicações, como o ffmpeg, mas no Gentoo não é problema, uma vez que nestes casos flags mais agressivas são filtradas.

Concluindo, se você utiliza o Gentoo 64 bits como desktop, seria bastante vantajoso ativar as flags -ftree-vectorize e -ftracer no seu make.conf, mesmo com um risco um pouco maior de encontrar bugs. Lembrando que não recomendo usá-las em ambientes 32 bits ou em arquiteturas diferentes da x86, por ter um histórico considerável de problemas.

O comportamento padrão do GCC pode ser alterado via Specs, que são arquivos contendo as instruções sobre quais flags usar e em que circunstâncias. Você pode olhar a spec padrão do seu GCC com o comando:

# gcc -dumpspecs

Após ler o artigo sobre –as-needed do Gentoo percebi que poderia usar isso para forçar o uso de minhas LDFLAGS, umas vez que alguns pacotes não respeitam aquelas definidas no make.conf. O procedimento é bastante simples:

# export SPECSFILE=$(dirname "$(gcc -print-libgcc-file-name)")/ldflags.specs
# export CURRPROFILE=/etc/env.d/gcc/$(gcc-config -c)
# gcc -dumpspecs | sed -e '/link:/,+1 s:--eh-frame-hdr:\0 *SUASFLAGS*:' > "$SPECSFILE"
# sed "${CURRPROFILE}" -e '1i\GCC_SPECS='$SPECSFILE > "${CURRPROFILE}-ldflags"
# gcc-config "$(basename "${CURRPROFILE}")-ldflags"
# source /etc/profile


No caso, basta substituir o *SUASFLAGS* pelas suas LDFLAGS, no meu caso (que uso -O1 –as-needed –hash-style=gnu –sort-common) ficaria assim:

# gcc -dumpspecs | sed -e '/link:/,+1 s:--eh-frame-hdr:\0 -O1 --as-needed --hash-style=gnu --sort-common:' > "$SPECSFILE"

Esta dica deve ser usada apenas por usuários avançados e que sabem o que estão fazendo. Como visto no passos acima, basta usar o gcc-config para alternar entre os diferentes specs ou mesmo o GCC vanilla.

CHM (Microsoft Compiled HTML Help) é um formato em que páginas HTML são agrupadas em um único arquivo, bastante usado em arquivos de ajuda no Windows e em alguns ebooks. Eu prefiro os PDFs ou mesmo DJVUs para os meus ebooks, mas alguns só são encontrados em formato .chm, por isso tive que encontrar uma solução para ler estes arquivos no GNU/Linux. O programa eleito foi o xCHM, um leitor escrito em wxGTK e chmlib, funciona muito bem com os ebooks que testei. O Okular do KDE suporta chm e usa a mesma chmlib, entretanto, ele é bem mais lento e instável para lidar com estes ebooks, por isso acabei optando pelo xCHM, mesmo sendo um usuário do KDE.

O xCHM está disponível em praticamente todas as grandes distribuições e pode ser instalado facilmente. No Gentoo Linux, ele está na árvore oficial e pode ser instalado com o comando abaixo:

# emerge -av xchm

Espero que a dica seja útil, pois pra mim deu um trabalho e tanto achar um leitor de chm que realmente faz o que promete.

• Site oficial: http://xchm.sourceforge.net/

Hoje compilei o Mozilla Firefox 3.7 alpha4 para ver como estão os progressos com a engine javascript e o resultado foi bastante animador, segundo o benchmark do SunSpider, está 2x mais rápida que a versão atual 3.6. Também fiz a comparação com uma build atual do Chromium e podemos ver que o Firefox está cada vez mais próximo do concorrente mais forte em termos de engine javascript.

• Firefox 3.6.2 vs Firefox 3.7 alpha4
• Firefox 3.7 alpha4 vs Chromium 5.0.360.0