スキップしてメイン コンテンツに移動

2011-03-14

Daily Memo 2011-03-14



  • 松岡先生のtwitterを見ている．主に電力関係で，普段聞けない貴重なコメント．↓ (23:23 JST)

  • ProfMatsuoka/twitter SRのような性能電力効率の悪いスパコンは止めてしかるべきです。Tsubameはラップトップの3倍良いので、止めると同仕事量なら寧ろ悪影響で 不急の同定が先で。@takeshun1984 地震研のeicは止める可能性があるとアナウンス&東大のSRはとりあえず月曜日までは止まって 11:53 PM Mar 13th (23:23 JST)

  • ProfMatsuoka/twitter ここでもう一度、何故TSUBAME2とか京とか性能電力効率が良いスパコンを安易に止めてはいけないか、むしろ節電に協力という意味では状況を悪化させる恐れがあるのか、を述べておきます。 1:04 AM Mar 14th (23:23 JST)

  • ProfMatsuoka/twitter 例えばGreen500の結果からは、高度にGPUチューンされたアプリケーションではTSUBAME2.0はラップトップの3倍、京でも2倍以上の性能電力比を示します。CPUオンリーでも莫大なバンド幅で良い。このあたり細かい議論は色々あるのですが省略します。 1:08 AM Mar 14th (23:23 JST)

  • ProfMatsuoka/twitter 無論多くのアプリは並列化しますが、その場合ユーザも弱スケーリングの範囲で使うことが多いのです。つまりCPU/GPU数を100倍にしたら性能も50-100倍になると。強スケーリングで並列化効率がアララの範囲だと課金でムチャ損するので実際のユーザでは余り見られません。 1:11 AM Mar 14th (23:23 JST)

  • ProfMatsuoka/twitter つまり、もしTSUBAME2.0を停止して、同じジョブをユーザが自分のパソコン等で実行すると、電力効率は最悪で数倍も悪く、あるいは強スケーリング性が多少あるとき問題サイズを小さくして、かつCPUオンリーとかでもTSUBAMEの電力効率を抜くことはラップトップ上でも難しいのです。 1:14 AM Mar 14th (23:23 JST)

  • ProfMatsuoka/twitter じゃあその分問題を小さくしてゆっくり計算を、という話もありますが、積分すれば弱スケーリングならば同じ計算量になるので、結局同じ性能電力効率を仮に達成できてもエネルギー使用量は同じです。今回の様に計画停電が長期化する事態では、ユーザはそう待ってられないので結局は同じ仕事量をする。 1:18 AM Mar 14th (23:23 JST)

  • ProfMatsuoka/twitter つまりせっかくスパコン止めてもユーザが自分のＰＣやクラスタとかで計算してしまって元の木阿弥以上にエネルギー消費する。しかも、結果が出るのはずっと遅くなって研究自身の質も下がる。省電力ではエネルギーｘディレイ積という効率の考えがあるのですが、それが正に増大してしまうわけです。 1:21 AM Mar 14th (23:23 JST)

  • ProfMatsuoka/twitter 現状の我が国のスパコンを鑑みれば、理研RICCより新しいマシンは世の中は確実に得するので止めないほうが良い。仮に計画停電対応以外の理由で止めたとすると、それは単にシンボリックな素人受けを狙った行為で、スパコン技術者としてちゃんとマシンのメトリックを考えていないことが露呈します。 1:24 AM Mar 14th (23:23 JST)

  • ProfMatsuoka/twitter 唯一可能性があるのは、組織運営の長レベルから「スパコンだろうがパソコンだろうがしばらくシミュレーション禁止」令が出ることです。長期化する場合、これの研究組織として強行は世の中それどころではない程ヤバイことになってるか、あるいは「ベンチがｘｘ」な時です。無論後者は東工大ではない筈 1:28 AM Mar 14th (23:23 JST)

  • ProfMatsuoka/twitter だから短期間ならば「スパコンだろうがパソコンだろうが使わない」ですが、でも実際ユーザはそういうニーズを持ってるから、我慢=研究の遅れなわけです。研究機関としてそのような我慢を長期間強いることは結局その研究の否定になる。なので、トップレベルでしか判断できないし、したらアララと。 1:36 AM Mar 14th (23:23 JST)

  • ProfMatsuoka/twitter 勿論世の中研究どころではないなら話は別です。今の福島原発の話は正にそうで、海水注入したら炉はNGになるので経済的損失だけでなくあらゆる面倒な事が起きるがそれは言ってられない危機で、当然トップレベルの判断でそうしてて、多分それは正しいものだった。でも同様の危機がスパコンでは？です。 1:40 AM Mar 14th (23:23 JST)

  • ProfMatsuoka/twitter あと、残念ながら京が稼働するまでは日本の大型スパコンパワーは過去より関東地方に90%ぐらい集中してしまっている(1/2近くがTSUBAME)ので、とても需要はまかないきれないのです。。。RT @__aji 東京電力管区のスパコンユーザを中部以西地域のスパコンに誘導し 12:18 PM Mar 14th (23:23 JST)

  • ProfMatsuoka/twitter やはりインフラはある程度地域分散しかつ分散透過性とそれによる相互のリスクヘッジがないといけない。今回は複数の事象で嫌というほど思い知らされている。スパコンに限ればナショプロが京の神戸の一点集中でなく仕分け後に全国分散のHPCIのサイエンスクラウド(旧グリッド)に発展するのはグー。 1:09 PM Mar 15th (23:23 JST)

  • ProfMatsuoka/twitter いろいろバタバタしましたが、TSUBAME2.0の今後の運用方針が大筋で決まりました。ただ現状は細切れで、かつやるかやらないか曖昧な計画停電に対応するのにスパコンとしての特性が合わず、稼働時間を確保するのに大変苦労しています。フル構成では立ち上げ7-8時間、下げ3時間かかるので。 5:26 PM Mar 15th (23:23 JST)

  • ProfMatsuoka/twitter よって起動時間を3-4時間に高速化するために縮退構成ににして、インタラクティブなノードとストレージの動作だけ今週は保障します。バッチキューも動き出す可能性がありますがいつでもジョブは停止される可能性があります。その分インタラクティブノードを順次増やした構成にしていきます。 5:32 PM Mar 15th (23:23 JST)

  • ProfMatsuoka/twitter このように時間がかかるのはTSUBAMEがデカイことと、連続稼働することで最高性能を確保する構成だからで、PCのような訳にはいかないのです。おまけに交通機関の不安定さでSEやスタッフの時間確保や足の問題もあるので、作業時間帯が限られてしまいます。 5:30 PM Mar 15th (23:23 JST)

  • ProfMatsuoka/twitter ですねえ御社も。しかもTsubameの非運用での損失は得られる学術成果や省エネ効果を加味すれば月一億を超える。簡単に継続運用確保の為の発電機が買える額です。@fumita0818: @ProfMatsuoka 今まさにTSUBAMEでやれることがあるのに本当に悔しいです。 9:42 PM Mar 15th (23:23 JST)

  • ProfMatsuoka/twitter TSUBAME2はインタラクティブノードとストレージのみに縮退運転し、ブート・シャットダウンを7-8時間から3-4時間に短縮化して何とかある程度のサービス時間を確保する作戦。これ以上の短縮はストレージ・Infiniband・管理サーバのブート順があり不可能。これ以下は発電機要。 (23:23 JST)

