マイクロプロセッサの未来、将来のコンピュータスタイルは ? 57
ストーリー by reo
create the future 部門より
create the future 部門より
Communications of the ACM にて米 Intel の Shekhar Borkar 氏と Andrew A. Chien 氏による "The Future of Microprocessors" という記事が掲載されている (Publickey の記事より) 。
クロック数の向上は数年前から頭打ちとなり、その代わりにマルチコア CPU が台頭してきたのだが、コア数の増大は電力消費量の増大にもつながり、現実的な消費電力を規定するならばコア数と周波数は制限される。この制限の下でどのように性能向上を図っていくかが論じられており、コアに与える役割の模索や、ハードウェアカスタマイゼーションが挙げられている。また効率的な並列化を実現する言語、フレームワーク、ソフトウェアアーキテクチャの必要性についても触れられている。
かつては個人が所有するコンピュータの余剰資源を集約して様々な分散計算を行わせる取り組みが推進されてきたが、十分に高速な伝送を実現できるネットワークが整備されるならば、よく言われることではあるけれども再び集中の時代へと戻っていくのかもしれない。果たして 10 年後、20 年後のコンピュータ利用スタイルはどのような形になっているのだろう。
だが、断るッ!! (スコア:3, 興味深い)
十分高速なＮＷ (スコア:2, 参考になる)
社内イントラですら１０Ｍでないことはザラ。
それもサーバネックならともかくケーブルが腐ってたり…orz
シンクライアントはそれからにしてくれ。
〜後悔先に立たず・後悔役に立たず・後悔後を絶たず〜
10MB/s？10Mbps？ (スコア:1)
T/O
水を飲むと屁(CH4)をこきます
GRAPE-DR (スコア:2)
GRAPE-DRのような斬新的なアーキテクチャが発表されていますが、
当分x86/x64にとって代わられることはなさそうですねえ。Itaniumでさえ..
http://grape-dr.adm.s.u-tokyo.ac.jp/system.html [u-tokyo.ac.jp]
並列化 (スコア:1, すばらしい洞察)
効率的なのはもちろんだけど、あえて「ここは並列で！」なんて指示しなくても良きに計らってくれるくらいでないと、なかなか厳しいと思う。
#pragma omp parallelうねうね。
Re:並列化 (スコア:1)
#Fortranじゃないよ
Re:並列化 (スコア:1)
単純に繰り返しの代わりにスレッドを起こすだけで、結構な問題をカバーできる。
# ループ間の依存関係があるとちょっと工夫しなければならないが。
そのためにはスレッドを簡単に起こす必要があって、スタックやTCBを割り当てたりなんてのでは困る。ではどうするかってーと、昔なつかしのスタックコンピュータならレジスタセットの代わりにスタックを積んでいるので命令一つでスレッドを起動できる。内蔵スタックが溢れたら例外起こしてメモリを割り当てればいい。
スタックコンピュータは連続した命令が非常に強い依存関係にあるというパイプラインによるスーパースケーラとしては致命的な欠点から廃れたのだが、SMTなりSMPなりが前提になるとスレッド間の依存関係がないのでスレッドから順繰りに命令を投入するだけで済む。ゆえにその欠点はまったく問題にならない。それどころか分岐予測やアウトオブオーダ、投機実行などのでかい回路が完全に不要になり、元々回路規模が小さいスタックコンピュータの小ささが際立つようになる。
Re: (スコア:0)
挙げられているメリット程度ならGPUでよくね？
Re:並列化 (スコア:1)
元コメのアーキテクチャでは条件分岐ペナルティがほぼゼロだよ？
特性的にはCPUとGPUの中間みたいな感じになるだろう。
Re: (スコア:0)
C/C++は抽象度が低すぎるから勝手に並列化するのはかえって難しいんですよ。
プログラマの「人間様である俺様がもっとも高速なプログラムを書けるんだ」信仰と、それを支えるC/C++にover optimizeされたハードウェアアーキテクチャのせいでいつまでたってもC/C++支配は終わりそうにありませんが。
Re:並列化 (スコア:2)
Re:並列化 (スコア:1)
手続き型言語は順次実行されるという概念が、並列化を妨げてる気がする。
例えば、C/C++っぽいものを使うにしても。
・並列可能なブロックを二重波カッコで区切る
・ブロック内で、上に記述されている処理が全て実行されるまで待機しなければならない場合、二重セミコロンをつける
とでもしたら、マシになったりしないかなぁ？
例えば
int main(){
foo();
bar();
{{
hoge1();;
hoge2();;
hoge3();
}}
;;
baz();
}
としたら、foo()とbar()と、{{hoge1(), hoge2(), hoge3()の順次実行}}を並列にして、その全てが終わるのを待ってからbaz()を実行する、といったように。
# スレッド分割、順序入れ替えを行うか行わないかはコンパイラ判断で。
1を聞いて0を知れ!
Re:並列化 (スコア:1)
Objective-C + Cocoaだと、ブロック(いわゆるクロージャ)で並列部分を記述してNSOperationQueueに好きなだけ突っ込み、
waitUntilAllOperationsAreFinishedメソッドで待機すればお望みのことが可能ですよ。(Grand Central Dispatch)
フレームワーク側でCPUコア数などを勘案し、スレッドを準備してくれます。
参考リンク
http://decafish.blog.so-net.ne.jp/2008-04-23-1 [so-net.ne.jp]
Re:並列化 (スコア:1)
私の書いたコメントで、最も大切な部分は、ブロックではなく、
明示していない限り、すべての文の実行順序が不定になることです。
何かのライブラリやら組み込みクラスやらを使って、
ユーザが明示的にマルチスレッドにする部分を書くようじゃ、
pthread使うよりは簡単だねってだけの話です。
1を聞いて0を知れ!
Re:並列化 (スコア:1)
Makefile?
Re: (スコア:0)
同意。
method/function callは原則として非同期実行に置き換えていいと思う。
同期が必要な部分だけ宣言すればいい。volatileやcritical sectionがすでにあるんだし。
Re: (スコア:0)
実行順序不定ってものすごく大きいパラダイム変化でしょ，言語にとっては．
その時点ですでに手続き型言語とは別物だと思うし
このコメント [srad.jp]でも言われているけど，
そんなことを後付けで中途半端にやるくらいなら
関数型言語マンセーでいいじゃん
Re:並列化 (スコア:1)
そうかな？
もともと、引数の評価順序みたいに、ごく自然に実行順序不定となるところはC/C++にあったのだから、大きな違いはないと思うよ。
実際にそれを利用して、マルチスレッド化された実行ファイルを出力するコンパイラの実装は、大きく変わるかもしれないけど、
OpenMPみたいなのが作れてるし、それに言語仕様としては実行順序が上から順でも問題ないのだから、段階的に並列度を高めていく方法もとれる。
関数型言語は魅力的だし、ついこないだCはオワコン的なストーリーも出たばっかりだけど、
それでも、C/C++系言語が今のコンピュータ動かす上で、LispやらHaskellやらの関数型言語よりも、大体の場合において効率がいいし、
その状況を変えるほどに革新的な関数型言語の実装が現れない限りは、この状況は続くんじゃないかなぁ。
1を聞いて0を知れ!
Re:並列化 (スコア:1)
手続き系言語で並列実行できるようにする場合のキモは「いかに確実かつ高パフォーマンスに処理をスレッドセーフにできるか」といった所じゃないかな。
簡単な記述で並列実行を指定できるようになっても、それだけじゃ美味しくないというか、
その個々の処理間で並列処理のためのロックだとかそのあたりの問題の方がよっぽど大変というか。
スレッドセーフの自動化といっても安直にデータアクセス全部にロックが入るようではパフォーマンスの低下がひどいことになりそうだし。
そのあたりをちゃんと解析して必要最小限なロックだけで済ませてくれるような処理をコンパイラがやってくれるならうれしいんですけどねぇ…
Re:並列化 (スコア:1)
並列化をするかしないかはユーザに任せないつもりで書きましたが、自動ロックは考えていません。
i++; i++; って書いたとき、iがどうなるかは未定義でいいと思います。
1を聞いて0を知れ!
Re: (スコア:0)
C言語で副作用完了点をまたがず順序に依存した処理を書くと未定義になったり、C++0xのsequenced-before関係が半順序だったりするのはできるだけ並列化を妨げないためなんですよ。
Re: (スコア:0)
.NET Framework 4.0 の Task とかで似たようなことができるんじゃなかったっけ
Re: (スコア:0)
OpenMPのようなもの？
Re: (スコア:0)
なんだそのOccam擬きは！
Transputerって登場が早すぎたんじゃないだろうか？と思うんだな
ちなみにIntelがどんなにがんばってたくさんのCPUコアをオンチップにしてもメモリの帯域が狭くなる一方だとおもうのだ。
バスの多重化でメモリへのアクセス速度が上がらないとどんなにプロセッサを増やしても頭打ちになるからこの方向で技術の華が開くならメモリとバス関係のブレークスルーが絶対必要だと思う。
#CSPってなんではやらないだよう ＞＿＜
#OccamらぶりーなAC
Re: (スコア:0)
スレッド分割や順序入れ替えはコンパイラというか実行時判断になりますが。
Re:並列化 (スコア:1)
と、不定な引数をとる関数を作っておいて、
ってするかな、俺なら。無駄な関数呼び出しは最適化で消えるはず。
……けど、そんなバッドノウハウみたいなテクじゃ、ダメなんだよ。
意識しなくても使ってしまうような記法じゃないと。
1を聞いて0を知れ!
Re: (スコア:0)
逆アセンブリしてループを見つけて、並列化できそうなら自動で命令文書き換えて・・・もちろん俺にはできませんよ(￣ー￣)
Re:並列化 (スコア:1)
むしろ、Intelにがんばってもらって。x86命令デコーダがμオペレーションレベルで自動並列化してくれるのを期待しましょう。
1を聞いて0を知れ!
Re: (スコア:0)
CPUとプログラマブルDSPが統合されて、演算処理内容に応じてCPUとDSPが協調動作してくれると嬉しいかも。
Re: (スコア:0)
理想は脳細胞？ (スコア:1)
記憶装置の階層が単一で不揮発で速度と容量が十分、となって欲しいです。
・記憶と演算の融合
演算装置が大容量メモリを内包するか、個々のメモリ素子が演算機能を持つか、イメージとしては後者で。
と書いてみて思いましたが、この2つ、片方だけ実現する感じでは無いですね・・・
どうプログラミングするか？・・・さぁ（笑）
Re:理想は脳細胞？ (スコア:1)
>記憶装置の階層が単一で不揮発で速度と容量が十分、となって欲しいです。
データがとっちらかって揮発性でど忘れ思い出し時間がかかるし、容量が哀しい脳細胞。
>演算装置が大容量メモリを内包するか、個々のメモリ素子が演算機能を持つか、イメージとしては後者で。
協調性がなく独立して矛盾することを考えるというのが哀しい脳細胞。
>どうプログラミングするか？・・・さぁ（笑）
アプリオリにプログラミングされているらしい。
Re:理想は脳細胞？ (スコア:1)
脳だって短期記憶と長期記憶がある。
そもそも階層がないと組み合わせ爆発で思考すらできない。
容量が大きくなるとｎ個情報の関係はｎ乗で増えるから、階層を増やさないと逆に機能が低下する。
記憶容量の増大はそれ以上のアクセス困難を招くから、記憶と演算の融合どころか更に高機能な記憶システムを必要とする。(ウェブ検索システムみたいな)
the.ACount
Re:理想は脳細胞？ (スコア:1)
キャッシュとかレジスタもメモリ階層の1つですよね。それが必要ないシステムを是非。
分散も集約も、まだ計算機を離散的に意識している… (スコア:1)
分散したり集約したりしながら、徐々に「空間における計算機密度」的なものが増えている気がする。1m3当たりに存在する計算機の量というか…
きっとそのうち、「ここからここまでが1台」的な感じが利用者側には見えなくなるんじゃないかと期待しているのだが…
fjの教祖様
クラウドは集中ではない (スコア:1)
分散と集中、というのは概念的にちょっと微妙な表現ですね。
クラウドは、ものすごく簡単に言えば分散したリソースを統括管理することで高性能で可用性の高いホストマシンとして利用するというシステムです。仮想的とはいえホストが一つのサーバとして見えているのでクライアント側から見ればホスト集中管理に見えますが、サーバ側は分散リソースを統合管理しているというシステムがクラウドなわけです。
クライアントから見て、どのリソースを利用しているのがが雲のようにもやっとしていて見えにくいからクラウドと呼ばれているわけで、ホスト側の本質は分散コンピューティングと変わりません。
まあ、ここで言われてる内容は端末のコア数が消費電力の関係で頭打ちになるからネットワーク越しにCPUリソースを利用することでその制限を回避しようというのが主眼であって、ネットワークの向こう側でリソースを管理する仕組みはどっちでもいい話ですが。
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
より軽いプロセッサと高速プロセッサ (スコア:1)
高速に処理をするプロセッサの２極化すると思われます。
まあ、今もその傾向は見えますが。
コンピュータ、電気がなければタダの箱。 (スコア:1)
タダの箱、電気があってもタダの箱。
Aaron Rashid
ラオ博士に怒られそうだが... (スコア:1)
Ｍ／Ｂは、ＣＰＵブロック、メモリブロック（主記憶とデータは別ね）、
Ｉ／Ｆブロック、バッテリーブロック、を適当にさしても動くように
（それぞれ、ブロックＩＤで通信してください）。グラボブロックは、
多ければ多いほど（パワーＧブロックとか、エコノミＧとか）
Ｍ／Ｂ同士も通信できて... 繋がる繋がる♪
配置の仕方で高速化できたりして、コンテストとかあったり。
そして、やっぱりスネオ見たいなやつもいて...
# 現実的には、１箱に複数のmini-ITXがブレードみたいにささると...
個人レベルでデータロストの可能性を心配しなくていいシステム (スコア:0)
データロストの可能性を個人レベルで心配しなくていいシステムができて欲しい。
ローカルPCのストレージはキャッシュとして機能して、どこのPCからでも
自分の環境およびデータにアクセスできること。
OSやアプリケーションのインストールしたり、アップデートするのは面倒なので、
情報漏洩の危険性を考えなければこれが理想。
Re:個人レベルでデータロストの可能性を心配しなくていいシステム (スコア:1)
これに一票。
とはいえやはり「手元に置いといて他所には置いておきたくないデータ」もあるとは思うので、
「いつでもどこでもオンラインストレージ高速UP/DOWNLOADステーション」（ビコビコーン）が欲しいな。
ステーションと言いつつ、無線でつながればいいんで物理的実態が必要なわけではないんですが。
どっかと契約してWiMAXで繋いで、とか今でも似たようなことはできるんでしょうけど、もうちょい意識せず”ゆびきたす”にできればなぁ、と。
Re: (スコア:0)
Chromebook + Pogoplugですな
ChromeOSはPogoplugサポートがないようですが実現して欲しいものです
俺の勝ちか (スコア:0)
長く使うことを考えて、最近Core i7 2600を買った。4コア8スレッド、3.4Ghz。
周波数を上げることは難しい、コア数増やすことも難しい。
とすると、5年後くらいにやっと、8コア16スレッド、5ghz程度になって、買い替えると性能アップが分かると言うわけだ。
1つのCPUを５年使えるってのは、良いな。今までなかった。
Re: (スコア:0)
もうすでに5年以上使い続けてる。
Re: (スコア:0)
単体スペックはもういいよ (スコア:0)
Clarkdaleレベルで仮想OSの２・３個回せるし。
ボトルネックは回線の金額くらいじゃないかな？
自宅鯖クラウドするには、
最低月1万以上はネット代にしなきゃならん。
ケータイもスマホもPCもMacも鯖も
どこでもつなげられる対価に年間12万って高すぎでしょ。
1/10位にコスト下げて、
ようやく本来の性能限界を使い倒せる時代が来る
ってのが現状な気がします。
並列化の機能追求は、
XeonやOpteronやGPUに任せて、
そろそろコンシューマー向けは、
使い道の適正化へ注力していただきたいもんだ。
Re:単体スペックはもういいよ (スコア:1)
「クラウド」の定義次第だとは思うけど、それは一般的にはクラウドじゃないでしょ。
Re: (スコア:0)
１０年使って１２万の茶碗や１０年使って３０万の腕時計や
１０年使って５０万の財布はなかなか売れないのに
年間１２万の電話代なら払ってもらえるという事実を考慮すれば
商売人が簡単に値下げ方向に向かうようなビジネスをやるとは思えない。
Re: (スコア:0)
> ボトルネックは回線の金額くらいじゃないかな？
> 自宅鯖クラウドするには、
> 最低月1万以上はネット代にしなきゃならん。
同意だけど、電気代忘れてません？
計画停電のおかげで、自宅サーバを全部VPSに移行したら、
過去実績から、回線と電気代で年間50万以上安くなったけど。
＃ 最低と言ってるんで、判ってるとは思いますが。
Re: (スコア:0)