3 (=3/60秒) と表示されます。 ITmediaの細田隊長によると、(続く)

あ、出力例は New3DS です。new じゃないともっと遅くなると思います。 こごで、プログラムは 3/60 秒で終了したと思っているけど、 実行モードに制御が返ってくるのは 10 秒後。 ITmedia 記事で細田隊長の言う「メインスレッドとインタプリタ」というのは、この場合どっちがどっちなんですかね??? (a) メインスレッド=コンソール表示(10秒), インタプリタ=(3/60秒) (b) メインスレッド=(3/60秒), インタプリタ=コンソール表示(10秒)

あと、誰か激遅四天王(配列, inc, 乗算, goto)について突っ込んだ人はいなかったのかな??

メインスレッドって言葉で混乱してるだけだろ メインスレッドはユーザープログラムのメインスレッドじゃなくて、プチコンのメインスレッドのことでしょ。 インタプリタは描画してないんだから メインスレッド10秒 インタプリタ3/60秒。 インタプリタスレッドはメインスレッドにタスク投げるだけ

今ひとつわからない。 > VSYNCが発生するとメインスレッドが走り、システム処理が終わると次のVSYNCまでインタプリタスレッドが動く、という処理になっている。 メインスレッドで "-"*1e6 を書くのに10sかかるならインタプリタに制御が渡るのはいつ??? メインスレッドがcpu握ってるならインタプリタも 10s かかる気がする。 握っててもインタプリタスレッドがプリエンプティブちっくに制御を奪うってこと???

あ!! メインスレッドが表示に専念中は maincnt も進んでないのかな???

wait 1 t0$=time$ ? "-"*1e6 t1$=time$ ? t0$, t1$ これでも t1$-t0$ は 1s 未満だなあ??????

time$ の更新も vsync 依存なんでしたっけ????

> メインスレッドで "-"*1e6 を書くのに10sかかるならインタプリタに制御が渡るのはいつ??? その途中だけど上のコードはもうインタプリタ実行終えてるから待ってるだけなのでインタプリタに制御映らない。 > メインスレッドがcpu握ってるならインタプリタも 10s かかる気がする。 > 握っててもインタプリタスレッドがプリエンプティブちっくに制御を奪うってこと??? メインスレッド待つ操作があるならそこで待つでしょ。今回はないので待たない。 メインスレッドはおそらくVSync+画面モードで決まる時間＋その他いろいろで決まる時間だけ処理する。その後他のスレッドに投げる。 インタプリタはメインスレッドに処理を投げる。そこはたぶんちょっとインテリジェトなキューにななっててメインスレッドがキューこなすまで止まったりする。

あらら。もう寝るので後で読みます。 wait 1 t0=maincnt t0$=time$ ? "="*1e6 wait 60 <---- 1s 待ちいれた t1=maincnt t1$=time$ t1-t0 = 63 (63/60s = 1+3/60s) t1$=t0$= 10s という結果になりました。

知っているとは思いますが、VSYNCを契機とする周期処理とインタプリタの処理とが、共通リソースで競合すると問題が発生します。その対処として、インタプリタの処理の一部で割り込みをマスクするか、VSYNCの周期処理と同じスレッドへ乗り換える処理で排他制御をしている（推測）為にそのような振る舞いになっていると思われます。ユーザが、処理を小分けにすれば、回避できると思います。

その説明は微妙。 コンソールの更新はメインスレッドがやってるだろ。 共通リソースじゃないし競合してるわけじゃない。 単にメインスレッドの処理が多いだけ

推測なので間違っているかもしれませんが、 画面の表示には、 １）ユーザプログラムからの指示で、更新されるエリア ２）ハードが読み取って画面に反映するエリア があって、 VSYNCを契機とした周期プログラムが、１のエリア情報を元に２のエリアを更新する構成を想定し、１のエリアを共通リソースと考えました。

最初のコードを旧3DS でやってみましたが、T1-T0 は7、秒数は30秒ちょいでした。 ちょっと時間かかりすぎるので、100万ではなく30万にしたところ、T1-T0 が3、秒数が10秒になりました。 で、本題。 メインスレッドとシステム処理、そしてインタプリタとありますが、メインスレッドって10秒もかかってるんです？ なんかイメージ的には、 CPU？ １．メインスレッドがプログラムの内容を実行して、何か表示更新するようなのがあれば、そういう命令を出す ２．VSYNC の更新タイミングが来るまで、インタプリタが実行され、ソースコードを翻訳？する 以下繰り返し ディスプレイとかスピーカーとか、なんか命令受けたところ １．命令を受けたらそれを実行する なんていうイメージがあるんですが……