ラベル:

このブログの人気の投稿

TeXマクロプログラミング

2012.03.30 更新 スライド化しました． 　 新しいマクロ定義 以下に例を示す． \dev\hoge{ほげ} 　 　これにより，\hogeが「ほげ」に変換される．引数を使うには，以下のように記述する． \dev\hour#1{今は#1時です} 　 別の方法 上に示した処理は，以下のようにも記述できる． \newcommand{\hoge}{ほげ} \newcommand{\hour}[1]{今は#1時です} 　 defとnewcommand違い defとnewcommandが異なる箇所として，以下が上げられる． 定義命令を定義している処理系 マクロを多重定義した場合の動作 引数のとり方 　まず，定義されている処理系が異なる．defはtexで定義されており，newcommandは，latexで定義されている． 　次に，多重定義した際の動作が異なる．defでは，新しい定義で上書きする．一方，newcommandではエラーを出力する． 　最後に，defでは，引数のとり方としてパターンマッチングを利用できる．例えば，以下のマクロ定義があるとする． \def\Hatchr(#1,#2)(#3,#4)#5 これにより，以下に示すインターフェイスを実現する． \Hatchr(3,4)(7,8){hoge} 　 マクロの複製 以下の処理では，\hogeの内容を\fugaに複製する． \let\fuga\hoge 　 マクロの初期化 以下のコードで，\hogeを初期化する． \let\fuga\relax 　ここで，\relaxは初期化のために利用する空の定義である． 　 マクロに文字を追加し再定義 defによる定義は，マクロの多重展開をおこなわない．例えば，以下のコードを考える． \def\hoge{ほげ} \def\hoge{\hogeふぇふぇ} 　この後，\hogeを利用すると「\hogeふぇふぇ」と展開される．つまり，一度だけしかマクロは展開されない． 　マクロを展開してから定義する際には，以下の記述を用いる． \edef\hoge{\hogeふぇふぇ} 　これに
続きを読む

