O que é mais rápido: if (bool) ou if (int)?

Qual valor é melhor usar? Boolean true or Integer 1?

O tópico acima me fez fazer alguns experimentos com boole intem ifcondições. Então, apenas por curiosidade, escrevi este programa:

int f(int i) 
{
    if ( i ) return 99;   //if(int)
    else  return -99;
}
int g(bool b)
{
    if ( b ) return 99;   //if(bool)
    else  return -99;
}
int main(){}

g++ intbool.cpp -S gera código ASM para cada função da seguinte maneira:

• código ASM para f(int)

  __Z1fi:
     LFB0:
           pushl  %ebp
     LCFI0:
            movl  %esp, %ebp
     LCFI1:
            cmpl  $0, 8(%ebp)
            je    L2
            movl  $99, %eax
            jmp   L3
     L2:
            movl  $-99, %eax
     L3:
            leave
     LCFI2:
            ret

• código ASM para g(bool)

  __Z1gb:
     LFB1:
            pushl %ebp
     LCFI3:
            movl  %esp, %ebp
     LCFI4:
            subl  $4, %esp
     LCFI5:
            movl  8(%ebp), %eax
            movb  %al, -4(%ebp)
            cmpb  $0, -4(%ebp)
            je    L5
            movl  $99, %eax
            jmp   L6
     L5:
            movl  $-99, %eax
     L6:
            leave
     LCFI6:
            ret

Surpreendentemente, g(bool)gera mais asminstruções! Isso significa que if(bool)é um pouco mais lento do que if(int)? Eu costumava pensar que boolera especialmente projetado para ser usado em instruções condicionais como if, portanto, esperava g(bool)gerar menos instruções asm, tornando-as g(bool)mais eficientes e rápidas.

EDITAR:

Não estou usando nenhum sinalizador de otimização no momento. Mas mesmo a ausência dela, por que gera mais g(bool)questionamento? É uma questão para a qual estou procurando uma resposta razoável. Devo também dizer que o -O2sinalizador de otimização gera exatamente o mesmo asm. Mas essa não é a questão. A questão é o que eu perguntei.

Faz sentido para mim. Aparentemente, seu compilador define a boolcomo um valor de 8 bits e o ABI do sistema exige que ele "promova" argumentos inteiros pequenos (<32 bits) para 32 bits ao colocá-los na pilha de chamadas. Portanto, para comparar a bool, o compilador gera código para isolar o byte menos significativo do argumento de 32 bits que g recebe e o compara cmpb. No primeiro exemplo, o intargumento usa os 32 bits completos que foram colocados na pilha, então ele simplesmente compara com o todo com cmpl.

Compilar com -03oferece o seguinte para mim:

f:

    pushl   %ebp
    movl    %esp, %ebp
    cmpl    $1, 8(%ebp)
    popl    %ebp
    sbbl    %eax, %eax
    andb    $58, %al
    addl    $99, %eax
    ret

g:

    pushl   %ebp
    movl    %esp, %ebp
    cmpb    $1, 8(%ebp)
    popl    %ebp
    sbbl    %eax, %eax
    andb    $58, %al
    addl    $99, %eax
    ret

.. por isso compila para essencialmente o mesmo código, exceto para cmplvs cmpb. Isso significa que a diferença, se houver, não importa. Julgar por código não otimizado não é justo.

Edite para esclarecer meu ponto. O código não otimizado é para depuração simples, não para velocidade. Comparar a velocidade de um código não otimizado não faz sentido.

Quando eu compilo isso com um conjunto razoável de opções (especificamente -O3), eis o que obtenho:

Para f():

        .type   _Z1fi, @function
_Z1fi:
.LFB0:
        .cfi_startproc
        .cfi_personality 0x3,__gxx_personality_v0
        cmpl    $1, %edi
        sbbl    %eax, %eax
        andb    $58, %al
        addl    $99, %eax
        ret
        .cfi_endproc

Para g():

        .type   _Z1gb, @function
_Z1gb:
.LFB1:
        .cfi_startproc
        .cfi_personality 0x3,__gxx_personality_v0
        cmpb    $1, %dil
        sbbl    %eax, %eax
        andb    $58, %al
        addl    $99, %eax
        ret
        .cfi_endproc