つまり、 ?"-"*1000000 っていうのはあっという間に計算が終わって、その結果を描画装置？に送信？したら、後は描画がされたかどうかとか気にせずインタプリタを実行しちゃう だから、描画が終わってないのに T1=MAINCNT をやっちゃって、その結果、描画に要する時間と、プログラム中の時間にズレが出る？　みたいな話。

あ、やっぱりメインスレッド(システム処理)で10秒は経過してるのかも。 ちょっと試しに「MAINCNT を60で割って得られる"起動後の秒数(と思われる値)"と、"現在の時刻(TIME$)を秒で表した数"との差分」を求めるプログラムを作成したのですが…… 最初のプログラムを実行するたびに、２つめのプログラムで求められる差分が徐々に拡大していきました。 つまり、MAINCNT っていうのはそんなに正確な経過時間を求められるわけじゃないから、実行時間を測るのには不適切な値って事、なのかなぁ。 (実のところ、何もしなくても10分単位で放置した後に計測すると、やや差分が広がる形でのズレが発生はするのですが、今回の結果には大した影響はないはず）

ダイレクトモードで？"="*1E6って実行すると数秒間画面表示をせずに 待たされた後に画面表示を行い、その直後にOKと表示されます。 文字列を表示用のバッファーに準備する間はその処理に集中しているため MAINCNTのカウントやTIME$の更新が行われていないのではと思います。

maincnt くらい割り込みでカウントしてるんだろうという思い込みがありましたが、単に表示中は maincnt 更新されないという理解でよさそうですね。 ただし time$ は rtc なのでプチコンとは無関係に進みます。time$ が更新されるのが、えーと、どこかのトピにあったような・・・確か通信して取得するとかなので、リアルタイムに time$ が更新されるわけではない。ので更新されるのを待つ wait 60 入れたら 10s 経過してた。 wait 1 t0$=time$:t0=maincnt ? "="*1e6 wait 60 t1$=time$:t1=maincnt ? t1$,t0$,t1-t0 >>output t1$=t0$= 10s t1-t0 = 63 (63/60s = 1+3/60s)

訂正 >表示中は maincnt 更新されない メインスレッド処理中は maincnt 更新されない

> メインスレッド処理中は maincnt 更新されない メインスレッドっつーか。「プチコンの定時処理」は… ・ハードウェアのVSYNC毎に1回割り込み。（おおよそ1/60sec) ・多重割り込みはない。 ・呼ばれるたびにmaincnt更新。 ・15回呼ばれるたびに1回time$更新。 ・GRP/BG/SP/コンソールの更新処理を行う。 ・処理が終わったらインタプリタに戻る。

>処理が終わったらインタプリタに戻る。 インタプリタ実行中しか「定時処理」しないってこと??

インタプリタが動いてなければ 「エディタ」か「ダイレクトモードの入力待ちルーチン」が動いてるんじゃね？

えーと「プチコンの定時処理」==「メインスレッド」ってことかな? メインスレッドが割り込み駆動で動いてる・・というより、割り込み処理そのもの!?! それはヒドイ。 で、多重割り込み禁止により、次の vsync 割り込みが無視ってことね?? よーくわかった(と思う)!!

プチコンとは直接関係ないけど、3DS のOS(?)ってリアルタイム性あるのかな?? project mirai (音ゲー) は、プレイ中ネットワーク切ってるみたいなんだけど、ネットワーク割り込み入るとリアルタイム性なくなる? 他の音ゲーはどうなんだろう???

だからメインスレッドって名称がおかしいと思うんだけど。 まぁ作った人がそういうならメインスレッドなんだろ。 OSのリアルタイム性どうってきかれても、そもそも定量的に言えるもんじゃないだろう。 ハード的には音はもうGBAの時代からDSPとDMAあるし VSYNCもHSYNCもボタン類も割り込みかかるし ネットワークは別チップだし しかもOSは独自仕様でゲーム用なら10ms程度のリアルタイム性が無いとは思えないけど。 ネットワーク切ってんのは電池の問題じゃね。

