Différence temporelle entre dans Netlogo

Question

Quelqu'un peut-il expliquer pourquoi il existe une différence de performance entre les deux segments suivants? Il est statistiquement significatif que l'appel du deuxième temporisateur rapporte un nombre plus petit que le premier appel du temporisateur. Mes seules pensées seraient que Netlogo pourrait mettre en cache les tortues en mémoire. Est-ce le comportement attendu ou y a-t-il un bug?

to setup 
    clear-all 
    crt 100 
    let repetitions 10000 

    ;;Timing assigning x to self 
    reset-timer 
    repeat repetitions 
    [ 
    ask turtles 
    [ 
    let x self 
    ] 

    ] 
    show timer 

    ;;Timing assigning x to who of self 
    reset-timer 
    repeat repetitions 
    [ 
    ask turtles 
    [ 
    let x [who] of self 
    ] 
    ] 
    show timer 
end 

Answer 1

Ce n'est pas à cause de quoi que ce soit dans NetLogo lui-même, mais plutôt parce que NetLogo fonctionne sur le JVM. La JVM apprend à optimiser le code plus il l'exécute dans le cadre de son just-in-time compilation (JIT).

Au moment où le deuxième segment est exécuté, la machine virtuelle Java a eu le temps d'optimiser plusieurs chemins de code que les deux segments ont en commun. En effet, l'ordre de commutation des segments, j'ai obtenu les résultats suivants:

observer> setup 
observer: 0.203 
observer: 0.094 
observer> setup 
observer: 0.136 
observer: 0.098 
observer> setup 
observer: 0.13 
observer: 0.097 
observer> setup 
observer: 0.119 
observer: 0.095 
observer> setup 
observer: 0.13 
observer: 0.09 

Maintenant, le code let x self est plus rapide (il est maintenant la deuxième chose qui fonctionne)! Notez également que les deux fois diminuent le plus j'ai couru setup. Ceci est également dû au JIT de la JVM.

De même, si j'éteins des mises à jour de vue et exécutez votre code d'origine, je reçois:

observer> setup 
observer: 0.088 
observer: 0.071 
observer> setup 
observer: 0.094 
observer: 0.072 
observer> setup 
observer: 0.065 
observer: 0.075 
observer> setup 
observer: 0.067 
observer: 0.071 
observer> setup 
observer: 0.067 
observer: 0.068 

Le code let x self commence plus lentement (pour la raison ci-dessus) et devient alors la même vitesse, comme un pourrait s'attendre. Il existe de nombreuses raisons possibles pour lesquelles cela ne se produit que si les mises à jour sont désactivées. NetLogo fait beaucoup moins avec les mises à jour désactivées

Le JIT de la JVM est extrêmement optimisé, mais compliqué, et il peut être difficile à raisonner. There's a lot to consider if you want to write truly correct micro-benchmarks.