Teste de divisibilidade mais rápido que o% de operador?

Notei uma coisa curiosa no meu computador. ^* O teste de divisibilidade manuscrita é significativamente mais rápido que o %operador. Considere o exemplo mínimo:

^{* _{AMD Ryzen Threadripper 2990WX, GCC 9.2.0}}

static int divisible_ui_p(unsigned int m, unsigned int a)
{
    if (m <= a) {
        if (m == a) {
            return 1;
        }

        return 0;
    }

    m += a;

    m >>= __builtin_ctz(m);

    return divisible_ui_p(m, a);
}

O exemplo é limitado por ímpar ae m > 0. No entanto, pode ser facilmente generalizado para todos ae m. O código apenas converte a divisão em uma série de adições.

Agora considere o programa de teste compilado com -std=c99 -march=native -O3:

    for (unsigned int a = 1; a < 100000; a += 2) {
        for (unsigned int m = 1; m < 100000; m += 1) {
#if 1
            volatile int r = divisible_ui_p(m, a);
#else
            volatile int r = (m % a == 0);
#endif
        }
    }

... e os resultados no meu computador:

| implementation     | time [secs] |
|--------------------|-------------|
| divisible_ui_p     |    8.52user |
| builtin % operator |   17.61user |

Portanto, mais de 2 vezes mais rápido.

A pergunta: você pode me dizer como o código se comporta na sua máquina? Perdeu a oportunidade de otimização no GCC? Você pode fazer esse teste ainda mais rápido?

UPDATE: Conforme solicitado, aqui está um exemplo reproduzível mínimo:

#include <assert.h>

static int divisible_ui_p(unsigned int m, unsigned int a)
{
    if (m <= a) {
        if (m == a) {
            return 1;
        }

        return 0;
    }

    m += a;

    m >>= __builtin_ctz(m);

    return divisible_ui_p(m, a);
}

int main()
{
    for (unsigned int a = 1; a < 100000; a += 2) {
        for (unsigned int m = 1; m < 100000; m += 1) {
            assert(divisible_ui_p(m, a) == (m % a == 0));
#if 1
            volatile int r = divisible_ui_p(m, a);
#else
            volatile int r = (m % a == 0);
#endif
        }
    }

    return 0;
}

compilado com o gcc -std=c99 -march=native -O3 -DNDEBUGAMD Ryzen Threadripper 2990WX com

gcc --version
gcc (Gentoo 9.2.0-r2 p3) 9.2.0

UPDATE2: Conforme solicitado, a versão que pode lidar com qualquer um ( ae mse você também deseja evitar o excesso de números inteiros, o teste deve ser implementado com o tipo inteiro duas vezes mais do que os números inteiros de entrada):

int divisible_ui_p(unsigned int m, unsigned int a)
{
#if 1
    /* handles even a */
    int alpha = __builtin_ctz(a);

    if (alpha) {
        if (__builtin_ctz(m) < alpha) {
            return 0;
        }

        a >>= alpha;
    }
#endif

    while (m > a) {
        m += a;
        m >>= __builtin_ctz(m);
    }

    if (m == a) {
        return 1;
    }

#if 1
    /* ensures that 0 is divisible by anything */
    if (m == 0) {
        return 1;
    }
#endif

    return 0;
}

O que você está fazendo é chamado de redução de força: substituindo uma operação cara por uma série de operações baratas.

A instrução mod em muitas CPUs é lenta, porque historicamente não foi testada em vários benchmarks comuns e, portanto, os designers otimizaram outras instruções. Esse algoritmo terá um desempenho pior se for necessário fazer muitas iterações e% terá um desempenho melhor em uma CPU em que precisará apenas de dois ciclos de clock.

Por fim, esteja ciente de que existem muitos atalhos para obter o restante da divisão por constantes específicas. (Embora os compiladores geralmente cuidem disso para você.)

Eu mesmo vou responder minha pergunta. Parece que me tornei vítima da previsão de ramificações. O tamanho mútuo dos operandos não parece importar, apenas a ordem deles.

Considere a seguinte implementação

int divisible_ui_p(unsigned int m, unsigned int a)
{
    while (m > a) {
        m += a;
        m >>= __builtin_ctz(m);
    }

    if (m == a) {
        return 1;
    }

    return 0;
}

e as matrizes

unsigned int A[100000/2];
unsigned int M[100000-1];

for (unsigned int a = 1; a < 100000; a += 2) {
    A[a/2] = a;
}
for (unsigned int m = 1; m < 100000; m += 1) {
    M[m-1] = m;
}

que são / não são embaralhadas usando o modo aleatório função .

Sem embaralhar, os resultados ainda são

| implementation     | time [secs] |
|--------------------|-------------|
| divisible_ui_p     |    8.56user |
| builtin % operator |   17.59user |

No entanto, depois de embaralhar essas matrizes, os resultados são diferentes

| implementation     | time [secs] |
|--------------------|-------------|
| divisible_ui_p     |   31.34user |
| builtin % operator |   17.53user |