Mi programa supuestamente determinista produce una de las pocas salidas ligeramente diferentes en diferentes ejecuciones. La entrada, el compilador y la computadora no cambian. No estoy seguro de qué salida es correcta porque siempre parece razonable.Fuentes de no determinismo
Además de una llamada perdida a rand(), ¿cómo podría ser esto posible?
de varias maneras:
seguramente Podemos hacer más conjeturas, pero si usted desea conseguir una ayuda significativa, tal vez sería bueno para usted para publicar las partes relevantes de su código :-)
Sí; necesitamos código! Por supuesto, todos estos factores, así como los errores decimales y las pseudoaleatorizaciones son técnicamente deterministas ya que se ejecutan en una máquina determinista. Simplemente no nos parecen deterministas cuando no podemos rastrear o comprender las entradas y los millones de estados progresivos de nuestro programa en el contexto de un sistema de tiempo compartido controlado menos personalmente. Es por eso que la teoría y la informática siempre son importantes para enseñar junto con las habilidades de programación de tuercas y tornillos. –
Debería haber dejado en claro que solo quería una lista de posibilidades comunes, que es lo que obtuve. Gracias. – zoo
Podría ser:
Sin ver ningún código (CONSEJO CONSEJO), lo mejor que puedo pensar sería buscar un patrón. Tal vez algo específico de la fecha y hora.
Además, intente buscar condiciones de carrera. Eso puede parecer no determinista.
Si su salida depende de una dirección asignada en el montón:
int main(int argc, char* argv[])
{
printf("%p", malloc(42));
return 0;
}
Para cada ejecución, el malloc() puede devolver una dirección diferente virtuales - por no hablar de NULL en caso de que la asignación falló.
Buena captura. La aleatorización de direcciones de pila/pila es una característica bastante estándar hoy en día. Eso tendría un efecto si los punteros se utilizan como claves en alguna parte. Lo usé en un par de ocasiones para hacer que el género sea estable (si las claves son iguales, compara los punteros). – Dummy00001
Sin embargo, tendrías que ser bastante desafortunado/ejecutar con muy poca memoria para tener una falla de asignación. – zneak
La salida dependería de una dirección asignada en el montón si los objetos asignados en el montón se ordenan por su dirección, por ejemplo, si los punteros se almacenan en un contenedor ordenado como un conjunto. – Richard
Usar el valor de un puntero en lugar de lo que apunta a siempre produce resultados interesantes.
Además de una llamada perdida a rand()
rand() es completamente determinista, siempre y cuando le da de comer la misma semilla inicial.
Obviamente una nueva instancia del error Phase of the Moon.
En los programas que no interactúan mucho con el "mundo exterior", la fuente popular de no determinismo es la confianza en comparación puntero. De vez en cuando puede verlo en el código: cuando una función de comparación lexicográfica se queda sin cosas para comparar (todo es igual), compara las direcciones de objetos como último recurso. Esto puede producir diferentes ordenamientos si los objetos están asignados en la memoria dinámica, ya que las ubicaciones de asignación reales pueden diferir de una plataforma a otra y de una ejecución a otra.
No proporcionó mucha información. Sin embargo, como alguien que hace programación en tiempo real para ganarse la vida, los culpables más probables que busco cuando suceden tales cosas es:
Por ejemplo, uno de esos problemas que tuve una vez fue que la biblioteca compartida no era tan "compartida" como pensé, y tratando de usar un identificador de un proceso para indexar una tabla que aún no se inicializaba en una segundo proceso. Dependiendo de cómo empezaron las cosas, es posible que haya o no haya causado datos importantes en un tercer proceso que se haya destruido.
Cualquier comportamiento indefinido. es decir: llevará cientos de páginas explicar cada posible fuente de alteración de la salida. Intente depurar para encontrar donde ocurre la alteración, o leyendo algunas especificaciones de C++.
Si su programa usa float/double, puede haber una diferencia en el resultado si hay un cambio de contexto en alguna arquitectura.
En x86, la FPU usa una precisión extendida para el resultado intermedio, pero cuando se guarda en la memoria (lo que sucede cuando hay un cambio de contexto en proceso o subproceso), dicha precisión se pierde. Eso podría causar una pequeña divergencia del resultado (hemos detectado tal problema en nuestro programa). Una forma de evitar este problema es pedirle al compilador que no use FPU sino SSE para operaciones de coma flotante.
http://www.network-theory.co.uk/docs/gccintro/gccintro_70.html
Habría que ver algo de código antes de hacer especulaciones. –
¿Su código contiene algo que se desvía hacia la tierra del comportamiento indefinido? –
¿Quién dijo que los compiladores son deterministas? – AshleysBrain