Netlogoでのタイミングの相違

Question

次の2つのセグメントにパフォーマンスの違いがある理由は誰でも説明できますか？ 2番目のタイマーコールが最初のタイマーコールよりも小さい数を報告することは統計的に重要です。私の唯一の考えは、Netlogoがメモリ内のカメをキャッシングする可能性があるということです。これは予想された動作ですか？またはバグがありますか？

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

これはNetLogo自体には何のではなく、むしろNetLogoはJVM上で実行されるため。 JVMは、just-in-time compilation (JIT)の一部としてコードを実行するほど、コードを最適化する方法を学びます。

2番目のセグメントが実行されるまでに、JVMには2つのセグメントが共通する多くのコードパスを最適化する時間がありました。確かに、セグメントの順序を切り替え、私は以下の結果を得た：

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 

今let x selfコードは（それが今で走る秒のことだ）高速です！また、私が実行した回数が多いほど、両方の時間が減少することに注意してください。setup。これはJVMのJITも原因です。私は、ビューの更新をオフにして、あなたのオリジナルのコードを実行した場合

は同様に、私が取得：

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 

let x selfコードは（上記の理由で）遅くを開始し、1と、ほぼ同じ速度となり期待するかもしれない。なぜこれは、ビューの更新をオフにした場合にのみ発生するのか、考えられる理由はたくさんあります。ビューの更新をオフにすると、NetLogoの処理が大幅に減る

JVMのJITは非常に最適化されていますが、複雑ではありません。 There's a lot to consider if you want to write truly correct micro-benchmarks.