2010-10-16 5 views
5

Actualmente estoy reescribiendo uno de mis programas. Tiene una función muy recursivo que resuelve PEG-solitario:C: Cuál es más rápido, acceder a la variable global o pasar un puntero a la función

int solve(int draw) { 
    if (finished()) 
    return true; 

    //loop over every possible move (about 76 long values) 
    //do a move (access the board, which is a long value) 
    if (solve(draw + 1)) 
    return true; 

    return false; 
} 

así que me preguntaba si es más rápido usar resuelve así:

solve(int draw, long **moves, long *board) {} 

Por el momento ambos movimientos y junta son variables globales.

Por supuesto que voy a probarlo, pero si alguien me dice que este intento no va a ser eficiente, ahorraré algo de tiempo :).

mejores deseos

+1

La primera regla de la Optimización es que usted no habla de Optimización. –

Respuesta

9

Probablemente no será tan eficiente, pero la única manera de saber con certeza es que el perfil de su código. Si se gasta la mayor parte del tiempo de ejecución haciendo su lógica de juego real, entonces la pequeña cantidad de sobrecarga que pone algunos argumentos en la pila debería ser insignificante.

Sin embargo, desde el punto de vista del diseño, evitar las variables globales es mucho mejor. Permite que su código sea sin estado y, por lo tanto, potencialmente reentrante y seguro para subprocesos. Sin embargo, esto puede o no ser relevante para su aplicación.

+1

El otro beneficio para evitar los globales es que las pruebas unitarias son más fáciles. –

1

Hay cierta sobrecarga con parámetros de paso para funcionar - escribir los parámetros para apilar. En la mayoría (probablemente todas) las arquitecturas modernas, el acceso a la pila y el acceso a los datos globales tienen la misma velocidad, por lo que lo más probable es que los parámetros de aprobación sean un poco más lentos.

+0

Existen algunas arquitecturas que pasan argumentos de funciones en los registros de la CPU. Sin embargo, el aumento de rendimiento asociado se elimina si está utilizando la función recursivamente. –

2

¡Esto parece optimizar demasiado pronto!

Cada vez que llame a solve(), debe verificar si ha terminado(). El costo del cheque finished() va a eliminar cualquier diferencia en el tiempo de acceso variable.

Primero, corrígelo, luego perfúlalo si es demasiado lento, luego ¡optimízalo!

2

No creo que este sea el cuello de botella de rendimiento.

La única cosa que viene a la mente con el código que muestra es la siguiente:

¿Necesita variables long largas? Por lo general, necesitan más espacio, lo que significa más tiempo para usarlos. Recuerdo una vez que reemplacé las variables dobles con variables flotantes y obtuve un GRAN impulso (50% menos de tiempo de ejecución). Esto puede ayudar un poco :)

+0

Desafortunadamente sí, la placa de clavijas puede contener 33 clavijas, por lo que necesito más de 32 bits :(. – imbaer

+0

Estoy bastante seguro de que 'long long' - si se deben tomar como enteros de 64 bits - no van a ser más lentos en las CPU modernas que cualquier otra cosa. –

Cuestiones relacionadas