Início / coding / Perguntas / 79597905
Accepted
Grigory Rechistov
Asked: 2025-04-29 16:13:47 +0800 CST

Exemplo de um microbenchmark para demonstrar que o código embutido nem sempre é benéfico para o desempenho

  • 772

TL;DR: muitas fontes citam a afirmação de que o uso excessivo de funções em linha pode, às vezes, prejudicar o desempenho do aplicativo devido ao excesso de código ou outros fatores. Existe algum exemplo real de programa que demonstre isso de forma mensurável?

Lembre-se: a missão de um microbenchmark na vida é ampliar algum aspecto do desempenho do seu programa. Por isso, qualquer pessoa pode facilmente gerar um microbenchmark que faça qualquer problema parecer um grande problema. // Dicas de Desempenho de Rico Mariani

Muitos programadores com quem converso têm a noção de que o inline de funções é incondicionalmente benéfico para o desempenho do aplicativo. O código C/C++ que analiso frequentemente tem inlinepalavras-chave (ou equivalente) aplicadas gratuitamente a funções, independentemente de seu tamanho, finalidade, popularidade ou posicionamento.

Em muitos casos, esse hábito estranho (chamado aqui de "doença do inline" ) é inofensivo para o desempenho geral: os compiladores modernos têm bom senso sobre o que realmente deve ser incorporado, e muito pouco código é quente o suficiente para que o (não)inline faça alguma diferença. Ainda assim, muitas vezes é prejudicial ao design do software resultante: mais coisas acabam nos cabeçalhos, os arquivos não são mais compiláveis ​​independentemente, etc.

Embora seja bastante fácil demonstrar que a aplicação aleatória sem benchmarking contínuo não faz nenhuma diferença mensurável no desempenho final, estou procurando um exemplo extremo em que forçar a questão prejudica estritamente o desempenho.

Um microbenchmark será suficiente; embora não prove nada sobre os efeitos do inline em aplicações do mundo real, deve demonstrar de forma comprovada que aplicá-lo cegamente não é uma boa ideia incondicional . Essa é realmente a ideia por trás de quase qualquer processo de otimização de código: pode ajudar, pode prejudicar e, às vezes, não faz diferença.

Alguns requisitos para tal exemplo de microbenchmark.

  1. Deve ser um programa razoavelmente curto, de preferência em C ou C++; outras linguagens nas quais o inlining pode ser aplicado também são bem-vindas.
  2. Não precisa ser um programa fazendo algo útil, ele pode fazer coisas "bobas" só para carregar/estressar o hardware subjacente.
  3. Deve ser possível compilá-lo em dois modos: com inlining imposto e inlining desabilitado. Qualquer técnica para conseguir isso pode ser usada: compilação condicional para redefinir anotações de inlining, sinalizadores de backend do compilador para controlar o inlining, etc.
  4. Ele deve ser bem formado e exibir o mesmo comportamento bem definido, independentemente de em qual dos dois modos ele for compilado.
  5. Ele deve conter pelo menos duas funções, uma chamando a outra, com a intenção de afetar o inlining de pelo menos uma delas.
  6. Pode conter qualquer técnica para garantir/impor a inclusão de funções em linha. Por exemplo, inlineextensões padrão de palavras-chave ou específicas do compilador ( __forceinline, __attribute__ ((always_inline))etc.) podem ser usadas para instruir o compilador a fazê-lo, independentemente de seu julgamento.
  7. Ao executar, o desempenho (latência, tempo de execução ou métrica semelhante) pode ser facilmente reportado. Pode ser apenas usando time a.out, ou chamadas internas para um recurso de temporização em torno do código afetado.
  8. Por fim, quando compilado por pelo menos um compilador específico de uma versão específica e executado em pelo menos um sistema de destino, as duas variantes resultantes do programa exibem diferenças estatisticamente significativas, e a compilação forçada em linha é mais lenta do que a compilação não em linha .

Eu percebo que o desempenho depende muito dos parâmetros do host; o que é mais lento em uma máquina pode se tornar tão rápido quanto ou mais rápido em outra. Mas estou buscando o pior cenário, quando o inlining irrestrito for comprovadamente contraproducente.

O ideal é que outras opções de backend do compilador que não afetam o inlining (como nível geral de otimização etc.) sejam as mesmas para duas compilações, a fim de excluir a possibilidade de que a diferença observável seja explicada por elas e não pelo inlining aplicado/ignorado.

Tenho uma ideia de um ponto de partida para esse programa, mas preciso de mais ajuda para desenvolvê-lo:

  1. Uma função interna é grande o suficiente para quase não caber no cache de instruções da CPU.
  2. Uma função externa é grande o suficiente para que, se a função interna for incorporada à força, a seção de código resultante se torne maior que o cache de instruções da CPU.
  3. O fluxo de controle do programa é organizado de tal forma que, quando tudo é incorporado, ele sofre uma frequência maior de falhas de cache de instruções, liberações de cache ou eventos semelhantes que não aconteceriam se o embutimento não fosse imposto.
