加藤＠ＯＤＮです．

In article <3990340news.pl@insigna.ie.u-ryukyu.ac.jp>, Shinji KONO wrote:
>河野真治 @ 琉球大学情報工学です。
>
>In article <412d9bf8.6984%katoh@pop12.odn.ne.jp>, Hideki Kato <katoh@pop12.odn.ne.jp> writes
>> ＃しかし何で lang.c なの？
>
>(歴史的理由 :-)
>
>> 結局，まだ gc の技術が不十分なんだと思う．
>
>GCの前提って、
>    new は明示的に行う
>    reference は、複製可、持ち運び可
>    reference の消滅は、上書きによって暗黙に行う
>って感じですよね。このあたりの前提が間違っているんじゃないかなぁ。
>あきらかに scalability のない前提って感じでさ。

この辺りもまだ研究が不十分だってことなのかな？　下に書いたコンパイラ
の（自動変数の）レジスタ割り付けなんてトンでもない人月で研究した結
果，ここまで来たんだから，GC（＋言語屋の一部？）の研究者の数を考える
と，まぁこんなものかな，と．

GC の必要性が高まってきた，というか，そう認識されてきたのもつい最近
だし．＃オブジェクト＋マルチスレッド＋弱い実時間性絡みね．

>GCする言語で再利用する工夫をすると余計遅くなるってことは、なんか
>プログラミングに対する制約、あるいは、隠された実行モデルが導入
>されているってことなんだよね。そのあたりが、組込みとかメモリ制約
>が強い場合、あるいは、下位ライブラリでは厳しい。

実装メモリが少ないマシンなら，GC で停まってる時間はかなり短くできる
から，かなりきつい処理でなければなんとかなる事も多いと思うんだけどね
ぇ．．．

昔々，UtiLisp 上のエキスパートシステム on Lisp マシン or Unix box を
プラントの制御に実際に使った例がいくつかあるんですが，下の方はＣや 
FORTRAN で書いたプログラムを realtime task として走らせて，UtiLisp 
とはパイプの類で通信してた様な気がする．GC の時間に関しては，，，確
か，やはり制限がきつくて使いにくいから実時間 GC にして欲しいって要望
は上がってきたけど，全部ではなかったと覚えています（セクションが違っ
たので詳しい事は知らない)．

>> 昔はＣでも register とか書
>> いてたけど，コンパイラとハードが進歩して，そういうのは書かない方が速
>> い（書いても無視される）時代になったよね．河野さんも今さら 
>> register が使いたいとは言わないよね？
>
>ところが最近、復活していて、しかも、aliasing に関するコンパ
>イラ指示みたいなものもあって... 
>
>Linux Kernel 2.6 では、大域変数のレジスタ割当てまで復活して
>いるみたいですね。どれだけ効果があるのか知らんが... 

この二つに関しては，確かに，まだ研究が足りない（今後に期待）ですね．
＃結局コンパイラの最適化とハードとは車の両輪なんだなぁ．．．

>> つらつら考えるに，，一つのアプリケーション（と言うかタスク）にはこ
>> ちょこちょやらないといけないところとと鷹揚に構えてかまわないところが
>> 混在してて，それを一つの言語（と言うか，runtime environment）の上で
>> 走らせてるのが根本的な原因なんだと思う．この辺りにもう一レベル階層を
>> 追加するというのは，実際どうなんだろう？
>
>その階層は、おそらく水平な階層ではないでしょうね。面白いと思うけど。

フラットじゃないのは確かでしょうねぇ．．．OS にも係わる話なんだろう
なぁ．＃最近の OS は良く知らない．

>> ＃昔からあるアイデアでは gc の対象外領域，ってのがあるけど，余り流行
>> ＃らなかった．．．低レベル過ぎるからか？
>
>実は、GC抜き + データ構造の工夫でなんとかなるからかなぁ。メモリ Pool
>なんかはそんなものだし。

そんなに大きくないアプリなら頑張ればなんとかなるのは確かだけど，それ
で思考停止しちゃうのは，なんでも中華鍋で料理するって話と同じだし．
＃何でも箸で済むってのも確かだが．．．名人こそ道具を選ぶ．．．
-- 
Hideki Kato <mailto:katoh@pop12.odn.ne.jp>