Timing Diskrepanz zwischen in Netlogo

Question

Kann jemand erklären, warum es einen Leistungsunterschied zwischen den folgenden zwei Segmenten gibt? Es ist statistisch signifikant, dass der zweite Timer-Anruf eine kleinere Anzahl als der erste Timer-Anruf meldet. Meine einzigen Gedanken wären, dass Netlogo die Schildkröten in Erinnerung behalten könnte. Ist dies das erwartete Verhalten oder gibt es einen Fehler?

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

Dies ist nicht in NetLogo wegen irgendetwas an sich, sondern vielmehr, weil NetLogo läuft auf dem JVM. Die JVM lernt, Code zu optimieren, je mehr es als Teil seiner just-in-time compilation (JIT) ausgeführt wird.

Zu dem Zeitpunkt, zu dem das zweite Segment ausgeführt wird, hatte die JVM Zeit, viele Codepfade zu optimieren, die die beiden Segmente gemeinsam haben. Tatsächlich ist die Reihenfolge der Segmente Schalt ich die folgenden Ergebnisse erhielt:

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 

Nun ist die let x self Code ist schneller (es ist jetzt die zweite Sache, die ausgeführt wird)! Beachten Sie auch, dass beide Zeiten um so geringer sind, je mehr ich lief setup. Dies ist auch auf das JIT der JVM zurückzuführen.

Und falls ich Ansicht Updates deaktivieren und Ihren ursprünglichen Code ausführen, erhalte ich:

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 

Der let x self Code langsamer beginnt (aus dem Grunde, oben) und dann wird etwa die gleiche Geschwindigkeit, wie man vielleicht erwarten. Es gibt viele mögliche Gründe dafür, dass dies nur bei Updates der Ansicht geschieht. NetLogo macht viel weniger mit View-Updates aus

Das JVM JIT ist extrem optimiert, aber kompliziert, und es kann schwierig sein, darüber nachzudenken. There's a lot to consider if you want to write truly correct micro-benchmarks.