O que é o 'register'?
serve para tentar forçar a variavel a ser armazenada nos registradores, tendo entao acesso mais rapido.
Em str_chr.c (e alguns outros arquivos .c também)...
O que traz de melhor o uso de:
for (;;) {
if (!*t) break; if (*t == ch) break; ++t;
if (!*t) break; if (*t == ch) break; ++t;
if (!*t) break; if (*t == ch) break; ++t;
if (!*t) break; if (*t == ch) break; ++t;
}
Em vez de:
for (;;){
if (!*t) break; if (*t == ch) break; ++t;
}
Está sem indentação porque o PACA comeu minha indentação.
O que traz de melhor o uso de:
for (;;) {
if (!*t) break; if (*t == ch) break; ++t;
if (!*t) break; if (*t == ch) break; ++t;
if (!*t) break; if (*t == ch) break; ++t;
if (!*t) break; if (*t == ch) break; ++t;
}
Em vez de:
for (;;){
if (!*t) break; if (*t == ch) break; ++t;
}
Está sem indentação porque o PACA comeu minha indentação.
Há algum tempo fiquei curioso, compilei com gcc -S o str_chr.c e um código cujo for era simplesmente
for (t = s; *t && *t != ch ; t++);
O gcc gera, para cada arquivo, um .s contendo o código de assembler correspondente. O código fica bem menor; infelizmente, não conheço o assembler tão bem a ponto de comparar qualidade.
Sobrou a possibilidade de ele ter feito à mão uma otimização conhecida como "loop unrolling". Ela consiste em executar várias instâncias de um loop sequencialmente, dentro do loop. Dependendo do processador, isso pode resultar numa otimização sutil. Isso porque muitos processadores vão lendo instruções da memória antes de serem executadas (o jargão é "prefetching").
No fim de um loop (for, while,...) é feito um teste, e, dependendo do resultado, é efetuado um pulo no código para o início do loop. Se o loop tem muitas iterações, são muitos pulos. Acontece que esse pulo faz com que todo o prefetching se perca, e dá um atraso até o processador ler as próximas instruções.
Algumas dessas otimizações são feitas por compiladores espertos. Eu não recomendo que se faça isso à mão sem ter resultados experimentais que mostrem que os ganhos são significativos. O Dan Bernstein, autor do qmail, é um perfeccionista que deve ter feito os testes dentro do contexto do programa dele.
for (t = s; *t && *t != ch ; t++);
O gcc gera, para cada arquivo, um .s contendo o código de assembler correspondente. O código fica bem menor; infelizmente, não conheço o assembler tão bem a ponto de comparar qualidade.
Sobrou a possibilidade de ele ter feito à mão uma otimização conhecida como "loop unrolling". Ela consiste em executar várias instâncias de um loop sequencialmente, dentro do loop. Dependendo do processador, isso pode resultar numa otimização sutil. Isso porque muitos processadores vão lendo instruções da memória antes de serem executadas (o jargão é "prefetching").
No fim de um loop (for, while,...) é feito um teste, e, dependendo do resultado, é efetuado um pulo no código para o início do loop. Se o loop tem muitas iterações, são muitos pulos. Acontece que esse pulo faz com que todo o prefetching se perca, e dá um atraso até o processador ler as próximas instruções.
Algumas dessas otimizações são feitas por compiladores espertos. Eu não recomendo que se faça isso à mão sem ter resultados experimentais que mostrem que os ganhos são significativos. O Dan Bernstein, autor do qmail, é um perfeccionista que deve ter feito os testes dentro do contexto do programa dele.