アカウント名:
パスワード:
SMPやマルチスレッドや非同期I/Oなどの性能は悪くないと思うんだが。
HPCの分野では, 汎用的なSMP等のスケジューリング性能は全くと言えないまでも, ほとんど関係ありません. 極論を言えばMS-DOS並みの超大粒度タスクスイッチングでも良かったりします. というのも, HPCで要求されるのはTSSやWebシステムの様なレスポンスやリアルタイム性ではなく, 一定の時間内で処理できるタスクを最大にするというトータルスループットだからです. そのためスケジューラの基本戦略としては, 各タスクは計算機資源を占有すると仮定して, 投入されたタスクを順次バッチ的に実行する. 計算機資源を使い切らないタスクについては資源の範囲内で完全並列で実行するという感じになります. 要は主記憶をほとんど占有するようなタスクが複数スイッチングしていたら, HPCとしては使い物にならないってことですね. 実際にはたとえばNQS [kyoto-u.ac.jp]みたいな上物を介していたりすることもあるみたいですし.
IOについてもHPCでは多くのアプリケーションと異なり, 計算ループ1回ごとに大量データのバースト転送ってパターンが多いですし, ハード構成としてもメインフレームと同様の専用の入出力プロセッサを介して行うことになるでしょうから, 汎用的なIO性能では推し量れないでしょう.
結局, HPC向けWindowsの採用ってのは, ある意味変態的な作りこみに対してどれだけのサポートが得られるかってことに尽きると思います.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
ついにゲイツOSに汚染されますか (スコア:-1, フレームのもと)
Re: (スコア:0)
SMPやマルチスレッドや非同期I/Oなどの性能は悪くないと思うんだが。
何も考えずにK&R時代のC標準ライブラリだけでコーディングするのなら、それらの利点はまるで生きてこないので、Linuxでいいと思うが。
Re:ついにゲイツOSに汚染されますか (スコア:2, 参考になる)
HPCの分野では, 汎用的なSMP等のスケジューリング性能は全くと言えないまでも, ほとんど関係ありません. 極論を言えばMS-DOS並みの超大粒度タスクスイッチングでも良かったりします. というのも, HPCで要求されるのはTSSやWebシステムの様なレスポンスやリアルタイム性ではなく, 一定の時間内で処理できるタスクを最大にするというトータルスループットだからです. そのためスケジューラの基本戦略としては, 各タスクは計算機資源を占有すると仮定して, 投入されたタスクを順次バッチ的に実行する. 計算機資源を使い切らないタスクについては資源の範囲内で完全並列で実行するという感じになります. 要は主記憶をほとんど占有するようなタスクが複数スイッチングしていたら, HPCとしては使い物にならないってことですね. 実際にはたとえばNQS [kyoto-u.ac.jp]みたいな上物を介していたりすることもあるみたいですし.
IOについてもHPCでは多くのアプリケーションと異なり, 計算ループ1回ごとに大量データのバースト転送ってパターンが多いですし, ハード構成としてもメインフレームと同様の専用の入出力プロセッサを介して行うことになるでしょうから, 汎用的なIO性能では推し量れないでしょう.
結局, HPC向けWindowsの採用ってのは, ある意味変態的な作りこみに対してどれだけのサポートが得られるかってことに尽きると思います.
Re: (スコア:0)
いや、ループの内側でI/Oすることはあんまりないと思うが…
せいぜいチェックポイントくらいだと思うぞ
Re: (スコア:0)
少なくとも、一般的なアプリケーションとは異なる指標で測ったほうがいいのは確か。
それはそれとして、Windows系統で開発ができるスパコンってのも応用を考える上ではあっても良いと思う。
少なくとも、素のPosixよりはAPIがマトモな面がある。
Re: (スコア:0)
いや、計算ループ1回ごとに大量データのバースト転送をすることが多いってんだから単位も糞もねーよ。
そんなことをすればI/Oバウンドになってしまう。何のためのスパコンなんだか。普通はオンメモリで計算するわい。
I/O担当ノードもlinuxやwindowsが載ってるしね。