Intelが80コアプロセッサを開発、1TFLOPSを越える時代へ 97
ストーリー by kazekiri
へぇ 部門より
へぇ 部門より
JonMoo 曰く、
EETimes Japanの記事によると、 Intelが80コア・プロセッサの開発に既に成功しているようだ。この80コア・プロセッサは、クロック周波数が3.16GHzで、 電源電圧が0.95Vのときに1.01TFLOPSを記録するが、消費電力はわずかに62Wということである。これなら、もう数年内には 手元のデスクトップにテラスケールの計算機ということになるかもしれないが、こんなリソースをどう使えばいいのだろう。
こんなリソースをどう使えばいいのだろう。 (スコア:5, すばらしい洞察)
# 128kBものメモリー・・どう使えばいいんだ、とか。
Re:こんなリソースをどう使えばいいのだろう。 (スコア:3, おもしろおかしい)
ボクらにはWindowsがあるんだから。
これでも処理速度が足らなくなるなんて、直ぐに達成してくれるさ。
fj.jokes出身:
Re:こんなリソースをどう使えばいいのだろう。 (スコア:3, 参考になる)
Intelのプレスリリースにもちょこっと書いてありますが、真っ先に思いつく用途はGPU(GPGPU)ですね。
CPUを思い浮かべると80コアは大量に思えますが、単精度浮動少数の積和演算器が80(x2)と考えれば、現在のGPUよりも少ないくらいです。動作クロックや実行できる命令の種類こそ異なりますが、現在売られているX1950(48 vectorFP)やGF8800(96ScalarFP)にも大量の単精度浮動少数演算器が搭載されていますから。
Intelは2009年にもハイエンドGPU市場に参入すると噂されているので、その土台の一角かもしれません。
Re:こんなリソースをどう使えばいいのだろう。 (スコア:2, すばらしい洞察)
演算能力を使いきるだけのバスとストレージの能力が足りません.
パソコンよりクロック周波数が低いベクトル型スパコンがなぜスーパーなのか考えてみましょう.
余ったコアはBOINCでSETIります (スコア:1)
計算しまくって100パー使ってくれるに違いないと今から楽しみですよ(笑)。
少々真面目な話をするならば、1CPU当り複数コア入っていても1CPUライセンスで
構わないと言ってくれるソフトメーカがリソース全部活用してくれるならば、結構
いいなーとか思う訳ですが。
#目茶目茶身近な案件だとSQL serverなんかかなー。
Re:こんなリソースをどう使えばいいのだろう。 (スコア:1, すばらしい洞察)
どんなにCPUが早くなろうが… (スコア:3, おもしろおかしい)
#特にエロゲに多いような。
Re:どんなにCPUが早くなろうが… (スコア:2, すばらしい洞察)
マルチコアCPUと、それに対応したOSならば、どう頑張ってもコア1つ分を占有する程度で終わるのでは?
Re:どんなにCPUが早くなろうが… (スコア:1)
むやみにスレッドを増やしたあげくに、個々のスレッドが延々ループ処理してたりとかするような
ソフトが出てくるような気がします。
Re:どんなにCPUが早くなろうが… (スコア:1, 参考になる)
Re:どんなにCPUが早くなろうが… (スコア:1, 参考になる)
必要も無いのにループするようなことを言ってるんだと思うけど。
いまどきの言語ならスレッド間の同期のやり方は実行環境が勝手に調整することも多いし、例に挙げるのは向いてないと思う。
#「必須」なのか「よく使われる」のか…
Re:沈黙の美学 (スコア:1)
…んだけど,最近は素直クールも流行だ.
Re:沈黙の美学 (スコア:1)
#きっと複数のコアでループさせたりするよ
=-=-= The Inelegance(無粋な人) =-=-=
Re:どんなにCPUが早くなろうが… (スコア:1)
>#特にエロゲに多いような。
あと、できの悪いMMOとか。
2割のアリは働かない (スコア:2, すばらしい洞察)
--
ソースはソニー?
Re:2割のアリは働かない (スコア:2, 興味深い)
Re:2割のアリは働かない (スコア:2, おもしろおかしい)
ブーストスイッチを押してる間だけ全コアが動作します。
ただし長時間全コア動作させると排熱が追いつかなくなる危険性がありますので
ご注意ください。
メモリ周りに触れられていないのですが (スコア:2, すばらしい洞察)
CPUのキャッシュ内に収まるような物で達成したところで、実際の利用を考えた上での実効速度はぐんと落ちるでしょうし、「ラボ内でこんな事も出来たんだよ」くらいにとらえておいた方が良いのかも。
Re:推測しよう (スコア:5, すばらしい洞察)
320[GFLOPS]/80[core]/1[GHz]=4。
つまり、1つのコアで1クロックあたり4命令のfloat演算を行っている。2つの単精度FPUしかないのに4命令ということは、SIMDか? それも16bitフローティング??
4命令がわかったので、記事中にある動作周波数と演算量を検証してみる。
「約3.1GHz時に1TFLOPS、5.67GHz時に1.8TFLOPS」という記述のこと。
4 * 80[core] * 3.1[GHz] = 992[GFLOPS]
4 * 80[core] * 5.67[GHz] = 1814[GFLOPS]
ここまできれいにスケールしていると、単純に演算器を動かすだけのテストの結果だろうと思われる。
LINPACKどころか、合成ベンチマークでもない可能性大。
Re:推測しよう (スコア:2, すばらしい洞察)
4命令のfloat演算
というのは間違いで、
4float演算
でしょう。一度に2回演算できる命令を呼べば良いんです。
Re:推測しよう (スコア:1)
2FPUなので4FLOP/クロック
「最大8個の命令を同時実行」なのでループジャンプは同時実行でカウントされない。
でもコレだと残り6個の命令スロットはずっと空いてるからもったいないな。
本来ココで整数演算を同時実行できるので、多分ピーク性能と現実的なベンチの差が小さいと思う。
Re:メモリ周りに触れられていないのですが (スコア:4, 興味深い)
コプロセッサのような物だと考えられます。GRAPE-DR [u-tokyo.ac.jp]と競合する分野でしょうか。
なにせ、並列動作できない部分が1%でもあれば、その部分は1/80の能力しか出せないわけで、
実行時間が80倍かかります。
つまり、99%を速度80で実行して、1%を速度1で実行すると、平均速度は45ぐらいです。
半分の性能しか出せていません。
99%を大きく超える効率で、80スレッドを動作させるとすると、このプロセッサ専用に
カリカリにチューニングされたコードを書くしかありません。
科学技術計算向けに、システム毎にコードを書き直すような使い方になると思います。
そうすると、CPUのキャッシュ内に収まるもので評価しても意味がないのではなくて、
キャッシュ内に収まるようにコードを書かなければ意味がないと言う方が適切でしょう。
ではメモリ帯域は関係ないのかというと、そんなことはないです。
メモリ帯域によって、使用できる用途が変わります。
用途によって、必要な演算量とメモリ帯域のバランスが変わるため、
現状だとメモリ帯域が少なく演算量の大きい用途にしか使えません。
具体的には、LINPACKなんかが最適でしょう。実用性はともかく、知名度は高いですし。
個人的には、メモリを3次元に配置しようとしているところが一番興味深いです。
今回の発表ではまだ実現できていないようですが、実現すればメモリ帯域が数十倍に増えて、
用途が一気に広がるのではないかと思います。
当面は技術デモのみかLINPACK用で、3次元メモリの技術が完成したらスパコン用とか
GPU用に使えるのではないでしょうか。
Re:メモリ周りに触れられていないのですが (スコア:2, 興味深い)
ZDNet の記事 [zdnet.com]の方が分かりやすいような気がします。
EETimes の記事だとここまで書かれていないのでちょっと分かりづらいのかもしれませんが、「とりあえずコアを増やせるだけ増やして同時に動かすことが出来るデモ」でしかないと見たほうがいいかと。
こちらの記事中に見られる以下の部分は x86 アーキテクチャ系の汎用プロセッサを指していると思いますが。
Re:メモリ周りに触れられていないのですが (スコア:2, 興味深い)
メモリとの接続は無し。プログラムもデータも全部オンチップメモリのみ。
という事らしいです。どうやらピーク性能そのままって感じですね。
ラボではこのチップの上に貼り付ける、積層メモリのような物を考えているようです。
でも私個人的には、この方向が将来のコンピュータの一つとは考えてます。
メモリが記憶だけしているなんてもったいなくて。
記憶装置と演算装置とついでに配線を兼ねた素子を見てみたいです(…脳細胞?)
Re:メモリ周りに触れられていないのですが (スコア:1)
積層メモリと言っても256kB*80個ですよね。
CellのLSのような物だろうからどちらにせよ外部メモリも付くでしょ。
メッシュを使っている以上CellとかGRAPE-DRみたいなパイプラインを組むのが前提になるのではないでしょうか。
Re:メモリ周りに触れられていないのですが (スコア:1)
Re:メモリ周りに触れられていないのですが (スコア:2, 参考になる)
物を良く知らないから、そういう書き方になったのではなく、知っているが故に書いているのですよ。
Re:メモリ周りに触れられていないのですが (スコア:1)
気になるところです。
#恥の上塗りかも知れないけれど臆病者は嫌いなのでID
Re:メモリ周りに触れられていないのですが (スコア:1, 興味深い)
理論ピーク性能(これ以上はどうやっても性能があがりませんすいませんごめんなさい)
実効性能(LINPACKみたいな特定のベンチマークで実際にこの性能を叩き出しましたすごいだろ)
があって
『実際に1TFLOPS』という記述から後者の話に違いないと想定するのは間違っていなくて
その場合にはキャッシュ間のコヒーレンシ(このプロセッサではデータメモリを持っているようだ)や同期が効いてくるから
実効性能として1TFLOPSを達成したのが命令やデータをキャッシュに収まるようにした特殊なものかもしれないし
さらにみなさんのお手元に届いて使うときの実効性能は数値演算アプリケーションの種類にも依存するから
…ラボの中でこんなことができたんだよと考えておく ことにあながちまちがいはないとおもうのですが
--
っていっしょうけんめい書いていたら余計なものになりそうだけどAC
Re:メモリ周りに触れられていないのですが (スコア:1)
でもなんか非常にキリの良い数値なのが気になるところ.
ちょうど4演算/(コア*サイクル)なんですよね.
先に言っておこう・・・ (スコア:2, おもしろおかしい)
cf. 「メガヘルツの神話」
今や、端末がIntel Mac・・・信じられん。
-- gonta --
"May Macintosh be with you"
これ? (スコア:1)
http://www.intel.com/pressroom/archive/releases/20060926corp_b.htm
Re:これ? (スコア:2, 参考になる)
中身は計算に特化したCPUコア(3KByteの命令メモリ,2KByteのデータメモリ,32個のレジスタ,2つの32bit演算器)の集合体なんだけど
消費電力が少ないのが売りかな。ATIやnVidiaなどのGPUとどっちが使いやすいだろうね。
Re:これ? (スコア:2, 興味深い)
Re:これ? (スコア:1)
Z80コア? (スコア:1, すばらしい洞察)
中には「8080コア」と読んだやつも絶対いるに違いない!
Re:Z80コア? (スコア:1, 興味深い)
元祖8086を8086発よりは現実的だと思うが、何か根本的なことを間違ってる気がしてきた。
Re:Z80コア? (スコア:2, おもしろおかしい)
Re:Z80コア? (スコア:2, おもしろおかしい)
Re:Z80コア? (スコア:1)
問題は、その頃には俺は生きてないってことだ。
Core 2 X68000 (スコア:1, おもしろおかしい)
現在のPCの処理能力って… (スコア:1, すばらしい洞察)
デスクトップも全て3Dで、学習コストと効率を上げたものが出て欲しいし。
Webサーバなんかだと、ちょっと効率悪いプログラムにちょっと人が集まるだけですぐ限界が来るような。
考え方の違いだろうか。
Re:現在のPCの処理能力って… (スコア:2, 参考になる)
だって3次元のデータをそのままではまともに扱えません。
医療機器などで使われている装置でも表示だけでいっぱいですし。
表面だけじゃなくて、中身が詰まった物体を、フツーに扱えるようになるには、
あとどのくらいの性能が必要なんでしょうね。
水ではなく火事になる (スコア:1, おもしろおかしい)
1枚が2枚
2枚が4枚
4枚が8枚
8枚が16・32・64・128・256・512・10……
Re:水ではなく火事になる (スコア:2, おもしろおかしい)
[udon]
消費電力 (スコア:1)
1プロセス1コア (スコア:1)
「1プロセス1コア」が現実になると今の OS の
スケジューラって全部、時代遅れになるんだろうな。
Re:1プロセス1コア (スコア:2, おもしろおかしい)
Re:1プロセス1コア (スコア:1)
ゲームに介入してきたり、とか?
// しまいには「人間、使えねぇ!」などと喚きだして、HAL9000化したりして
Re:昔は無関係。今は、、、。 (スコア:2, 興味深い)
>HDビデオ編集環境が実現できたら素敵ですね。
大丈夫です。今度はメモリーとHDDが足を引っ張ってくれます☆
実際とあるプロジェクトで大きなデータの演算やらせてるのだけど、CPU性能向上のおかげで演算自体は当初から数百倍近く速くなりました。でもデータ量も増えてきており、OSのスワップやらデータの読み込み/書き出しで時間をとられてそれほど全体にかかる時間は減っていません。もちろんやれる事が増えているのは確かなんですけどね~。
#昔:LZHやZipは時間がかかるけどフロッピーに書き出す時には欠かせないんだよな~。(データ量を減らすため。)
#今:LZHやZipは時間がかかるけどUSBメモリーに書き出す時には欠かせないんだよな~。(ファイル数を減らすため。ファイル数が多いほど遅いので。)