Test di divisibilità più veloce di% operatore?

Ho notato una cosa curiosa sul mio computer. ^* Il test di divisibilità scritto a mano è significativamente più veloce %dell'operatore. Considera l'esempio minimo:

^{* _{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);
}

L'esempio è limitato da dispari ae m > 0. Tuttavia, può essere facilmente generalizzato a tutti ae m. Il codice converte la divisione in una serie di aggiunte.

Consideriamo ora il programma di test compilato con -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 i risultati sul mio computer:

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

Pertanto più di 2 volte più veloce.

La domanda: puoi dirmi come si comporta il codice sul tuo computer? Ha perso l'opportunità di ottimizzazione in GCC? Puoi fare questo test ancora più velocemente?

AGGIORNAMENTO: Come richiesto, ecco un esempio riproducibile minimo:

#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;
}

compilato con gcc -std=c99 -march=native -O3 -DNDEBUGAMD Ryzen Threadripper 2990WX con

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

UPDATE2: come richiesto, la versione in grado di gestire qualsiasi ae m(se si desidera anche evitare l'overflow di numeri interi, il test deve essere implementato con il tipo intero due volte più lungo degli interi di input):

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;
}

Quello che stai facendo si chiama riduzione della forza: sostituire un'operazione costosa con una serie di operazioni economiche.

L'istruzione mod su molte CPU è lenta, perché storicamente non è stata testata in diversi benchmark comuni e quindi i progettisti hanno ottimizzato altre istruzioni. Questo algoritmo funzionerà peggio se deve fare molte iterazioni e% funzionerà meglio su una CPU dove ha bisogno solo di due cicli di clock.

Infine, tieni presente che ci sono molte scorciatoie per prendere il resto della divisione per costanti specifiche. (Anche se i compilatori generalmente si prenderanno cura di questo per te.)

Risponderò alla mia domanda da solo. Sembra che sono diventato vittima della previsione del ramo. La dimensione reciproca degli operandi non sembra avere importanza, ma solo il loro ordine.

Considera la seguente implementazione

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 gli array

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;
}

che sono / non sono mescolati usando la funzione shuffle .

Senza mescolare, i risultati sono ancora

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

Tuttavia, una volta mischiato questi array, i risultati sono diversi

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