fecti
リアルタイムオーディオ処理ライブラリを作製中。ASIOに対応しているので、低遅延なオーディオプログラムを書くことができます。こんなかんじにコードがかけます： int main() { abb::ASIODevice::createInst(new abb::ASIODevice("ASIO4ALL v2")); abb::Sin…
左からNon-blocking Concurrent Queue, Two-lock Blocking Queue, std::queue + boost::mutexです。 縦は、３秒間に５スレッドで同時Push/Popしたカウント。Non-blockingは他の23倍ぐらいのパフォーマンスが出てる。std::queue以外はLockFreeな固定メモリア…
やっと負荷かけても落ちなくなった。詳細書こうかと思ったけどめんどいので適当に概要…結局、freed memoryを参照しても落ちないように自前でメモリ管理をやる必要があったというだけでした。そもそもせっかくLockFreeなコンテナなのに、メモリ管理がlockfree…
まだPPUのみだけど。G4には対応済だったので楽だった。 http://websvn.nyaxtstep.com/viewvc.cgi?view=rev&revision=691
conceptテンプレート習作。RAIIなリソース操作とか。http://websvn.nyaxtstep.com/viewvc.cgi/fecti/trunk/fecti/Utility/FResource.h http://websvn.nyaxtstep.com/viewvc.cgi/fecti/trunk/test/util_FResource/test_FResource.cppgcc -O3で完全にインライ…
Makefile.amの修正は終わった。あとは細かいgcc対応。
スレッドキャンセル機構にバグがあった。修正。実行中のスレッドをcancel()するのは問題ないのだが、既に終了しているスレッドのFThreadクラスインスタンスをcancel()すると既にfreeされたメモリを参照してしまう。原因はスレッドキャンセルのフラグのdelete…
単なるリファクタリングで済むかと思ったのですが、プロトタイプでの問題点が多かったので8割くらい書き直してます。未踏期間中バグが分散libレイヤーに固まっていたので、今回は全てのコードのテストを書くことにしました。(今までは怪しげなところしか組ん…
RPC経由でsin()関数を100回呼び出しにかかるコスト。OmniRPC: 平均528msec libnetdist: 平均380msecという結果になりました。環境： マシンA: Thinkpad X60s C2D L2300 Mem 1GB マシンB: 自作 C2D 6600 Mem 2GB 接続：100M Ethernet
libnetdistという名前はいい加減ダサいので変えようと思う。以下最終報告レポート下書きを兼ねて… 導入が楽 依存ライブラリ少ない・All code written in C++ コンパイルも楽 初期ノード一覧さえあればネットワーク接続可能 かならずしも全ノードがリストに載…
ソースを読み返すたびにボロがでてきて全然先に進まない。困った。
http://www.google.com/notebook/public/17204077664538055246/BDR6MIgoQ1urgmcYiコード書いたのが4月で、実装を殆ど忘れていたので思い出しながら作成。クラス設計が結構酷いことになっているので、リファクタリングが必要。設計が破綻した原因として、グリ…
FRGB::operator+/-系の実装が酷いことになっていた。 //! addition operator FRGBA operator+(const FRGBA& col) const { return FRGBA( r + col.r, g + col.g, b + col.b, a + col.a ); } αチャンネル足してどうする。
悪夢で眼が覚めたのでとりあえずコーディング。 計算物理レポート用プログラム（期日すぎたら公開します） 独自形式SAX風パーサ残りコーディング→libnytr統合 guiclient: シーンデータ拡張子判別＆実装振り分け
複数チャンネル画像のレンダリングに対応中。レンダラ内部処理の対応は大体おわって、残りはクライアントへの転送処理。
速度が重要になる部分以外はテキストベースのプロトコルに作り変えた方がよさそう。
これは困った。COLLADA DOMを使っているのですが、Material数が多いファイルのロードに恐ろしく時間がかかる模様。 10分待ってみても終わりませんでした。仕方ないので独自形式フォーマットをでっち上げる予定。
分散システム： 質優先計算時間予測 計算時間スペック計測 レイ分散 シーン分散 動的ノード管理 物理ベース対応シェーダ： 複数チャンネル出力 シェーダコンパイラ ブロックの実装実装実装 フレームワーク改良 可変光源サンプリング, etc. GUI改良 最適化： …
で落ちる。ということは低負荷で動かしててもある確率で落ちるってことか。std::listをロック機構なしでつかってるのがまずいのかな。std::findをかけるところで落ちてる。 list中の値を変更する動作はあるが、要素の追加削除はないのでロック無しでいけると…
PM訪問が明後日にあるので、デモの準備をしなければならない。とりあえず、今の環境で分散レンダリングのデモをやれるだけやってみようと思う。このままだとぜんぜん見栄えがしないデモになりそうだが仕方がない。ノード負荷モニターとか作っておけばよかっ…
できた。朝5時から今まで作業してたから休憩引いて12時間ぐらいか。昨日から作業してた。久々にCornell Boxをレンダリングして、懐かしい気分。
予想以上に手間取る。今日中に終わるだろうか…
大体できた。残りはスペック表転送と質優先のノード選択アルゴリズム実装。しかし、なんでこんなに複雑化したんだろう。 課題としては、UDP Socket, UDP Messaging, P2P network management, RPC layer, RPC interfaceの分離をちゃんと行うこと。 ノード管理…
質優先最適化の場合はマスターノードのみ有効にして、他のノードはマスターノードに計算を依頼したほうがかえって早いかな。
やっぱりアルゴリズムはそれぞれ共通のインターフェースを持つように設計して、自由に差し替えられるべきだ。実行速度に影響を及ぼさない範囲でどこまで柔軟性を持たせられるか。
明日朝みて問題なかったらこれでいく。いかに計算時間が最小になるように処理を分散してやるか。ノード選択アルゴリズムを２種類に分ける。 質優先計算時間最適化 前提：タスクの粒度が荒い。発信元ノードはマスターノードまたはそのバックアップのみで少数…
さっきコンパイルが通った。テストはまだ。追記：テストも通った。
libcoroutine now builds with autotools. minor fixes for MacOSX fecti MacOSX port 明日午前中に開発環境の移行は完了させたい。
うーん。計算時間予測を導入して最適なスケジューリングを図るっていう基本的なアイデアは同じですね。
kurobox側設定 LAN配線etc.アップルに電話をかけるfecti_netdist開発
