Je crois que vous avez mal compris : chaque exécution du simulateur ne fait qu'une seule simulation. En d'autres termes, pour avoir une prédiction, il faut l'exécuter plein de fois et faire des stats sur l'ensemble des résultats obtenus.

C'est l'argument des auteurs du code : ce n'est pas important que le code ne soit pas déterministe, puisque de toute façon on fait la moyenne des résultats. Celui qui a écrit l'article rétorque que même si on fixe les paramètres d'entrée (y compris la seed) et qu'on désactive les sources de non-déterminisme (en n'utilisant qu'un seul thread), deux exécutions du code ne donnent pas les mêmes résultats, et que c'est anormal.

J'avoue que je suis circonspect sur la question :

- d'un côté, c'est (très) contraignant d'avoir du déterminisme dans ce genre de code, surtout si c'est multithreadé. Surtout que normalement, une fois que la moyenne des résultats est faite, que ce soit déterministe ou pas ne doit rien changer.

- de l'autre, sans déterminisme, on perd la répétabilité parfaite, et ça peut masquer des bugs comme la lecture de mémoire non initialisée, empêcher de vérifier qu'un refactoring n'a pas eu d'effet de bord, rendre le débogage beaucoup plus ardu, etc. Et le fait que le code ne donne pas toujours les mêmes résultats même en fixant tous les paramètres est pour le moins louche.