Eles ainda usam instruções diferentes para a comparação ( cmpbpara booleano vs. cmplpara int), mas fora isso os corpos são idênticos. Uma rápida olhada nos manuais da Intel me diz: ... quase nada. Não existe tal coisa como cmpbou cmplnos manuais da Intel. Eles são todos cmpe não consigo encontrar as tabelas de tempo no momento. Estou supondo, entretanto, que não há diferença de clock entre comparar um imediato byte e um imediato longo, portanto, para todos os fins práticos, o código é idêntico.

editado para adicionar o seguinte com base na sua adição

A razão pela qual o código é diferente no caso não otimizado é que ele não é otimizado. (Sim, é circular, eu sei.) Quando o compilador percorre o AST e gera o código diretamente, ele não "sabe" nada, exceto o que está no ponto imediato do AST em que está. Nesse ponto, faltam todas as informações contextuais necessárias saber que, neste ponto específico, ele pode tratar o tipo declarado boolcomo um int. Um booleano é obviamente tratado por padrão como um byte e ao manipular bytes no mundo da Intel você tem que fazer coisas como estender o sinal para trazê-lo a certas larguras para colocá-lo na pilha, etc. (Você não pode empurrar um byte .)

Quando o otimizador visualiza o AST e faz sua mágica, entretanto, ele olha para o contexto circundante e "sabe" quando pode substituir o código por algo mais eficiente sem alterar a semântica. Portanto, ele "sabe" que pode usar um número inteiro no parâmetro e, assim, perder as conversões e ampliações desnecessárias.

Com GCC 4.5 em Linux e Windows, pelo menos sizeof(bool) == 1,. No x86 e no x86_64, você não pode passar menos do que o valor de um registro de uso geral para uma função (seja por meio da pilha ou de um registro, dependendo da convenção de chamada, etc ...).

Portanto, o código para bool, quando não otimizado, vai até certo ponto para extrair esse valor bool da pilha de argumentos (usando outro slot de pilha para salvar esse byte). É mais complicado do que apenas puxar uma variável de tamanho de registro nativo.

No nível da máquina, não existe bool

Muito poucas arquiteturas de conjunto de instruções definem qualquer tipo de operando booleano, embora haja frequentemente instruções que disparam uma ação em valores diferentes de zero. Para a CPU, geralmente, tudo é um dos tipos escalares ou uma string deles.

Um determinado compilador e uma determinada ABI precisarão escolher tamanhos específicos para inte boole quando, como no seu caso, esses tamanhos forem diferentes, eles podem gerar códigos ligeiramente diferentes e, em alguns níveis de otimização, um pode ser um pouco mais rápido.

Por que o bool tem um byte em muitos sistemas?

É mais seguro escolher um chartipo de bool porque alguém pode fazer uma grande variedade deles.

Atualização: por "mais seguro", quero dizer: para o compilador e implementadores de biblioteca. Não estou dizendo que as pessoas precisam reimplementar o tipo de sistema.

Sim, a discussão é divertida. Mas apenas teste:

Código de teste:

#include <stdio.h>
#include <string.h>

int testi(int);
int testb(bool);
int main (int argc, char* argv[]){
  bool valb;
  int  vali;
  int loops;
  if( argc < 2 ){
    return 2;
  }
  valb = (0 != (strcmp(argv[1], "0")));
  vali = strcmp(argv[1], "0");
  printf("Arg1: %s\n", argv[1]);
  printf("BArg1: %i\n", valb ? 1 : 0);
  printf("IArg1: %i\n", vali);
  for(loops=30000000; loops>0; loops--){
    //printf("%i: %i\n", loops, testb(valb=!valb));
    printf("%i: %i\n", loops, testi(vali=!vali));
  }
  return valb;
}

int testi(int val){
  if( val ){
    return 1;
  }
  return 0;
}
int testb(bool val){
  if( val ){
    return 1;
  }
  return 0;
}

Compilado em um laptop Ubuntu 10.10 de 64 bits com: g ++ -O3 -o / tmp / test_i /tmp/test_i.cpp

Comparação baseada em inteiros:

sauer@trogdor:/tmp$ time /tmp/test_i 1 > /dev/null

