![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
総覧・未分類 †
データフロー型 †
島田先生@名大 http://www.shimadalab.nuee.nagoya-u.ac.jp/member/shimada/publication.html ☆[Dennis74](文献1)の計算モデル。 Jack B. Dennis. First version of a data flow procedure language. In "Lecture Notes in Computer Science 19: Programming Symposium", pp 362-376. Springer-Verlag: Berlin, New York, 1974. 入手できない! つーか、LNCS19ってすげーな。 関数は入力により一意に定まり、他の関数の実行結果の影響(副作用)を受けな い→関数型言語向き。 モデルの限界: リンクには常に一つのトークンしか置けない →拡張: 静的計算モデル / 動的計算モデル 静的計算モデル: 発火のためには出力リンクが空である必要がある。 ループは容易に実現できるが、リカーションは無理 動的計算モデル: トークンにタグを持たせる ((u,c,s,i),v) ここで、 u: グラフ実行時のインスタンス c: グラフ内のループ s: 行き先のアクタ(ノード) i: ループの繰り返し回数 タグを操作する命令により、ループ・リカーション・パイプライン計算を 実現 アーキテクチャの話とかもある。 簡単なアーキテクチャ(静的計算モデル)
疑問: 出口が一つという制約はどこから出てきたのかな？ まあ、入力値が異なる同じ関数をどう共有するかって、そりゃむづかしい かもね。 動的計算モデルの場合は、いろいろ複雑かも。 サーベイ論文 †
理論 †実装・評価 †
問題点とか †マクロデータフロー 関数レベルでのデータフロー 【データフローの限界】 履歴依存性のある計算ができない リンク上にトークンがあるかどうかをテストできない(ので同期は受け身) 計算の終了判定のオーバーヘッドが大きくなる 並列にしすぎると待ち合わせ記憶とかカラー？などが足りなくなるので、 並列性を制御したくなっている？ hunga先生のスライド: http://www.am.ics.keio.ac.jp/comparc/others/tsld012.htm EM-4/EM-Xってのもあるようだ。 【データフローマシンの問題点】
【Dennis先生曰く】
が次の課題(と20年前におっしゃっておられた) 論理型 †
ICOT TR(http://www.icot.or.jp/ARCHIVE/Museum/TRTM/tr-list-J.html): 033, 035, 050, 099, 114, 122, 165, 168, 187, 189, 268, 301, 414 ICOT TM(http://www.icot.or.jp/ARCHIVE/Museum/TRTM/tm-list-J.html): 098, 236 神奈川県立川崎図書館にあるらしい… 並列論理 †
関数型 †Reduction Machine †
理研 brainway team †http://www.riken.jp/r-world/research/lab/nokagaku/brain/device/index.html pdf置き場 (メンバー限定) †担当 †
|
