視線の直線と物体との交点を求める処理を、別プロセスに切り出して処理させてみます。

さらに次のステップでは、切り出した別プロセスのプログラムをC言語で実装しなおしてみて、高速化を試してみます。 (numbaのお試しは、さらに先延ばし...)

• sock.py を新規追加しました
• serverプロセスの処理とclientがserverに依頼する処理に分かれてます
• cg.py のコマンド引数に use_srv 指定があると、従来と違って次の動作に
• cg.pyからserverの起動をかけて、物体のdataをserverに登録
• rt.pyから視線と物体群との交点をcross.pyの関数使って求める処理の箇所で、替わりにserverに依頼
• serverでは、登録されてるdataについて、こっそりcross.pyを使って交点を求めて結果を返す
• 最後まで処理が終わると、serverに終了を伝えて終了
• serverの終了処理では、過去に返した答が記録してあるので、あんちょこファイルに保存して終了

とまぁ、この段階ではわざわざ別のserverプロセスに分けても、serverで同じcross.pyの処理を呼び出してるので、 遅くなるだけです。

serverで返した交点の答をあんちょこファイルに落としているのがミソで、次回同様に use_srv 指定で起動した場合にserverの動作は

• あんちょこファイルがなければ、上記の use_srv の動作と同じ
• あんちょこファイルがあれば、読み込んで
• 交点を求める依頼がくると、依頼内容は目をつむって、あんちょこファイルの結果を順に返答するだけ

あんちょこファイルを作ったときと同じ設定にしなければ意味ないのですが、 これは、１つの処理時間の基準になります。

同様のserverをがんばってC言語で実装したとしても、 このあんちょこカンニング版の処理時間が上限で、 これ以上短くなる事はまず無いでしょう。

なので、あんちょこを使っても遅ければ、プロセス間通信のオーバーヘッドが大きいので、 素直に従来通り処理した方が、まだ「まし」という事になります。

v20.patch

まずは、従来の処理の場合から。 use_srv 指定の有無による分岐が1つ追加で入ってるので、影響が大きくないか一応確認しておきます。

$ cat v20.patch | ( cd rt ; patch -p1 )

$ cd rt

$ ./cg.py eyep=[0,0,0],200,10 sec=10 data_name=objs name=out_v20/objs_1_2 n=1 init_sec=5 div=2
  :
wh : 76242/76800(99.3%) : total 7m 50.43s : rest 3.41s : 2018/04/12 21:42:35
wh : 76664/76800(99.8%) : total 7m 48.84s : rest 0.83s : 2018/04/12 21:42:34
wh : 76800/76800(100.0%) : fin 7m 48.33s

ふむ。従来通りの処理時間っすね。

では、別serverプロセスを起動する方式で、あんちょこファイルも作ってみます。

$ ./cg.py eyep=[0,0,0],200,10 sec=10 data_name=objs name=out_v20/objs_1_2_s n=1 init_sec=5 div=2 use_srv
  :
wh : 76049/76800(99.0%) : total 9m 12.58s : rest 5.40s : 2018/04/12 23:11:19
wh : 76446/76800(99.5%) : total 9m 10.71s : rest 2.53s : 2018/04/12 23:11:17
wh : 76800/76800(100.0%) : fin 9m 9.07s

$ ls -l xdat
-rw-r--r--  1 kondoh  staff  2636160  4 12 23:58 xdat

同様の画像ができてます。 そして、あんちょこファイル 2.5Mバイト程度。

xdat

別プロセスに分けることで
100 * ( (9*60+9.07) / (7*60+48.33) - 1 ) = 17.23 パーセント低下

続いて、あんちょこファイルでカンニング方式

$ ./cg.py eyep=[0,0,0],200,10 sec=10 data_name=objs name=out_v20/objs_1_2_s2 n=1 init_sec=5 div=2 use_srv
  :
wh : 67446/76800(87.8%) : total 2m 3.53s : rest 15.04s : 2018/04/13 00:02:20
wh : 71625/76800(93.3%) : total 1m 57.40s : rest 7.91s : 2018/04/13 00:02:14
wh : 76800/76800(100.0%) : fin 1m 50.29s

無事、同様の画像ができてます。

ほとんどプロセス間通信のオーバーヘッドだけの状態で
100 * ( 1 - ( 1*60+50.29) / (7*60+48.33) ) = 76.45 パーセント向上

これならserverの処理をC言語でトライしてみる価値がありそうですね。 76.45パーセントのどこまで近づけれるものなのか。

ちなみに、生成した画像ファイルはみな同様に見えますが、、、

$ cd out_v20

$ ls -l *.jpg
total 192
-rw-r--r--  1 kondoh  staff  32282  4 12 21:43 objs_1_2.jpg
-rw-r--r--  1 kondoh  staff  32282  4 13 00:00 objs_1_2_s.jpg
-rw-r--r--  1 kondoh  staff  32282  4 13 00:02 objs_1_2_s2.jpg

$ cmp objs_1_2.jpg objs_1_2_s.jpg 
$ 

$ cmp objs_1_2_s.jpg objs_1_2_s2.jpg 
$ 

$ cd ..

無事、一致しておりました。