[FUG-BR] [Off-Toppic] GCC

[Joao Rocha Braga Filho]

On Jan 6, 2008 10:13 AM, Jean Everson Martina <everson at inf.ufsc.br> wrote:
> Bom pra dar meus dois centavos.
>
>     Eu ja fiz este tipo de analise ha uns 2 anos num projeto de
> criptoanálise, onde nós tinhamos que fazer simulações de cifragem de
> 2^48 vezes do AES por exemplo. Essa historia de colocar a função no meio
> do codigo economiza pelo menos 2 intruções. Tem outra opções legais,
> tais como --funrolloops, que desdobra todos os loops que tem o controle
> do numero de interações decidíveis em tempo de compilação. O tamanho do
> executavel aumenta consideravelmente, mas quando o tempo de carga é
> infimo quando comparado ao da execução, então carregar 20k ou 2M
> realmente não faz diferença. No nosso caso conseguiamos retirar mais de
> 2^100 instruções executaveis de um codigo de 1500 linhas so usando as
> otimizações do GCC.
>     Ainda assim usando -O3 e um saco de outras opções, ainda dava pra
> otimizar qualquer coisa na mão :)

Acredito que sim. Como acredito que nas versões atuais possa ter menos
coisa que possa ser otimizada à mão.

E por mais engraçado que pareça, tem vezes que um loop desenrolado
(unrolloops) pode ser mais lento que um não desenrolado, pois o desempenho
na execução do programa não depende só de quantas instruções ele executa,
mas também de onde elas vem. POr exemplo, o processador Pentium 4 tem
uma cache de 12 K de instuções já decodificadas. Grandes extensões de
código podem implicar em muito acesso à memória, ou à caches secundárias.

Mas loops desenrolados também eliminam instruções de teste e mecanismos
de predição de jumps. Talvez cada caso seja um caso.

Sim... Já brinquei muito com otimização de programas, e, em geral, os meus
programas consomem muito pouca CPU e memória.


João Rocha.


>
>
> Jean Martina
>
>
>
> Joao Rocha Braga Filho wrote:
> > On Jan 2, 2008 10:01 AM, Ricardo Nabinger Sanchez <rnsanchez at gmail.com> wrote:
> >
> >> On Wed, 2 Jan 2008 00:23:21 -0200
> >> "Joao Rocha Braga Filho" <goffredo at gmail.com> wrote:
> >>
> >>
> >>> Alguém já olhou a geração de código de um gcc atual?
> >>>
> >> Sim.
> >>
> >>
> >>> Com a opção -O3, se uma função for "static" e só é chamada uma
> >>> vez, ele some com ela introduzindo o código no local de chamada.
> >>>
> >> static em funções diz ao compilador que ela é local àquela unidade de
> >> compilação (.o), e portanto o símbolo gerado não será visível.  Sendo
> >>
> >
> > Sim.. e eu contava com a possibilidade da função sumir, mas ele sumiu
> > até mesmo  com os símbolos e integrou até mesmo as funções grandes.
> >
> >
> >> assim, não tem porque o compilador criar uma entrada para ele na .symtab
> >> se ninguém vai usar.  Em outras palavras, isto está OK.  :)
> >>
> >>
> >>> E tem mais. Uma printf para só imprimir uma string é trocada por
> >>> uma puts, e com passagem de parâmetros por registradores, e não
> >>> por pilha. Ele faz isto em muitas outras coisas. Eu já tinha ficado
> >>> meio assombrado com o que ele fazia a alguns anos atrás, mas o
> >>> pessoal ainda deu mais um capricho agora.
> >>>
> >> Esse e mais um monte de truques.
> >>
> >
> > Como a printf com passagem de parâmetros por registrador. :^)
> >
> >
> >>> Eu descobri isto parando o compilador a etapa do assembler, com
> >>> a opção -S. Estou usando a versão AMD64.
> >>>
> >> Tem uma outra onde tu pode ver a saída de cada estágio, inclusive os de
> >> otimização.  Gera um montão de arquivos, alguns que não tem como
> >> entender sem conhecer a estrutura interna do GCC, mas interessantes
> >> mesmo assim.
> >>
> >
> > Eu aprendi assembler do PDP 11/70 assim, com a opção -S. Comecei com
> > o FORTRAN, e depois, quando comecei aprender C, fiz o mesmo. Ei ainda
> > usava o adb, assembler debuger. Tinha cegado ao ponto de olhar para o
> > assembler e ver na minha mente o código que o gerou. Mas com o nível de
> > otimização atual isto é muito difícil.
> >
> > Lá pela versão 2.x o gcc já modificava loops por conta própria, e muitas
> > outras coisas. Se você fizesse um loop de 0 a 10, e a variável de controle
> > não fosse usada dentro do loop, ele invertia por conta própria, pois é mais
> > fácil testar se é zero do que qualquer outra coisa.
> >
> > Eu achei uma pena a AMD não ter feito o processador de 64 bits dela
> > ortogonal, como os PDP 11, os VAX e os Motorola 68K. Seria muito bom
> > de entender o código assembler e geraria menos código.
> >
> >
> > João Rocha.
> >
> >
> >
> >> --
> >> Ricardo Nabinger Sanchez                   rnsanchez at gmail.com
> >> Powered by FreeBSD                  http://rnsanchez.wait4.org
> >>
> >>   "Left to themselves, things tend to go from bad to worse."
> >>
> >> -------------------------
> >> Histórico: http://www.fug.com.br/historico/html/freebsd/
> >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> >>
> >>
> >
> >
> >
> >
>
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>



-- 
"Sempre se apanha mais com as menores besteiras. Experiência própria."

goffredo at goffredo.eti.br
goffredo at gmail.com
http://www.goffredo.eti.br