Xenを用いた仮想クラスタの構築 - nyaxtのPC作業ログ
記憶から書くので、いろいろ抜けているところがあるかも。 Dom0設定 まず普通にDebian lenny/amd64を導入。 適当にパーティション分け。/dev/sdb ~ /dev/sddは50Gバイトraid用に取って、残りディスクイメージ用LVM。VGはそれぞれのHDDに別に取っておく。 nfs-kernel-serverをRaid0上にセットアップ。共有データストレージとして使う sshdをセットアップ。RSA鍵で認証するようにする。 あとはsmbdとか、開発環境一通り。 いよいよXen lennyのamd64向けxen対応カーネルは現在ない。stableのパッケージも読み込めるように/etc/apt/sources.listに追記、etch版xen kernel導入 apt-get install xen-tools bridgeutils 自前でbridge構築する /etc/
外部イテレータ in ruby - nyaxtのPC作業ログ
標準添付されているGeneratorライブラリを使えばいいみたい。 #!/usr/bin/ruby require 'generator' teststr = 'abcde'.split('') # teststr.each {|c| puts c } g = Generator.new(teststr) puts g.current # => a puts g.next # => a puts g.next # => b puts g.next # => c puts g.rewind.next # => a puts g.next # => b puts g.next # => c puts g.next # => d puts g.next # => e puts g.next # => EOFError うーん。巻き戻しすると最初に戻っちゃうのか。確かにブロックを与えたときcall
2007-08-20
あとで書き直す RSL的シェーダ言語にはちょっと抵抗があるなぁ。 物理的な特性なのか、特殊効果的な強調なのか区別できない、混ざった形で記述されている。 特殊効果的な強調はfirst-ray passでは許されるけど、GI計算で計算が発散する要因になりうる。 アルゴリズム記述と、物質特性の記述がごっちゃになっている レンダリング方程式がシェーダ上に書かれるのはおかしくないか。 eg. illuminance loop 無駄に自由度が高い 最適化を妨げる。再利用性が失われる。etc. RTSL: a Ray Tracing Shading Language Steven G. Parker, Solomon Boulos, James Bigler, and Austin Robinson. To appear IEEE Symposium on Interactive Ray Tracing
2007-04-04
タスク定義をどうするかが問題。なんとかcontinuation（継続）をC++でかけないものか。 必要なのは、いわゆるプログラムカウンタ（＋レジスタ群）の保存と、スタック上のローカル変数データの保持。 FSMモデルならなんとかかけます。（参考：d:id:yaneurao:20040525) 保存が必要なデータはメンバ変数にすればOK。でもこれだとプログラムが恐ろしく汚くなるんだよな。 やりたいことはスタックポインタ入れ替えてsetjmpなんだけど、これのポータブルな実装を自前でやるのは絶望的すぎる。というか例外使ってるプログラムだとどうなるんだっけ？ と、書いてる途中にBinary Hacksに似たようなネタがあったのを思い出す。 ありましたありました。 Portable Coroutine Library http://www.xmailserver.org/libpcl.html GN
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2006-11-28
2006-11-29