beamerでしおりを付ける

しおり 　 しおりとは，acroreadなどでpdfを表示する際に，ウィンドウの左側に表示される目次のようなものである．このしおりを使うことで，文章の構成を大まかに把握したり，特定の項目に移動することが簡単にできる． 　 beamerには，標準でしおりを付ける機能が備わっている．以降では，しおりを付ける方法について述べる． しおりをつける 　 beamerでしおりを付けるには，次のコマンドをtexの文章中に記述する． section{} subsection{} subsubsection{} 　 カッコの中に記述する文字列が，しおりの項目名に使用される．また，section，subsection，subsubsectionを使い分けることで，階層化をすることも可能． 文字化け対策 　 しおりは，標準の仕様ではUnicodeのみがサポートされている．EUCを使う場合は，そのままではしおりの日本語が文字化けする．このため，Unicodeを用いない際には，何らかの対策が必要である． 　 以下では，EUCを利用する人のための対処策を述べる．ここで，dviからpdfを生成する際の方法によって，対処の仕方が異なることに注意する．具体的には，(1)dvipdfmxを用いる場合と，(2)dvipsおよびps2pdfを用いる場合で，対処の仕方が異なる．以降，それぞれについて述べる． dvipdfmxを用いる場合 　 次のコードをプリアンブルに記述しておくことで解決できる．これにより，しおりの部分の文字列が，自動でUnicodeに変換される． \ifnum 42146=\euc"A4A2 \AtBeginDvi{\special{pdf:tounicode EUC-UCS2}}\else \AtBeginDvi{\special{pdf:tounicode 90ms-RKSJ-UCS2}}\fi 　 ただし，実行にはEUC-UCS2というファイルが必要．texをインストールする際に，標準でシステムに入る場合はこのままコンパイルできるが，無ければコンパイルできない．私がこれまで経験したなかでは，Vine 5.0, Mac OSXには含まれているが，Debian lennyには入っていなかった． 　 システムにEUC-UCS2が無い場合，以下のようなサイトから取ってくる．取って
続きを読む

ssh-agentの管理を自動化する

ssh-start.sh ssh-agentの管理を自動化するスクリプトssh-start.shを紹介する． 詳細 ssh-agentを使うことで，sshでリモートログインする際に，パスワードの入力を省略できる． ssh-agentを利用するためには，ソケットのパスとプロセスIDを環境変数に登録する必要がある．環境変数に登録すべき情報は，ssh-agentの起動時に，以下のように標準出力に出力される． $ ssh-agent SSH_AUTH_SOCK=/tmp/ssh-XTqIvn4918/agent.4918; export SSH_AUTH_SOCK; SSH_AGENT_PID=4919; export SSH_AGENT_PID; echo Agent pid 4919; 上記のように，ssh-agentの出力はシェルコマンドとなっており，実行すれば環境変数がセットされる．このため，多くの解説記事では，次のようにevalを用いる方法が述べられている． $ eval `ssh-agent` Agent pid 4919 しかし，この方法は，同じssh-agentのプロセスを複数のシェルから利用することはできない．上記コマンドを他のシェル上でも実行すれば，動作はするが，次の点で優れた手法とは言えない． ssh-agentのプロセスを複数起動する (本来は1個で充分)． 起動毎に秘密鍵の登録，およびパスフレーズの入力が必要となる． 上記の問題は解決するには，1個のssh-agentを複数のシェルから再利用すればよい．例えば2個のターミナルから1個のssh-agentプロセスを利用するには，次のようにする． # terminal 1 $ ssh-agent > ~/tmp.sh $ source ~/tmp.sh Agent pid 4919 # terminal 2 $ source ~/tmp.sh Agent pid 4919 こうすることで，2個のターミナルから同一プロセスのssh-agentを利用できる． 以上の処理を自動化したものが，ここで紹介するスクリプトである． 使い方 環境変数を扱かうため，通常のスクリプトのようには利用できない．このため，sourceコマンドや.(ドット)コマンドで実行する． $ source /path/to/dir/s
続きを読む