#KOGUROさんはいつだって、「みんなでネタ話としては盛り上がるけど実際に手は出されない」ようなことをサラッとやっちゃう。
しばらくKOGUROさん見ないなーと思ったら大抵なにかを企んでいる。
#Lisp
#すげーー。
#すごい!
#そうです、WebPackです。 >maru
#Spartan-3A スタータキットで動かしています。
#とりあえず実装してみただけで、最適化していないせいか、あんまり速くないんですよね。
#50MHzのクロックで動かしているんですが、(fact 10)の計算でだいたい 100μs くらいかかっていると思います(シミュレータでの結果)
#開始から終了までに183個のインストラクションが実行されているので、1個あたり平均 550 ns くらい。
#ちゃんと調べていないけど、メモリアクセスが 32bit あたり 100ns くらいかかって遅いので、そのせいかも。
#部分継続のネイティブサポートできた(と思う)。ちゃんと動かすのにてこずったけど、実際の変更箇所は小さかった。ただ、話を簡単にするために継続フレームをヒープに動かしているので、性能的にはkahuaで使ってるcall/ccによる実装とあんまり変わらないかも。kahuaコンパチの名前を提供するかどうかはもうちょっと考える。
#あ、ついに部分継続のネイティブサポートですか！？
#scheme #kahua #gauche
#でもたった今、部分継続で遊んでたらSEGVしたのでまだ不完全な模様。
#部分継続ってじつはあんまりよくわかってないんですが、スタックの途中までを持っている継続みたいなもんでしょうか？
#あ、いま WiLiKi の cut-sea さんによる説明を読んだんですが、スタックのある深さから別のある深さまでを差っぴいたものを継続として計算する、ですかね。だるまおとしみたいなイメージ？
#active buffered port table overflow
#初めて見たかも
#たくさん出力ポート使ってるの?
#もし同時にたくさん(256個とか)の出力ポートを開いてないのにそれが出たなら、何らかの理由で使用済ポートの回収が遅れてる可能性があるな。
#virtual portを多用してたら一回のgcでファイルポートのfinalizationが済まないかも。
#(1) できれば使用済ポートをまめにcloseするようにする (2) ポートを開く前に(gc)をいくつか入れてみて様子をみる
#これでport table overflowが出なくなったら、使用済ポートの回収の遅延の問題だと思う。それでも出たら、テーブルのサイズを増やすしかないなあ。
#いや、単に256個のスレッドを起こして、それぞれが別のクライアントソケットを使いたかったのです(負荷生成ツール)。だから挙動としては正しいと思う。
#その上限値は、ビルド時にしか増やせないんですよね?
#このツール用に増やしてビルドし直せばいいのか
#今のところそうです。open file descriptorのデフォルトの上限値くらいの大きさにしとくべきかも。普通1024くらい?
#ほんとはダイナミックに増やすべきなんだけど、面倒なので放置してた。この際実装してしまうって手もある。
#Mac OS Xだとulimit -nは256ですね。NetBSD 5.1RCだと128。だから256って値はデフォルト値としては適正だと思うけど、確かに動的に増やせると嬉しいですね。sys-setrlimitみたいな感じで。
Gauche > Archives > 2010/05/11