kono@ie.u-ryukyu.ac.jp (Shinji KONO) writes:

> そうじゃなくて、
>     unbound な部分 (例えば、大量のルールやDisk/CDから読まれる部分)
>        ある意味で気にしない、あるいは、その部分の遅れは許される
> と
>     bound な部分 (例えば、通信バッファや一時的な領域)
>        ここは気にする
> 
> を分離できないのが困るんです... まぁ、別プロセスとか別マシンに
> するというアプローチはあるんだけど。

なるほど。

たとえばCで分離するとしたら別プロセスにするんでしょうけど、Lispだとプ
ロセスがでかいので気軽にforkしにくいという問題はあるかも知れませんね。

Cでも、同じプロセスでページフォルトとかディスクI/Oとかが起きちゃったら、
リアルタイム性はなくなっちゃいますよね。1つのプロセスにunboundな部分と
boundな部分を混ぜて書くのは無理でしょう?

で、混ぜない(boundな部分だけ)ならLispでもOK、ってのは良いですか?

> heap または garbage 量に比例する時間がかかるとなると、分離し
> たくなるのは当然ですよね。

GCサイクル全体ではヒープに比例しますが、割り当て1回(1バイト)あたりは定
数ですよ。他の言語と比べても全く不利じゃないでしょう。

> > 他の言語でデータ量を考慮して書くことが必須な場合は、Lispででもデータ量
> > を考慮して書いて比べて下さい。
> 
> もちろん、そうするわけなんだけど「再利用部分を自分でやると、GCを
> 持っている言語だと、むしろ遅くなる」とか言われると、何をして良い
> のかが良くわからないです...

再利用を自分でやろうとしなければ良いのでは。自分でやってもGCにまかせて
もオーダーは変わらないし、boundならリアルタイム性が失われることもない。
で、GCにまかせた方が効率が良くなる、と。

ひょっとして、リアルタイムでないGCしか持たない処理系で、リアルタイム処
理をしようという、そもそも無理なことをしようとしているんじゃないかと。

じゃあ、なぜリアルタイムGCを持っている処理系がないんだと言うことになり
ますが… それはUnixやWindowsでGCだけリアルタイムにしても無意味だから。
リアルタイムGCの数%のオーバーヘッドの分だけ損してしまう。

# GCを止めたり、特別なアロケータを使ったりしないでOSを書いて見せればデ
# モンストレーションになりますかね。

                                前田敦司