* タスクセーブなどに関する議論
 -(by [[K]], 2019.02.25)
 
 ** (0)
 -Essen2019-Aに搭載されている変数監視機能は、結局は第一世代OSASKの目指していた「タスクセーブ」の副産物みたいなものです。
 -''そう私はタスクセーブをずっとやりたかったのです!!''
 
 ** (1)
 -以前は、タスクセーブ相当なことをするには、OSから手掛けなければいけないと思っていました。それはASLRなどによって、起動ごとにスタックの位置やヒープの位置が変わってしまうからです。それでは全メモリイメージを保存していても、再開がうまく行きません。
 -しかしそれは2016年にpersistent-Cをやった時に、ポインタを使わないデータ構造を採用するという方向でなんとかできると思い、OSからやらなくても実現できる可能性が出てきました。OSからやらなくてもいいのであれば、私は面倒なデバイス開発をする必要が無くなるので、一気に実現可能性が出てきます。
 
 -次の問題として、どのタイミングで保存をさせるのかという問題がありました。いつでも保存してしまっていいのでしょうか。たとえば何かのロックを取ったまま保存するのはいいことでしょうか、私はそれは良くないと思います。できるだけ切りの良いタイミングで保存するべきです。
 -ではどうすれば切りのいいタイミングで保存できるでしょうか。真っ先に思い付いたのは、保存してほしくない期間中は「保存抑制フラグ」を立てておき、もしその期間中に保存要求が来たら「保存待機フラグ」を立て、保存抑制フラグを下げるときには保存待機フラグを確認させるというものでした。・・・しかしこれは、プログラム内でしょっちゅうフラグ操作をするということであり、煩雑になってしまいそうです。頻繁にやりすぎると速度低下の恐れもあります。
 -ということで、いっそのこと、プログラム内に数か所設定した「チェックポイント」でのみ保存待機フラグをポーリングするようにして、その他の間はずっと保存抑制フラグがONであるかのようにふるまうことにしました。これによって失われるのは、ユーザが保存したいと思ってから実際に保存が始まるまでの時間差が生じやすくなるということですが、そもそもそんな厳密のこのタイミングで保存しなければいけないということはないので、問題になっていません。それよりも保存の段階でメモリの状態が確実にきれいになっていること&アプリ開発に際して面倒な割り込み処理を意識しないでもいいこと、の2点の方がはるかに大きなメリットになっています。
 -とはいえ、チェックポイントから次にチェックポイントまでに何ミリ秒かかったかについては、保存待機がなくとも常に監視して、アプリケーションの品質を表す値の一つとしていつでも容易に確認できるようにしています。
 
 ** (2)
 -このパラダイムの転換によって、良い効果が生まれました。・・・割り込み抑制型のモデルだと、アプリプログラムは「抑制期間はできるだけ短くしなければならない」という暗黙の前提があるせいで、窮屈なプログラミングになりがちです。抑制期間中であればポインタを使っても構わないわけですが、やはりデフォルトでは使うべきではないという雰囲気になってしまいがちです。それで全体的に遅くなります。
 -しかしチェックポイント型であれば、チェックポイントの時だけポインタを手放していればよく、チェックポイントを抜けたらまたポインタを取得してアクセスできるわけで、だから普通のプログラミングと比較して速度低下がほとんどありません。処理が一段落してしまえば、アクセスに使ったポインタを手放すことは実質的には何のロスもなく、自然な感じでプログラムを書くことができます。
 
 ** (3)
 -Essenではこのチェックポイントはセーブ可能なタイミングであるだけではなく、疑似マルチタスクの切り替えタイミングでもあります。
 
 ** (4)
 -ゲームを作る立場からすれば、変数の内容が容易に見えてしまったり、それを変更できてしまったりするのは悪夢です。またいつでもセーブできてしまうというのもありがた迷惑です。これでは進行上重要なフラグも立てたい放題ですし、レベルもヒットポイントも変更できてしまいますし、ボスを弱くすることもできてしまいます。
 -これに関して言えば、たとえばプログラムの冒頭である命令を実行すれば、該当のプロセスについて、以降は変数の内容を見せないようにしたり、書き換えできないようにしたり、保存できないようにしたりすることができると考えています。つまり私はプログラマの意思を無視してまで、タスクセーブを実現しようとまでは思っていないのです。
 
 ** (5)
 -CPU負荷が100%みたいなアプリでは、他のアプリを同時に起動することで減速させることが容易にできますが、cubeやinvaderなど基本的にほとんど時間をタイマ待ちで費やしている低負荷のアプリに対してはこの方法はほとんど役に立ちません。でもこれらに対してもスローで実行したり、逆に高速にしてみたりしたいというのは十分にありうる話です。
 -これらについては、アプリに見せる時間そのものを遅らせるのが有効そうだと思っており、その方向で開発しようと思っています。
 
 * こめんと欄
 #comment

リロード   新規 編集 差分 添付   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS