Si ha perfilado su código con cuidado y encontró que un operador de módulo es el mayor costo en un bucle interno, entonces hay una optimización que podría ayudar. Es posible que ya están familiarizados con el truco para determinar el signo de un entero usando desplazamientos aritméticos izquierda (para los valores de 32 bits):
sign = (x >> 31) | 1;
esto se extiende el bit de signo a través de la palabra, por lo que los valores negativos producen -1 y positivo valores 0. a continuación, el bit 0 se establece de modo que los valores positivos representan 1.
Si solo estamos incrementando los valores por una cantidad que es menor que el módulo entonces este mismo truco puede ser utilizado para envolver el resultado:
val += inc;
val -= modulo & (static_cast<int32_t>(((modulo - 1) - val)) >> 31);
Alternativamente, si está disminuyendo por valores menores que el módulo a continuación, el código en cuestión es:
int32_t signedVal = static_cast<int32_t>(val - dec);
val = signedVal + (modulo & (signedVal >> 31));
He añadido los operadores static_cast porque yo estaba pasando en uint32_t, pero puede que no sea necesario encontrarlos.
¿Esto ayuda mucho a diferencia de un simple operador%? Eso depende de su compilador y arquitectura de CPU. Descubrí que un bucle simple funcionaba un 60% más rápido en mi procesador i3 cuando se compilaba con VS2012; sin embargo, en el chip ARM11 de Raspberry Pi y compilando con GCC solo obtuve una mejora del 20%.
"¿Este código implica ciclos while lo suficientemente eficientes, en comparación con% operador?" Usted nos dice que usted es quien usa el programa. ¿Se siente lento? ¿Puedes siquiera darte cuenta? ¿Ha perfilado y encontrado que esto es lento en absoluto? – GManNickG
Eso dependerá del tamaño. Si 'b = 1000000000' y' c = 3'. Llevará un tiempo ... – Mysticial
¿Puede indicar la CPU y el compilador de destino? Sin eso, es imposible comparar cualquier enfoque. – fghj