On Jan 6, 2008 10:13 AM, Jean Everson Martina <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > >> On Wed, 2 Jan 2008 00:23:21 -0200 > >> "Joao Rocha Braga Filho" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] > >> 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." [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.goffredo.eti.br ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