メインスレッド＝定時処理だとすれば、ゲームハード上の動作としてはとっても素直かもしれない。1/60秒割り込み「しか」ハード割り込みがなかった昔のMSXのような割り切った考え方とも。 で、1/60秒に間に合わない定時処理は、かつてのシューティングゲームの処理落ちのごとく全部遅れると。

最近の動向を知らないので、「ＯＳのリアルタイム性」が何かはわかりません。 古い情報ですが、リアルタイムシステムとかリアルタイム処理と言うときの、リアルタイムとは、「イベントが発生してから、システムに要求される時間内に処理を終える。」ことです。 （時間は実行する処理によって異なります。n/μ/m秒だったり、秒／分／時間だったりします。ものによっては、イベントの発生確率分布がおまけに付いたり、仕事が立て込んできた時（「ふくそう」した時）には、処理しなくて良いと言う条件が付くこともあります。） リアルタイム処理の要求条件を無視したアプリケーションがあれば、リアルタイムＯＳ（よくわかりません）を使ってもリアルタイム処理にならないと思います。 Oskarさんの「割り切った考え方」のおかげで、プチコンのプログラミング（特に試験）が楽になっている場合が多いと思います（個人的な感想）。

>リアルタイムとは、「イベントが発生してから、システムに要求される時間内に処理を終える。」ことです。 んー。ほんのちょっとだけ違うかなぁ。 ずっと昔から情報処理の分野での「リアルタイム」の定義は同じ。 「実行時間(処理時間)の予測がつく」ことをリアルタイム性という。 「そのための機能を提供するOS」をリアルタイムOSという。 あちこちでイベント起きて割り込み入ると実行時間の予測がつかなくなるのでリアルタイム性が失われる、 リアルタイムOSでは割り込み禁止領域を指定できる、 とかそういった感じで使う。 「システムに要求される時間内に処理を終える」ことができなくても、その処理にあとどのくらい時間がかかるのか正確にわかる場合はリアルタイム性が高い。単に「処理速度が足りない」だけ。 WindowsUpdateの「あとxx%」みたいなのがリアルタイム性低いっていう。

>あちこちでイベント起きて割り込み入ると実行時間の予測がつかなくなるのでリアルタイム性が失われる、 わかっているとは思いますが、イベントの発生確率分布がわかっていれば、実行時間の予測は可能ですよね。システムに要求される時間内に処理が終わるかは別問題ですが。

確率分布は確率分布なので、確率分布がわかっていてもそれがブロードならリアルタイム性が低くなる。 確率分布がわかっているかどうかが問題なんじゃなくて「実行時間の予測がつくこと」が「リアルタイム」の意味。 ブロードな確率分布のイベントが起きても、NOPいれて時間調節して実質遅延時間の確率分布をシャープに整えればリアルタイム性は高くなる。 そのかわりにシステムのスループットが減る。 だから特定システムのリアルタイム性を定量的に示すことは可能だけど、 「OSのリアルタイム性」ってのは定量的に言うのは難しい。 その上に載せるシステムの組み方でかわるから。

「リアルタイム性」が、少しわかった気がします。 どうやら、 １）れいさんの言う「リアルタイム性」は、リアルタイムシステムの性能を評価する指標の１つで、 ２）私が言う「リアルタイム」は、リアルタイムシステムの実装方法の１つ という違いがあるようです。 一言でリアルタイムシステムと言っても、自動車のエンジン制御のように高い「リアルタイム性」が要求されるものもあれば、（コンピューターによるシステムではありませんが）チケット販売の行列のように、お客さんからクレームが出なければ、十分リアルタイムシステムとして成り立つものもあります。

今回の現象をまとめると 1. VSYNC 割り込みにより、「メインスレッド」が動く。 2. メインスレッド実行中は VSYNC 割り込みはマスクされる。 3. メインスレッドでは 3-1. maincnt を +1 する 3-2. コンソール処理(print した文字列を実際に画面表示する) などを行い、処理終了すればユーザプログラムの実行に戻る。 通常は 3 の処理は 1/60 秒よりも十分に短い時間で終了する。 ところが、100万文字から成る文字列を print させると、3-2 の処理に 10 秒くらいかかってしまう。この処理中に vsync 割り込みが 600 回くらい発生するんだけど、無視される。その結果 maincnt は 10 秒間に 1 しか増えない。 (世の中のまともな実装では、割り込み内では時間のかかる処理は行いません。その理由は、まさに今回のようなマヌケな現象

が起きないようにするためです。)