search

toppers / hakoniwa-core-cpp-client

5 stars 3 forks source link

測定結果を評価し、期待通りになっているかチェックする #67

Closed tmori closed 1 month ago

tmori commented 1 month ago

測定条件

tmori commented 1 month ago

箱庭アセット数×総処理時間

assetxelapse

tmori commented 1 month ago

アセット数 x 遅延時間の標準偏差

asset-stddev

tmori commented 1 month ago

アセット数10の時の総処理時間x遅延時間の標準偏差

elapse-stddev-m10

tmori commented 1 month ago

アセット数=1

スクリーンショット 2024-09-21 13 42 17 スクリーンショット 2024-09-21 13 42 59

アセット数=2

スクリーンショット 2024-09-21 13 46 02 スクリーンショット 2024-09-21 13 46 30

アセット数=10

スクリーンショット 2024-09-21 13 48 31 スクリーンショット 2024-09-21 13 49 06
kenjihiranabe commented 1 month ago

読み始めました。質問。

ぼくの数学記述では、

としています。森さんの、

固定パラメータ：

ステップ数：1,000ステップ
ステップ時間：10msec

のステップ時間は、どちらでしょう？また、もう一つの値はどうなるでしょう？

tmori commented 1 month ago

のステップ時間は、どちらでしょう？また、もう一つの値はどうなるでしょう？

ステップ時間は、こちらに対応します。

時刻更新のウォール時間間隔 = Δt についてですが、ここはちょっと説明が難しいですね。。

まず、箱庭シミュレーションを現実の時間進行と歩調を合わせたい場合は、箱庭アセット側で明示的にΔT(シミュレーション時刻のカウントアップ幅 )と同じ時間だけ sleep させるようにしています。多分、これが、平鍋さんの定義のウォール時間間隔Δtという解釈でおります。

ただし、この場合、以下の２つの要因により、ウォール時間間隔Δtは、毎回同じ値にはならないと考えております。

なので、Δt は以下のようになると思います。

Δt = <sleep時間> + <箱庭アセット処理時間> + <OSジッタ>

<OSジッタ>は、PCの性能に依存しますし、処理負荷が高くなると、幅を利かせてくるような気がしています。

次に、今回の測定についてですが、現実の時間進行と歩調を合わせておりませんので、<sleep時間>は、０にしています。

<箱庭アセット処理時間> については、10000回ビジーループする時間になりますが、ここは測定しておりませんので、どれくらいかはわからない感じです。。

kenjihiranabe commented 1 month ago

了解しました。ぼくの方でも、Δt 自身は証明には必要なくて、数列の添字の代わりくらいに思ってもらって（一回づつずれても）大丈夫です。

感覚的には、ウォール時刻 t やサンプリング時間感覚 Δtは「意識していない」もしくは「ループをできるだけ早く回している」ということですね。

また、やろうとすれば、 sleep を入れて明示的に示すことはできるが、どうせ揺れると。ただし、シミュレーション時刻の方は、増加量 ΔT を一定にしている。

ですかね。

あと、結果としての毎回の t （ウォール時刻）をログとして出すことは可能ですね？

tmori commented 1 month ago

また、やろうとすれば、 sleep を入れて明示的に示すことはできるが、どうせ揺れると。ただし、シミュレーション時刻の方は、増加量 ΔT を一定にしている。

ですかね。

ですね。

あと、結果としての毎回の t （ウォール時刻）をログとして出すことは可能ですね？

はい、今回の測定では、real-time として、念の為ログ採取しております。

こんな感じです。 asset-0-measure.csv

kenjihiranabe commented 1 month ago

実時間では、結構、コアも揺れますね。もちろん同じPC上で、他のソフトも動いているしね。

image