約 149,921 件
https://w.atwiki.jp/j_lecture/pages/48.html
並列分散処理入門･･･2年/CS/選択 lecture01 - 07/09/24 lecture02 - 07/10/? lecture03 - 07/10/? lecture04 - 07/10/? lecture01 - 07/09/24 lecture02 - 07/10/? lecture03 - 07/10/? lecture04 - 07/10/? コメントどうぞ♪ 名前 コメント すべてのコメントを見る 担当：mica@管理人 Last Update 2007年10月01日15時21分48秒
https://w.atwiki.jp/othello/pages/40.html
一つの仕事を複数のコンピュータで分けて行おうとする試み 「オセロの試合結果は何通りか？」の問題を解くにあたって一番の問題は時間であるとされる。 Ｎ台のコンピュータで同時に処理をすると、１台の時と比べ、Ｎ倍の速度で処理をすることとなり、 時間を大幅に短縮できる。 しかし、我々にとって大幅な短縮となっても敵は腐っても超大な数、なかなかうまくいかない。 また、分散処理の分野となると、話題に上がれる人が少なくなってくるのも痛恨である。 しかし、このシステムが出来上がれば、さらに今の数手先の棋譜数の出力はいけそうである。 親話題→棋譜数のカウント 156 名無しさん＠３周年 2005/07/03(日) 06 01 27 あるソフトをネットを通してバラまく。このソフトは、 一つの局面から一手すすんだ全ての局面を計算する簡単なソフト。 まず１台のPCからスタートする。一手目はルール上黒f5と決まっているらしいから。 一局目は初期状態からf5に黒をおいた一通りの棋譜となる。 んでこの棋譜を同じソフトが入っている別の任意の一台のPCに送る。 棋譜を送ったら棋譜の情報を消す。 受け取ったPCは受け取った棋譜から二局目を弾きだす。 実際二局目は三通りある。 んでこの三通りの棋譜を今度は三台のPCに一通りづつ送る。 送ったら、棋譜の情報を消す。 以下続ける。 終局の棋譜を受け取ったPCは、この終局の棋譜はソフトネットワーク上 唯一無二なので、「終局の棋譜が来た」 という情報だけで棋譜の情報を消してもいい。 んで何回終局の棋譜が来たかを 代表のサーバーに送って それを足していけば答えがでるんじゃん？ 157 名無しさん＠３周年 sage 2005/07/03(日) 07 13 28 156 既に指摘されているようだが、やっぱり時間が足りないと思われ。適当に概算してみよう。 この場合、木をそのまま辿っていくから可能な状態は 37 によると 10^58。 超大雑把に IPv4 アドレス全域に属するノードが使えるとして 2^32 ≒ 4*10^9。 どんどんノードが増加していくから処理が進む、 というのは典型的なネズミ講発想で残念ながら頭打ちする。 つまりノード全域に盤面が行き渡ってしまえば他に渡せるやつがいなくなるので単位処理あたりに進む 手数はノード数と等しくなると考えて良かろう。結局、探索空間をノード数で分割しただけと考えて良い。 1ノードで 1μs で1手進むとして、1年間に 60*60*24*365*1000*1000 ≒ 3*10^13 進む。 結局全体で 1 年間で 4*10^9 * 3*10^13 = 12 * 10^22。 10^58 を割ってやると 8 * 10^34 年程度ということになる。 ttp //ja.wikipedia.org/wiki/宇宙の終焉 によると 10^14 年 -- すべての恒星が燃え尽きるまでの時間 だそうです。 http //ja.wikipedia.org/wiki/ 175 名無しさん＠３周年 2005/08/24(水) 00 57 39 あ～!!!!!!!!!!! 時間さえあれば!!!!!!!!!!!! UDみたいに分散コンピューティングは使う事は出来ないの？ 176 名無しさん＠３周年 sage 2005/08/24(水) 02 18 16 分散コンピューティングでの予想経過時間 仮定1 コンピュータの速さは平均3GHzとする 仮定2 1クロックで1手探索できるとする 仮定3 173 の慨算が正しいとする 仮定4 コンピュータは常時100億台使えるものとする 結構非現実的な仮定もあるけど、これで計算すると 10^52 / (3*10^9 * 10^10) ≒ 3.3*10^32 [sec] ≒ 1.05*10^25 [年] (´･ω･`)ﾑﾘﾎﾟ 179 名無しさん＠３周年 2005/08/24(水) 09 37 29 こんなんあるよ。 分散すれば何とかなるかも。 ttp //oshiete1.goo.ne.jp/kotaeru.php3?q=1091338 6000 (年) * 365 = 2190000 (日) 約200000台のPCが集まれば、10日か... この専門家の根拠は不明だが。 既出だったらごめんよ。 http //oshiete1.goo.ne.jp/kotaeru.php3?q=1091338 426 256 sage 2006/03/24(金) 21 56 39 http //boinc.oocp.org/indexj.php 以前↑こんなのを見つけたんですが、誰か知ってる人居ます？ 前からこれで何かの分散処理やってみたいなと思ってたんですけど、 苦手なのでまだよく理解してなくて。 こっち方面の得意な方居ますか？ http //boinc.oocp.org/indexj.php 429 名無しさん＠５周年 sage 2006/03/25(土) 14 24 46 426 分散処理って全探索の場合はN台でやってもコストが1/Nにしかならないのよね。 全探索はいまの段階では使ってもまだまだ無理かなぁ。 あともうちょっと！ってところ、つまりあと10000倍くらい計算機が速いと 何かが解けるんだけどなぁという段階になったらいいかもね。 確率的概算値を求めるんなら、確率的分散がいまよりどれくらい抑えられるかな？ 430 256 sage 2006/03/25(土) 15 44 11 429 ふむふむ。参考になります。 僕は序盤の全探索があと4手くらいは多くできるかなくらいで考えてました。 406では大型コンピュータを使って何をするつもりなのかも気になりますね。 453 409 (=200) sage 2006/04/09(日) 12 43 21 以前話されていたグリッドコンピューティングなんだけど、 総手数を「数える」のは１００万台マシンをそろえても本質的な解決にならないよね ってうちの分散処理の教授がいってました(泣 理由は１００万台では１００万倍にしかならないからです(結果をまとめない限り) １００万倍位じゃ数え上げるの無理ですね 757 ：名無しさん＠５周年 ：2009/05/03(日) 06 29 17 520 氏の othello_counter3.cpp をなんちゃって並列化してみますた http //www9.atwiki.jp/othello?cmd=upload act=open pageid=28 file=othello_counter3_multi.cpp (http //www9.atwiki.jp/othello/pages/28.html) といっても単に初期状態を引数指定できるようにしただけ。 ex. ２手目結果から18手まで探索する場合 (２手結果 = 12盤面/回転対称4 = ３問題に分割、あとで結果を４倍しる) ./othello_counter3_multi 00000008 10080000 00000010 08040000 18 result/02-0000.txt ./othello_counter3_multi 00000008 08080000 00000010 10100000 18 result/02-0001.txt ./othello_counter3_multi 00000000 18080000 0000001C 00000000 18 result/02-0002.txt 758 ：名無しさん＠５周年 ：2009/05/03(日) 06 32 11 ex. ３手目結果から18手まで探索する場合 (３手結果 = 56盤面/回転対称4 = 14問題に分割、あとで結果を４倍しる) ./othello_counter3_multi 00000010 08000000 00000008 100E0000 18 result/03-0000.txt ./othello_counter3_multi 00000010 00040000 00000008 1C080000 18 result/03-0001.txt ./othello_counter3_multi 00000000 08040000 00000038 10080000 18 result/03-0002.txt ./othello_counter3_multi 00000000 08040000 00001018 10080000 18 result/03-0003.txt ./othello_counter3_multi 00000010 10000000 00000008 08182000 18 result/03-0004.txt ./othello_counter3_multi 00000010 00000000 00000008 18380000 18 result/03-0005.txt ./othello_counter3_multi 00000010 00100000 00000008 38080000 18 result/03-0006.txt ./othello_counter3_multi 00000000 00100000 00000038 18080000 18 result/03-0007.txt ./othello_counter3_multi 00000000 10100000 00002018 08080000 18 result/03-0008.txt ./othello_counter3_multi 00000018 00000000 00000204 18080000 18 result/03-0009.txt ./othello_counter3_multi 00000014 00000000 00000408 18080000 18 result/03-0010.txt ./othello_counter3_multi 00000014 00000000 00000808 18080000 18 result/03-0011.txt ./othello_counter3_multi 0000000C 00000000 00001010 18080000 18 result/03-0012.txt ./othello_counter3_multi 0000000C 00000000 00002010 18080000 18 result/03-0013.txt 付けてひとりで Quad 実行するもよし、 計算を別の日に分けるもよし、 みんなで分割統治するもよし。 おまいら２ｃｈのちからを見せてくれ 759 ：757 ：2009/05/03(日) 07 11 22 ちなみに３手目から13手目までの探索をテストしてみた結果 (Core2Quad Q6600 2.4GHz) othello_counter3 13手目全棋譜数 18429768516, パス19204, 終了16384 計算時間 74.39秒 othello_counter3_multi x14 13手目全棋譜数 18429768516, パス19204, 終了16384 計算時間(14 jobs @ 1 CPU) 74.62秒 計算時間(14 jobs @ 4 CPU) 17.63秒 なかなかいい感じ。 760 ：757 ：2009/05/03(日) 08 35 40 説明ミスりました。 ex. ２手目結果から18手まで探索する場合 (２手結果 = 12盤面/回転対称4 = ３問題に分割、あとで結果を４倍しる) ./othello_counter3_multi 00000008 10080000 00000010 08040000 17 result/02-0000.txt ./othello_counter3_multi 00000008 08080000 00000010 10100000 17 result/02-0001.txt ./othello_counter3_multi 00000000 18080000 0000001C 00000000 17 result/02-0002.txt ex. ３手目結果から18手まで探索する場合 (３手結果 = 56盤面/回転対称4 = 14問題に分割、あとで結果を４倍しる) ./othello_counter3_multi 00000010 08000000 00000008 100E0000 16 result/03-0000.txt ./(以下略) Ｎ手目結果からＭ手後棋譜を求めたいときは M-N+1 を引数に与える。 757 758 そのままやると19手,20手まで求めようとして止まらなくなるｗ
https://w.atwiki.jp/j_lecture/pages/49.html
並列分散処理入門【演習】･･･2年/CS/選択 lecture01 - 07/09/24 lecture02 - 07/10/03 lecture03 - 07/10/10 lecture04 - 07/10/17 lecture05 - 07/10/24 lecture01 - 07/09/24 課題をやること（汗 lecture02 - 07/10/03 ？ lecture03 - 07/10/10 URLの操作。 SiteSelectorを改造すること。 lecture04 - 07/10/17 ソケットをつかった通信プログラム。 クライアントとサーバーでチャットできる。 課題は、複数のサーバーと１つのクライアントでの操作。 lecture05 - 07/10/24 コメントどうぞ♪ 名前 コメント すべてのコメントを見る 担当：mica@管理人 Last Update 2007年10月17日14時00分21秒
https://w.atwiki.jp/zikken/pages/13.html
machines の作り方 以下のファイルをダウンロードして次のコマンドを実行すると自動的に生きているマシーンのみの machines を作ってくれる. auto_login エラーが起こるときは 以下のコマンドで解決する（かも ~/mpich-1.2.7p1/util/cleanipcs 正しいfd1d.c http //www40.atwiki.jp/zikken?cmd=upload act=open pageid=13 file=fd1d.c 課題1のサンプル taskl1.c 丸写ししちゃダメだよ あってるかは保証しない fd1d_1.c 課題2に関して KEを100倍くらいにするときれいなグラフが取れる
https://w.atwiki.jp/ke-tai7/pages/51.html
作品での並列分散リンク 現実での並列分散リンク 並列分散処理ともいう。複数の分散された処理ユニットが同時並行的に情報処理を行うこと。 詳しくは並列分散処理@wikipedia 「並列分散リンク」検索結果 取得中です。 上へ
https://w.atwiki.jp/ohtaman/pages/14.html
統計・解析 朱雀の杜 (機械学習についてまとめたWiki) http //ibisforest.org/index.php?FrontPage RjpWiki (RについてまとめたWiki) http //www.okada.jp.org/RWiki/ umekoumeda.net (機械学習・統計などについてまとめたノート・ソースコードがある) http //www.cs.dis.titech.ac.jp/~umeda07/ 数理計画法 プログラミング 設計技法 アルゴリズム Hadoopで、かんたん分散処理 (MapReduceの簡単な解説) http //techblog.yahoo.co.jp/cat207/cat209/hadoop/ いま再注目の分散処理技術 @IT http //www.atmarkit.co.jp/fjava/index/index_distributed.html GoogleのMapReduceアルゴリズムをJavaで理解する http //www.atmarkit.co.jp/fjava/special/distributed01/distributed01_1.html イロイロな分散処理技術とイマドキのWebサービス http //www.atmarkit.co.jp/fjava/special/distributed02/distributed02_1.html MapReduceのJava実装Apache Hadoopを使ってみた http //www.atmarkit.co.jp/fjava/special/distributed03/distributed03_1.html クラウド技術の理解を深める Think IT http //thinkit.co.jp/book/2009/09/01/76 クラウド、台頭! ITpro http //itpro.nikkeibp.co.jp/article/COLUMN/20081007/316261/?ST=itproexpo T.Kouya s Webpage 数値計算に関する授業ノートなどが載っている http //na-inet.jp/ Numerical Computation as Software http //na-inet.jp/nasoft/ spring入門 https //www.myeclipseide.jp/modules/contents04/index.php?id=32
https://w.atwiki.jp/j_lecture/pages/29.html
講義一覧 講義名の一覧です。 まだページをつくってないものも多いので要注意。 1年 2年 3年 4年 CS必修 選択 DM必修 選択 1年 微積分学 基礎物理学1 英語表現 英語理解 論理回路 情報科学入門 コンピュータリテラシ 数理リテラシ Java1 プロジェクト 2年 C言語 科学英語 時事英語 Javaによるデータ構造とアルゴリズム（演習も含む） 解析学 ファイナンス理論1 順序回路設計論 コンピュータの構成と設計 コンピュータの構成と設計【演習】 社会と科学1 社会と科学2 法学 形式言語とオートマトン OS OS【演習】 ソフトウェア工学 プログラム設計 プログラム設計【演習】 人工知能 人工知能【演習】 並列分散処理入門 並列分散処理入門【演習】 プロジェクト 3年 ソフトウェア開発の形式学的手法 心理学1 コンパイラ コンパイラ【演習】 ビジネスに求められるコンピュータシステム 言語学1 データベース データベース【演習】 歴史学1 科学史 国際関係論1 Webサービス ソフトコンピューティング テクニカルライティング1 プロジェクト 4年 CS 必修 選択 DM 必修 選択
https://w.atwiki.jp/isikawa232323/pages/42.html
＜１．情報処理システムの種類＞ ①処理形態 名前 概要 例 バッチ処理 データをまとめて処理し結果を一度に得る 請求書の発行や試験の採点 オンライントランザクション処理 取引（トランザクション）が発生したとき一定時間で結果を返す 座席予約や銀行システム リアルタイム制御処理 機械装置をモニタで監視し制御を行う 電力制御やエンジン制御 ＜２．オンラインシステム＞ ①ACID特性・・・データベースを保護するための４つの特性 原子性・・・トランザクション処理が完了(コミット)するかまったく更新されていない(ロールバック)かで終わること 一貫性・・・トランザクション処理の前後でデータの矛盾がないこと 隔離性・・・トランザクションを同時に実行しても異なる順番で実行してもお互い干渉しないで独立処理するこｔｐ 持続性・・・コミットしたトランザクションの結果は維持される ＜３．集中処理と分散処理＞
https://w.atwiki.jp/okoba0119/pages/23.html
コマンドライン引数の処理(python) 分散処理
https://w.atwiki.jp/masurai/pages/66.html
出典 パーソナル百科事典『マスペディア（Masupedia）』 Googleを支える技術 ‾巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ) posted with amazlet at 08.04.23 西田 圭介 技術評論社 売り上げランキング 22 おすすめ度の平均 Googleの分散処理をわかりやすく解説 Amazon.co.jp で詳細を見る メモ・考えたことなど インデクシングやランキングアルゴリズム自体の技術というよりも、それをいかに膨大なWeb空間検索のために利用するか、といった実践的技術の内容が書かれてる 例えば、DB構造とか分散処理のさせ方とか、どのような機器をどのように並列するかとか、コストや消費電力の観点での解決策も載ってる キーワード・キーフレーズ Googleにブラウザからアクセスするとアクセス元にもっとも近いGoogleデータセンタに繋がる ランキングのために PageRank、アンカーテキスト、単語情報（位置、前後関係、など）を利用 Googleのインデックスには億単位のキー⇒リレーショナルデータベースでは性能的に× もっと原始的で、しかし限界まで効率化されたシステムが必要 文字列は全て数値に置き換える⇒DB内で文字列がそのまま重複して保存されるのを回避 多段階構造のデータ構造（BigTable） クローラ：：最もトラブルに遭いやすいシステム。特定サイトにアクセス集中×。応答ない場合等の対処など。DNSがボトルネック⇒内部キャッシュ管理。 インデクシングLexicon：：単語文字列とwordId Barrels：：docIdとその中に含まれるwordId一覧を持つテーブル。分散のためにはwordIdによってテーブルを分割。特定のwordを検索する際には一つのインデックスに負荷が集中してしまい処理分散にならない（初期Google版。現在はBarrelsに代わりShardを使う） Shard：：docIdとその中に含まれるwordId一覧を持つテーブル。Barrelsとの違いは、docIdによってテーブルを分割している点。これによりインデックスあたりのdocIdの数が限られる。特定のwordを検索する際に複数インデックスを並列して検索でき、効率が良い。また、処理するPCの性能によりインデックスあたりのdocIdの数を調整でき、また各インデックスを検索する処理時間の推定も容易などの利点。 Links：：リンク関係。docIdとdocIdのセット 検索処理の流れ（初期型Google) １．検索後をLexicon使いwordIdに変換 ２．wordIdをキーに分散されたShardを調べ、そのwordId含むdocIdリスト得る ３．各インデックスサーバで担当する範囲内でランキングを行う ４．全ての情報を統合し、docIdそれぞれについてのランキングを出す 検索処理の流れ（新型Google) １．検索後をLexicon使いwordIdに変換 ２．wordIdをキーにBarrelsの転置インデックスを調べ、そのwordId含むdocIdリスト得る ３．docIdそれぞれについてランキング計算し並べ替え スケールアップ：：より優れたハードを使う スケールアウト：：ハードの数を増やす Googleでは普及していて安価なハードを大量に並列化する方法 故障してもいいようにソフトウェアで対処⇒UPSやRAID等は不要（H/Wレベルでの信頼性向上はしない） GFS：：GoogleFileSystem。独自の分散ファイルシステム。膨大なデータの通り道。キューとして用いるだけ。更新、修正等できない。ロックもない。 BigTable：：分散ストレージシステム。データベースのような存在。通常のRDBのように行・列ではなく。列の代わりに行キー、コラムファミリーの二種類。行キーは行特定のために用いる。コラムファミリーは複数列になり得て、複数列のうちのどのデータかを指す際にコラムキーを用いる。コラムキーはいくつでも増やすことができ、行によってコラムキーの数が違ってもよい。各セルにはタイムスタンプの概念があり、過去の情報も持つ。３次元的な構造。（詳しくはp90～参照） 開発体制仕事は与えられるものではなく、自分でみつけだす 利用できる言語は限られる(C++,Java,Python）各言語ごとにコーディングスタンダードがある。 アイデア浮かぶ⇒DB登録⇒社員による投票、コメント デモ＆ドキュメント作成を重視 TechTalk：：社内でいつでもプレゼン開ける。デモ見せてPJアピールや、社外エンジニアの講演など TGIF：：Thanks God! it s Friday 自由参加の集会。息抜き、交流。重要な情報交換の場 Googleレジュメ：：担当案件や経歴、得意分野を公開 スニペット：：毎週書く週報 日常的に使うOSはUbuntuを独自カスタマイズしたGoobuntu 大規模DBにはBigtable。それ以外はMySQLを多用。 コメント 名前 コメント 目次 第1章 Googleの誕生 1.1 よりよい検索結果を得るために 1.2 検索エンジンのしくみ 1.3 クローリング -- 世界中のWebページを収集する 1.4 インデックス生成 -- 検索用データベースを作り上げる 1.5 検索サーバ -- 求める情報を即座に見つける 1.6 まとめ 第2章 Googleの大規模化 2.1 ネットを調べつくす巨大システム 2.2 世界に広がる検索クラスタ 2.3 まとめ 第3章 Googleの分散ストレージ 3.1 Google File System -- 分散ファイルシステム 3.2 Bigtable -- 分散ストレージシステム 3.3 Chubby -- 分散ロックサービス 3.4 まとめ 第4章 Googleの分散データ処理 4.1 MapReduce -- 分散処理のための基盤技術 4.2 Sawzall -- 手軽に分散処理するための専用言語 4.3 まとめ 第5章 Googleの運用コスト 5.1 何にいくら必要なのか 5.2 CPUは何に電気を使うのか 5.3 PCの消費電力を削減する 5.4 データセンターの電力配備 5.5 ハードディスクはいつ壊れるか 5.6 全米に広がる巨大データセンター 5.7 まとめ 第6章 Googleの開発体制 6.1 自主性が重視されたソフトウェア開発 6.2 既存ソフトウェアも独自にカスタマイズ 6.3 テストは可能な限り自動化する 6.4 まとめ