performance

1 respostas

  1. Best Answer

    Eu experimentei e usei o desenrolamento de loop do GCC para obter muito código de máquina a partir do seguinte código C:

    #include <stdint.h>

// from https://prng.di.unimi.it/xoshiro256starstar.c
static inline uint64_t rotl(const uint64_t x, int k) {
    return (x << k) | (x >> (64 - k));
}
static uint64_t s[4];
// a fast PRNG that will get inlined to generate lots of code
static uint64_t next(void) {
    const uint64_t result = rotl(s[1] * 5, 7) * 9;

    const uint64_t t = s[1] << 17;

    s[2] ^= s[0];
    s[3] ^= s[1];
    s[1] ^= s[2];
    s[0] ^= s[3];

    s[2] ^= t;

    s[3] = rotl(s[3], 45);

    return result;
}

uint64_t benchmark() {
  uint64_t sum = 0;
#ifdef UNROLL
  #pragma GCC unroll 65534
#endif
  for (int i = 0; i < 5000; i++) {
// do something
    if (sum & 1) {
      sum += next() >> 60;
    } else {
      sum += 1;
    }
  }

  return sum;
}

#include <inttypes.h>
#include <stdio.h>
#include <sys/random.h>
#include <time.h>

int main() {
  struct timespec t0, t1;

  // initialise from urandom
  getrandom(s, sizeof(s), 0);

  // run test 5 times
  for (int i = 0; i < 5; i++) {
    clock_gettime(CLOCK_MONOTONIC, &t0);

    uint64_t res = benchmark();

    clock_gettime(CLOCK_MONOTONIC, &t1);

    double dt = t1.tv_sec - t0.tv_sec;
    dt += (t1.tv_nsec - t0.tv_nsec) / 1e9;

    printf("took %.1f us to calculate %" PRIu64 "\n", dt * 1e6, res);
  }
}

    Salvando isso inlinecost.ce compilando via:

    gcc -Wall -Os -o inlinecost inlinecost.c
gcc -Wall -Os -o inlinecost-unrolled inlinecost.c -DUNROLL

    dando-me os seguintes binários:

    -rwxr-xr-x 1 smason smason  15656 Apr 29 16:30 inlinecost
-rwxr-xr-x 1 smason smason 597288 Apr 29 16:30 inlinecost-unrolled

    Mostrando que certamente está gerando mais código.

    Correr inlinecostme dá:

    took 12.4 us to calculate 26605
took 12.0 us to calculate 26265
took 12.3 us to calculate 26759
took 12.1 us to calculate 26487
took 12.3 us to calculate 26499

    enquanto inlinecost-unrolledme dá:

    took 167.4 us to calculate 27161
took 28.1 us to calculate 26685
took 24.8 us to calculate 26297
took 25.0 us to calculate 26388
took 24.2 us to calculate 26763

    Você pode ver que o código não embutido é executado de forma muito mais consistente, enquanto a versão desenrolada leva 10 vezes mais tempo para carregar o código de máquina da RAM para o cache e executá-lo, e então "apenas" leva o dobro do tempo para executá-lo.

    Ter o loop benchmarkgerando mais iterações (por exemplo, aumentando 5000 para 10000) torna essa diferença ainda mais visível, mas leva muito tempo para compilar.

    Aqui está um link para o GodBolt com apenas 5 iterações desenroladas (muitas iterações fazem com que a compilação atinja o tempo limite porque está gerando muito código), mostrando que ele está incorporando o PRNG.

    Espero que seja útil!

    Atualização: tentei mudar benchmarkpara fazer:

    uint64_t benchmark() {
  uint64_t sum = next();
#ifdef UNROLL
#pragma GCC unroll 65534
#endif
  for (int i = 0; i < 30000; i++) {
    if (sum == 0) {
      uint64_t x = 0;
#ifdef UNROLL
#pragma GCC unroll 1024
#endif
      for (int j = 0; j < 4; j++) {
        x ^= next();
      }
      sum += x >> 60;
    } else {
      sum += 1;
    }
  }

  return sum;
}

    Isso leva a versão desenrolada a ~400µs na primeira vez, depois ~50µs nas iterações subsequentes, enquanto a versão em loop parece levar de forma confiável ~7µs. Eu esperava que o preditor de ramificação tivesse dificuldades com tanto código, mas pelo menos minha CPU está se saindo notavelmente bem com isso — um AMD 9900X, ou seja, Zen5. Não sei por que me lembrei do Zen4 no meu comentário abaixo.

    • 1

relate perguntas