Lançado o GCC 4.3.0
“O recém-lançado GCC 4.3.0 contém substanciais novas funcionalidades não disponíveis nas versões anteriores.
O GCC foi lançado por Richard Stallman em 1985 a partir de um compilador de Pastel, e alcançou sua versão 1.0 em 1987.”
Enviado por Gogo Yubari – referência (gcc.gnu.org).
• Publicado por Augusto Campos em
2008-03-12
@brlinuxblog
Feed RSS
O “release” não fala em otimização para processadores dual core ou acima. Enquanto isso não for adicionado, esse tipo de processador vai ser sub-utilizado.
“The -m386, -m486, -mpentium and -mpentiumpro tuning options have been removed because they were deprecated for more than 3 GCC major releases. Use -mtune=i386, -mtune=i486, -mtune=pentium or -mtune=pentiumpro as a replacement.”
Não exatamente no contexto do compilador, mas alguns algoritmos da STL foram otimizados para rodarem em paralelo, portanto aproveitam o paralelismo de processadores de vários núcleos:
“An experimental parallel mode has been added. This is a parallel implementation of many C++ Standard library algorithms, like std::accumulate, std::for_each, std::transform, or std::sort, to give but four examples. These algorithms can be substituted for the normal (sequential) libstdc++ algorithms on a piecemeal basis, or all existing algorithms can be transformed via the -D_GLIBCXX_PARALLEL macro.”
http://gcc.gnu.org/gcc-4.3/changes.html
Pastel?
É isso mesmo?
Acho que ele quis dizer Pascal, deve ter se confundido na hora de digitar ;-)
Parece que não, o compilador se chama Pastel mesmo:
The Short History of GCC development
Projeto GNU por Richard Stalmann
O pior é que é Pastel mesmo. :P
Essa é uma linguagem derivada do Pascal.
“O “release” não fala em otimização para processadores dual core ou acima.”
Fala sim:
“IA-32/x86-64
* Tuning for Intel Core 2 processors is available via -mtune=core2 and -march=core2.
* Tuning for AMD Geode processors is available via -mtune=geode and -march=geode.”
Meu, grandishmerda se o Stallman iniciou o gcc a século atrás, mas duvido que tenha uma linha de código dele ainda no código. O cara é importante, mas não precisam ficar toda a hora pagando pau pro cara. Odeio fanboys.
Odeio fanboys é por isso que me odeio!!!
zer0c00l é marca registrada, babe.
Yeh Baby
O povo passou a faca no suporte a binários formato a.out na versão do Linux. ELF rulez!
E parece que o GCJ tá mais redondo:
“gcj now uses the Eclipse Java compiler for its Java parsing needs. This enables the use of all 1.5 language features, and fixes most existing front end bugs.”
Meu, grandishmerda se o Stallman iniciou o gcc a século atrás, mas duvido que tenha uma linha de código dele ainda no código.<blockquote
Essa é uma opinião bastante depreciativa, mas mesmo que não haja código de 1985 no programa de hoje, o principal está lá: o conceito de construção do software, afinal o GCC desde o princípio trabalhou com o conceito de compilador (C, C++…), Assembler e linker independentes.
“O “release” não fala em otimização para processadores dual core ou acima. Enquanto isso não for adicionado, esse tipo de processador vai ser sub-utilizado.”
Quem tem que otimizar software para rodar em dual core (ou quad ou quantos cores forem) não é o compilador, mas o programador. Se o software não foi desenvolvido com múltiplas threads, o compilador não vai fazer nenhum milagre.
É claro que no final das contas, quem vai definir como o software vai se portar é o programador. Mas sem a ajuda do compilador, meu caro, ele nunca vai conseguir fazer o milagre.
Veja o Kernel Linux. Nos últimos lançamentos, há opção para core2 da INTEL, mas se o compilador não tiver essa “graça”, o que vai acontecer?
1. Vai ser utilizado plenamente?
2. Vai ser sub-utilizado?
3. Vai travar?
“Quem tem que otimizar software para rodar em dual core (ou quad ou quantos cores forem) não é o compilador, mas o programador. Se o software não foi desenvolvido com múltiplas threads, o compilador não vai fazer nenhum milagre”
Errado. Vários compiladores conseguem identificar códigos que podem ser executados em paralelo e gerar o código de máquina otimizado para isso. O compilador c/c++ da Intel por exemplo, já faz isso. Até o da Borland faz.
Marcos Alexandre, o código não pode ser executado no outro processador se não existir outra thread, ou processo. É claro que um compilador pode detectar um código que pode ser executado em outra thread, mas mesmo quando o programador faz algo multi-thread já é complexo de controlar a sincronização entre as threads, quanto mais um compilador adivinhar que um pedaço de código pode ser outra thread, e adicionar uns forks, e semáforos e etc no meio do código.
É claro, existem processadores que executam mais de uma instrução ao mesmo tempo num único processador, e nesse caso, o compilador pode sim otimizar o código. Mas no caso da arquitetura ia-32 (x86), não é bem assim. E quem tem controle dos processadores não é o compilador, mas o Sistema Operacional, e ele é o único cara que vai dizer quem vai rodar onde, e sem duas threads, não tem como um programa utilizar os dois processadores simultaneamente. Pelo menos não por enquanto.