real    0m8.203s
user    0m8.170s
sys 0m0.010s
sauer@trogdor:/tmp$ time /tmp/test_i 1 > /dev/null

real    0m8.056s
user    0m8.020s
sys 0m0.000s
sauer@trogdor:/tmp$ time /tmp/test_i 1 > /dev/null

real    0m8.116s
user    0m8.100s
sys 0m0.000s

Teste / impressão booleano sem comentário (e inteiro comentado):

sauer@trogdor:/tmp$ time /tmp/test_i 1 > /dev/null

real    0m8.254s
user    0m8.240s
sys 0m0.000s
sauer@trogdor:/tmp$ time /tmp/test_i 1 > /dev/null

real    0m8.028s
user    0m8.000s
sys 0m0.010s
sauer@trogdor:/tmp$ time /tmp/test_i 1 > /dev/null

real    0m7.981s
user    0m7.900s
sys 0m0.050s

Eles são iguais com 1 atribuição e 2 comparações, cada loop em 30 milhões de loops. Encontre algo mais para otimizar. Por exemplo, não use strcmp desnecessariamente. ;)

Dependerá principalmente do compilador e da otimização. Há uma discussão interessante (agnóstica de idioma) aqui:

"If ([bool] == true)" requer uma etapa a mais do que "if ([bool])"?

Além disso, dê uma olhada neste post: http://www.linuxquestions.org/questions/programming-9/c-compiler-handling-of-boolean-variables-290996/

Abordando sua pergunta de duas maneiras diferentes:

Se você está falando especificamente sobre C ++ ou qualquer linguagem de programação que irá produzir código assembly para esse assunto, estamos limitados a qual código o compilador irá gerar no ASM. Também estamos limitados à representação de verdadeiro e falso em c ++. Um inteiro terá que ser armazenado em 32 bits e eu poderia simplesmente usar um byte para armazenar a expressão booleana. Snippets de Asm para declarações condicionais:

Para o inteiro:

  mov eax,dword ptr[esp]    ;Store integer
  cmp eax,0                 ;Compare to 0
  je  false                 ;If int is 0, its false
  ;Do what has to be done when true
false:
  ;Do what has to be done when false

Para o bool:

  mov  al,1     ;Anything that is not 0 is true
  test al,1     ;See if first bit is fliped
  jz   false    ;Not fliped, so it's false
  ;Do what has to be done when true
false:
  ;Do what has to be done when false

Então, é por isso que a comparação de velocidade é tão dependente da compilação. No caso acima, o bool seria um pouco rápido, pois cmpimplicaria em uma subtração para definir os sinalizadores. Também contradiz o que o seu compilador gerou.

Outra abordagem, muito mais simples, é olhar para a lógica da expressão por conta própria e tentar não se preocupar em como o compilador traduzirá seu código, e acho que essa é uma maneira muito mais saudável de pensar. Ainda acredito, em última análise, que o código gerado pelo compilador está, na verdade, tentando fornecer uma resolução verdadeira. O que quero dizer é que, talvez se você aumentar os casos de teste na instrução if e ficar com booleano em um lado e inteiro no outro, o compilador fará com que o código gerado seja executado mais rápido com expressões booleanas no nível da máquina.

Estou considerando que esta é uma questão conceitual, então darei uma resposta conceitual. Essa discussão me lembra das discussões que normalmente tenho sobre se a eficiência do código se traduz ou não em menos linhas de código em assembly. Parece que esse conceito é geralmente aceito como verdadeiro. Considerando que não é viável manter o controle da rapidez com que a ALU irá lidar com cada instrução, a segunda opção seria focar nos saltos e comparações na montagem. Quando for esse o caso, a distinção entre declarações booleanas ou inteiros no código que você apresentou torna-se bastante representativa. O resultado de uma expressão em C ++ retornará um valor que receberá uma representação. Na montagem, por outro lado, os saltos e comparações serão baseados em valores numéricos, independentemente do tipo de expressão que está sendo avaliada em sua instrução C ++ if. É importante, nessas questões, lembrar que declarações puramente lógicas como essas acabam com uma grande sobrecarga computacional, embora um único bit seja capaz da mesma coisa.