GPGPU#4

1 ：デフォルトの名無しさん：2009/10/11(日) 19:17:10

GPGPUについて語りましょう

前スレ
GPGPU#3
http://pc12.2ch.net/test/read.cgi/tech/1237630694/

関連スレ
http://pc11.2ch.net/test/read.cgi/tech/1228891105/
http://pc11.2ch.net/test/read.cgi/tech/1206152032/

参考リンク
総本山? gpgpu.org
http://www.gpgpu.org/
OpenCL
http://www.khronos.org/opencl/
NVIDIA CUDA
http://developer.nvidia.com/object/cuda.html
ATI Stream
http://developer.amd.com/gpu/ATIStreamSDK/Pages/default.aspx
GPUをCPU的に活用するGPGPUの可能性
http://pcweb.mycom.co.jp/articles/2005/09/06/siggraph2/

2 ：デフォルトの名無しさん：2009/10/11(日) 19:17:59

ダンゴのために立ててやったぞ
謝罪しろ

3 ：デフォルトの名無しさん：2009/10/11(日) 19:22:45

確かに、ダンゴの謝罪がないと始まらないな
さっさと謝罪しろよ

4 ：デフォルトの名無しさん：2009/10/11(日) 19:58:32

ダンゴが何を書くかではなく、何を書かないかで判断するとGPGPUの経験がないだろｗ

5 ：デフォルトの名無しさん：2009/10/11(日) 20:08:42

専門職に汎用的な仕事を教えてる間に
一般職が専門知識を身につけ始めたでござる

6 ：デフォルトの名無しさん：2009/10/11(日) 20:20:28

結局、Fermi vs Larrabeeとかの前に、GPGPUをなんに役立てるかがわからないと
いうのが前スレからの流れだけど、だれかGPGPUはこれからものすごい必要になると
主張できる人はいないの？

できたらもうやっているって文句言われそうだけどさ。

俺は超並列処理で認識系のアプリがそのうち、コンシューマで必要とされる日がやってくると思う。
例えば、顔認識みたいなののもっともっと高級なやつ。

でも今のGPGPUの流行が、そういうアプリの登場まで続いているという自身はないけど。

7 ：デフォルトの名無しさん：2009/10/11(日) 20:26:46

「超並列処理」って計算量に関するアルゴリズム本の内容が
変わるくらいの変化ってこと？

8 ：デフォルトの名無しさん：2009/10/11(日) 20:38:17

>>7
今以上のすっごい量の並列の処理っていうつもりでいったんだけどさ。
並列の構造がさらに入れ子状になっているようなイメージで。

9 ：デフォルトの名無しさん：2009/10/11(日) 20:42:12

例えばホログラム
何もない空間に立体的に写し出すSF映画でよくみるアレ

10 ：デフォルトの名無しさん：2009/10/11(日) 20:46:16

それは普通に本来の用途じゃね

11 ：デフォルトの名無しさん：2009/10/11(日) 20:49:42

Cell REGZAやPS3次期ファームの新機能の一つに通常動画の立体化があるから
そういう方面をPCで実現するのにGPGPUは向いてる

今のGPGPUは開発環境が右往左往してるから
やりたい事があっても商品化にはあと数年掛かる

12 ：デフォルトの名無しさん：2009/10/11(日) 20:58:12

こんな用途とか

CUDAでウイルス検索が高速化する
http://northwood.blog60.fc2.com/blog-entry-3190.html

13 ：デフォルトの名無しさん：2009/10/11(日) 21:06:43

Nvidiaの方向性見るに、やっぱりGPGPUは本質ではないんじゃないか。
結局目指してるのはメニーコアでの並列処理であって、
グラフィックに特化したものを流用することをGPGPUと呼んでるだけで。
LarrabeeもFermiもスタート地点が違うだけで目指してるものは同じだし。

14 ：デフォルトの名無しさん：2009/10/11(日) 21:13:16

>>9
AMDのGPU部門トップ，Rick Bergman氏が語る「1〜10年後のグラフィックステクノロジー」
http://www.4gamer.net/games/045/G004578/20081001053/

だからこれなんだろ

15 ：デフォルトの名無しさん：2009/10/11(日) 21:27:52

グラフィックスがもっとも近くて、ありえるターゲットだってのはそうだろう。
誰でもまあそうじゃんって感じだよね。ホログラム、レイトレ、3Dテレビとかへの
転用ね。結構、それだけでも儲かるかな?IntelとかNvidiaが今無駄に投資している
様に見えるGPGPU研究費用って、結構その方面で回収できるかな？一般に普及するなら
結構儲かるような気もする。そういう算段をつけてて、やつらは今投資しているんだろうか。

16 ：,,・´∀｀・,,）っ-○○○：2009/10/11(日) 23:28:11

SSE4.2の文字列検索アクセラレーション、あと次のAESアクセラレーションは
対応すればほぼ全てのサーバアプリケーションが恩恵を受ける技術な。

http://www.nvidia.co.jp/object/io_1249982404004.html
ちなみに前スレの6万（笑）はここがソース

17 ：デフォルトの名無しさん：2009/10/11(日) 23:29:57

文字が扱えるようになるなら
爆発的に価値がでるけど

SSE4.2を超える問題領域を扱えないなら
いらんな

18 ：デフォルトの名無しさん：2009/10/11(日) 23:36:28

gnu grepが対応する見込みは？

19 ：デフォルトの名無しさん：2009/10/11(日) 23:43:22

>>16-17
自作自演？

20 ：,,・´∀｀・,,）っ-○○○：2009/10/11(日) 23:45:14

いいのかGREP程度で。


つーか、線形ファイル検索って基本的にストレージネックで拡張命令で云々やっても大して効果ないような。
ストリームに対して複数文字列パターンを同時探索するようなケースが有効。
ウィルス探索もそうだけど、データベースとかがそう

21 ：,,・´∀｀・,,）っ-○○○：2009/10/11(日) 23:54:20

NVIDIAアーキじゃ小回りが利かなくて無駄が生じるようなことを
力任せで何とかなると思って本気で取り組んできたらそれはそれでヤバい構図だぞ

22 ：デフォルトの名無しさん：2009/10/12(月) 01:31:23

文字は、ふつーに使えるだろう。
しかし、そんな大量の文字列を扱うアプリってある？
パターンマッチつっても、
そのために、メインメモリ - GPUメモリ間の転送が無駄すぎる。。

23 ：,,・´∀｀・,,）っ-○○○：2009/10/12(月) 01:39:51

Perlのようなもの

24 ：デフォルトの名無しさん：2009/10/12(月) 04:00:06

昔はメモリだって1GBも何に使うんだ？とか、CPUだって動画見ないから1.3GHzもいらないと思ってたし、同じノリでGPGPUも何かに使えるんじゃないの。
何に使えるかは分からんが。

25 ：デフォルトの名無しさん：2009/10/12(月) 06:25:41

そういや、nvの開発環境って
何の成果がなくても、そのまま貸しといてもらえるもんなの？

26 ：,,・´∀｀・,,）っ-○○○：2009/10/12(月) 10:45:23

返却しろよ

27 ： ◆0uxK91AxII ：2009/10/12(月) 12:27:09

物凄く重い暗号化/復号をGPUで行い、
何かのP2Pなモノでソレを使うとかすれば、
強引に需要を作り出せるかも。

28 ：デフォルトの名無しさん：2009/10/12(月) 12:50:31

そんな需要があるのは割れ厨だけだろ

29 ：デフォルトの名無しさん：2009/10/12(月) 12:52:27

文字列まともに解析できるなら
Winnyなんかのパケットをフィルタするソフトを
GPGPUで作れるから有望なんだけどなぁ

スイッチとかでハード対応するとすぐ1台50万とかになるけど
やっすいPCにGPU挿しておくだけでいいならすごい価値あるんだよなぁ

30 ：デフォルトの名無しさん：2009/10/12(月) 13:55:26

今の環境ってもうかなり成熟してきているよね。メモリが1Gを超えるのが当たり前になってからメモリを必要とすることが少なくなってきたし、HDDも動画集めしない限り、1Tもいらないじゃない。CPUもATOMなんてモノが売れているし。
明かに次代は今までと違う方を向いている様だし、GPUのマーケットは縮小して行くよね？今のままだとIntelだけ残るのかな？

31 ：デフォルトの名無しさん：2009/10/12(月) 14:47:30

>>29
現時点で、現実的に見ると、やはりサーバーへの利用がありえそうなんだね。
処理するデータ量が大きいからやっぱり向いているのか。

その場合って、PCI-EXPRESSがボトルネックにならないだろうか？大丈夫？

32 ：,,・´∀｀・,,）っ-○○○：2009/10/12(月) 15:20:55

>>27
暗号化ってブロック間の依存関係があるからGPGPUは根本的に向かんよ
CPU（のショートSIMD）でやるのが正解。

ECBモード限定か、クラックならまた別だが。

33 ：デフォルトの名無しさん：2009/10/12(月) 17:45:39

物理演算などは並列性が高い処理が多い
科学分野では相当重宝する技術だが一般向けの普及は難しい気がする

もっとも、アルゴリズムそのものを書き換えて、処理を分岐から並列にシフトできるというなら話は別だが

34 ：デフォルトの名無しさん：2009/10/12(月) 17:51:30

えーと、皆さん。
もう少し分かり易く話していただけません？

35 ：デフォルトの名無しさん：2009/10/12(月) 17:55:12

既存の言語にあわせてGPGPU言語を設計すべきなのか
GPGPUに合わせた言語を設計すべきなのか答えって出たんだっけ？

36 ：デフォルトの名無しさん：2009/10/12(月) 17:58:38

>>35
段階を踏まないと厳しいかもしれないね
最初に既存の言語に最適化されたものを作ってから、次にGPGPUに最適化されたものを作っていくしかないと思う

37 ：デフォルトの名無しさん：2009/10/12(月) 18:02:07

GPGPUでのHello Worldは何に該当するの？

38 ：デフォルトの名無しさん：2009/10/12(月) 18:16:44

>>37
CUDA SDKだと一番簡単なのはscalarProdかな

39 ：デフォルトの名無しさん：2009/10/12(月) 18:26:36

scalarProdも2重のループとreductionを使っているから読みにくいね。
SDKにすんなり読めるのはないな。じっくり解読しないといけない。

40 ：,,・´∀｀・,,）っ-○○○：2009/10/12(月) 21:16:17

Fermiのメモリ帯域って256GB/sだろ。
GDDR5のメモリ帯域あたり消費電力って1GB/sあたり0.5Wだから
つまるところメモリ転送だけで最大128W食うわけで・・・

メモリ帯域依存のチップ構成は最早限界。
ローカルメモリの容量を増やしてタイルレンダに移行しないと性能を伸ばしていけない。
読み書き両方可能なL2キャッシュがあるといってもLarrabeeの1/10以下の容量しかない。

レンダリング方式が変わって既存のコードの性能が出なくなることを恐れてるんだろ。
だとすれば結局今までのコード資産に縛られてるのはGPUも同じというわけだ。
GPUの限界を感じた。

41 ：デフォルトの名無しさん：2009/10/12(月) 21:34:38

Radeonじゃ再起関数作るためのレジスタ
機能作れないしGeforceが唯一絶対だろうな

42 ：,,・´∀｀・,,）っ-○○○：2009/10/12(月) 21:37:45

どっちつかずのGeForceだけが唯一絶対死亡な気がする。
どのみちTDPの半分をメモリ帯域で使っちゃうようなマヌケ設計に未来はない。

43 ：デフォルトの名無しさん：2009/10/12(月) 21:51:50

♪CUDAは5年後過ぎにMUDAへと変わるだろう

44 ：デフォルトの名無しさん：2009/10/12(月) 22:14:27

みんなDX11CSに最適化してる最中だな

45 ：デフォルトの名無しさん：2009/10/13(火) 11:38:40

ttp://www.brightsideofnews.com/news/2009/10/12/an-inconvenient-truth-intel-larrabee-story-revealed.aspx?pageid=4

46 ：,,・´∀｀・,,）っ-○○○：2009/10/14(水) 00:26:30

なかなか面白い考察だと思う
ただ、データ帯域を比較するのに全コアL1の帯域を単純合計して云々とかいう
計算法は俺的に好かん。

FLOPSあたりの帯域で見た方が割と面白い事実が見えてくると思う。
たとえば、
Fermiって実はSPあたりのロード・ストア帯域がGT200の半分になってるじゃん糞杉
とかさ

47 ：デフォルトの名無しさん：2009/10/14(水) 00:41:40

はじめてこのスレきたんだが、団子って何者なの？

48 ：,,・´∀｀・,,）っ-○○○：2009/10/14(水) 00:44:38

けだ者だよ

49 ：デフォルトの名無しさん：2009/10/14(水) 00:49:26

他にも、うつけ者とかバカ者とか色々だよね

50 ：デフォルトの名無しさん：2009/10/14(水) 01:00:12

>>48
あんたレス早いよｗ
･･･人のこと言えないか。

51 ：デフォルトの名無しさん：2009/10/14(水) 04:33:07

Industry's first OpenCL GPU and CPU SDK out NOW
ttp://developer.amd.com/GP...

52 ：デフォルトの名無しさん：2009/10/14(水) 04:34:16

ttp://developer.amd.com/GPU/ATISTREAMSDKBETAPROGRAM/Pages/default.aspx

53 ：デフォルトの名無しさん：2009/10/14(水) 04:55:08

まだ諦めてなかったのか

54 ：デフォルトの名無しさん：2009/10/14(水) 06:58:48

Fermiのロード・ストアユニットの詳細ってでてたっけ？
あれってtexture unitじゃないのか？

55 ：デフォルトの名無しさん：2009/10/14(水) 07:35:04

AMDのOpenCL使ってみたけど
やっぱり雪豹より8万分の1の性能しかでない

Radeon 5870 5850 4890 4870 4850 3870
で試してみたけど総じて遅いし話しにならなかった

眠い寝るぉ

56 ：デフォルトの名無しさん：2009/10/14(水) 07:55:41

>>55
どんなソース書いたのか見せて。

57 ：デフォルトの名無しさん：2009/10/14(水) 09:52:17

なんで同世代のカードを複数買ったんだ？馬鹿なのか？

58 ：デフォルトの名無しさん：2009/10/14(水) 11:19:00

友達に協力して貰ったのかもしれないじゃないか
買ったと断定するのは早い

59 ：デフォルトの名無しさん：2009/10/14(水) 11:19:09

NVIDIAはハードウェアのペーパーローンチ、
AMDはソフトウェアのペーパーローンチか。

60 ：デフォルトの名無しさん：2009/10/14(水) 11:23:50

なんで3870〜5870の速さが全部同じの8万分の1になってるんだ？阿呆なのか？

61 ：デフォルトの名無しさん：2009/10/14(水) 12:22:09

そもそもGPUで処理してないから

62 ：デフォルトの名無しさん：2009/10/14(水) 15:47:03

8万の時点で、性能の差じゃないことぐらいわかるだろ

63 ：デフォルトの名無しさん：2009/10/14(水) 16:22:24

性能の差っていうか
作り手がただへぼいだけに

64 ：デフォルトの名無しさん：2009/10/14(水) 17:09:27

>>59
ペーパーロンチ以前にβ版がもう2年続いてますから

65 ：デフォルトの名無しさん：2009/10/14(水) 18:09:43

そもそも3870は対象外じゃないの？

66 ：デフォルトの名無しさん：2009/10/14(水) 18:35:41

>>65
3870も4870も5870もR600ベースのアーキテクチャだから、
処理速度には大きな違いがあるけど命令の互換性には問題無い
3870コアのFireStream9170がGPU初のFP64対応だし

67 ：デフォルトの名無しさん：2009/10/14(水) 18:44:56

>>66
いや、SDKの動作環境見てみれ

68 ：デフォルトの名無しさん：2009/10/14(水) 19:08:50

AMDのOpenCLが遅いのはATi Streamを使わせようって魂胆だろう。
でもそれならみんなNvidiaにいく。

69 ：デフォルトの名無しさん：2009/10/14(水) 21:16:52

Radeon4850買ってきました。
今からubuntu9.04でOpenCLしてみます

70 ：デフォルトの名無しさん：2009/10/14(水) 21:22:59

>>66
670と770には互換性ないぞ。
TｰUnitで実行できる命令が一部削除されてる。

71 ：デフォルトの名無しさん：2009/10/14(水) 22:39:33

v2.0-beta4じゃまだ
OpenCLだとGPU無効になるなぁ
やっぱり2011年度まで待たないと無理だね

72 ：デフォルトの名無しさん：2009/10/14(水) 23:04:35

>>71
ん、SDKのページにあるOpenCL専用ドライバ入れた？
普通のCatalystじゃ動かないよ？

73 ：デフォルトの名無しさん：2009/10/14(水) 23:22:34

>>69
LinuxでRadeon(fglrx)なんてXの起動すらできるか怪しいんだが…

74 ：デフォルトの名無しさん：2009/10/14(水) 23:23:57

>>72
入れてみましたがどこで確認すればいいのですか？
sampleのx86のNBody実行してもCPUしか使わないですよ

75 ：デフォルトの名無しさん：2009/10/14(水) 23:51:51

>>73
何年前の話をしてるんだ？

76 ：デフォルトの名無しさん：2009/10/14(水) 23:56:59

>>75
実際Windows以外じゃ動かないよ

77 ：デフォルトの名無しさん：2009/10/15(木) 00:17:05

Nvidia Geforce 8200M G　でCUDAって可能でしょうか
ttp://www.nvidia.co.jp/object/product_geforce_8200m_g_mgpu_jp.html
ここだとCUDAテクノロジー　無
ttp://en.wikipedia.org/wiki/CUDA
ここだと、対応していると書いてある

どっちが正しいのでしょうか。一昔前のですが
PC買い換えるついでにCUDAも使えるようにしておきたく。

どなたかご存知でしたら教えてください

78 ：,,・´∀｀・,,）っ-○○○：2009/10/15(木) 00:28:05

なんでわざわざ対応してるかどうかもわからない8200MG搭載機をピンポイントで選びたがるんだ

79 ：デフォルトの名無しさん：2009/10/15(木) 00:28:50

>>76
なにが動かないの？

80 ：デフォルトの名無しさん：2009/10/15(木) 00:43:38

ドライバ入れて
AMD Testing use onlyって表示されるようになったけど
N体ちっとも早くないぞ

8万とかにしたらすぐマシン落ちる

81 ：デフォルトの名無しさん：2009/10/15(木) 01:03:39

XP用ドライバのzip壊れてるな・・・

82 ：デフォルトの名無しさん：2009/10/15(木) 01:58:11

ftp://streamcomputing:streamcomputing@ftp-developer.amd.com/ATI%20Stream%20SDK%20v2.0-beta4/ati-opencl-beta-driver-v2.0-beta4-xp.zip

83 ：,,・´∀｀・,,）っ-○○○：2009/10/15(木) 02:41:07

>>54
http://www.4gamer.net/games/099/G009929/20090930012/

84 ：デフォルトの名無しさん：2009/10/15(木) 07:06:43

>>75
phoronix見てこい
いまだに動かないだのOpenGLの動作がおかしいて阿鼻叫喚の図が見られる

85 ：デフォルトの名無しさん：2009/10/15(木) 07:31:46

結論AMDのOpenCL実装はCPUよりも遅い

86 ：デフォルトの名無しさん：2009/10/15(木) 14:08:12

>>84
forumは久々に見たがドライバそのもののトラブルは随分と減ってるじゃないか。
どこが阿鼻叫喚なんだよ。

87 ：デフォルトの名無しさん：2009/10/15(木) 22:57:06

GT300はスクラッチパッドメモリが切り札になりそう

88 ：,,・´∀｀・,,）っ-○○○：2009/10/15(木) 22:59:28

ならねーよ。

SP個数当たりに直してみろ、GT200のそれと何も変わってない。
ロードストアユニットが等速32Wayじゃないから実質スクラッチパッドの性能は退化。

89 ：デフォルトの名無しさん：2009/10/16(金) 00:15:46

GT300の開発者向けサンプル
来月末に送付確定したね

90 ：,,・´∀｀・,,）っ-○○○：2009/10/16(金) 00:35:27

遅っ

91 ：デフォルトの名無しさん：2009/10/16(金) 00:52:07

だんごよララビー信者のお前にそれを言える資格はないと思うがw

92 ：デフォルトの名無しさん：2009/10/16(金) 00:53:06

>>84
ubuntuとかFedoraだけど、現行モデルは動かんよ。
大昔のやつは動くけど、現行の一番古くてショボい(安い)
HD4350刺したら、アナログ接続では使えたが今時の
解像度のモニタに繋ぐと画質の劣化が激しくて、デジタル
(DVI, HDMI)接続だと真っ暗で映らなかった。

とっくに絶版の、まだHDが付かなかった頃のでないとマトモ
に使えない。ATi死ね。

93 ：デフォルトの名無しさん：2009/10/16(金) 00:54:06

ララ兵衛って、www
痛ニウムの二の舞だろ。

94 ：デフォルトの名無しさん：2009/10/16(金) 00:55:50

>>91
LRBより遅いんだがｗｗｗ

95 ：,,・´∀｀・,,）っ-○○○：2009/10/16(金) 01:00:19

いまんとこLarrabeeのスペックは去年公開された通りだしな
どっかのFermiはスループット下方修正しまくりんぐ

96 ：,,・´∀｀・,,）っ-○○○：2009/10/16(金) 01:03:03

>>91
Radeonうめぇｗｗｗｗ


ぶっちゃけGPUとしてはATIで十分だと思うよ。
割り切りが出来ないNVIDIAはただただシェアを失うのみですな

97 ：デフォルトの名無しさん：2009/10/16(金) 01:12:53

AMDのOpenCL実装CPUより遅いのだが
これ意味あるのか？

98 ：,,・´∀｀・,,）っ-○○○：2009/10/16(金) 01:15:32

ないよ。

結局GPU性能が必要な人はGPGPUなんて欲してない。
逆もしかり。

NVIDIAにぴったりな格言があるよ
二兎を追う者は一兎をも得ず

99 ：デフォルトの名無しさん：2009/10/16(金) 01:31:02

しかし2羽の鳥を石ころ一つで落とすことはできるんだなこれが

100 ：デフォルトの名無しさん：2009/10/16(金) 01:34:26

速いだろ。nbodyでn増やせばそれなりに。
それでも会津大のcalで書いた奴よりは大分遅いけど。

101 ：,,・´∀｀・,,）っ-○○○：2009/10/16(金) 01:40:18

ATIの2倍のダイサイズ使って中途半端なもの作るくらいなら
GPUとCPU作ったらどうですか

102 ：デフォルトの名無しさん：2009/10/16(金) 09:05:48

マジキチ

103 ：デフォルトの名無しさん：2009/10/16(金) 09:45:36

>>99
ClarksdaleのGMCH統合でコストダウンとパワードメイン集中管理による電力制御合理化、
さらにはNVIDIA排除ですねわかります

104 ：デフォルトの名無しさん：2009/10/16(金) 09:58:28

将来の統合CPUでのLRBniサポートは既定路線だから
どのみちx86ベースのCPU必要なんだけどね

それともTegraでx86市場破壊の夢でも見るか？

105 ：デフォルトの名無しさん：2009/10/16(金) 15:04:29

ttp://pc.watch.impress.co.jp/docs/news/20091016_322120.html
> 開発コードネーム“Larrabee”(ララビー)で開発を進めているディスクリートGPUについて触れ
> 日本時間の17日に、Larrabeeの性能データを初めて公開することを明らかにした。

CUDA終了のお知らせ？

106 ：デフォルトの名無しさん：2009/10/16(金) 17:40:33

Larrabeeってx86つうところが何とも・・
せめてIA64ベースならまだ許せるんだけど
まぁただの実験でしょ、商売にはならんわな

107 ：デフォルトの名無しさん：2009/10/16(金) 17:56:50

いや、IA64ベースだったら総スカンだろ。

108 ：デフォルトの名無しさん：2009/10/16(金) 18:19:22

IA64とかIntelですら見捨ててるのにｗ

109 ：デフォルトの名無しさん：2009/10/16(金) 18:50:14

さっさとリリースしないと会社が傾く様な状況でもないのに、なんで今なのかね。
Fermiが出てきてからだと霞んでしまうので、
今のうちに旧世代のフラッグシップ(シングルだが)をタコ殴りにして印象付けたかったとか？

110 ：デフォルトの名無しさん：2009/10/16(金) 19:00:05

>>109
B0ステップが出来上がったんでこけら落としだろ。
FermiのスペックはGTX280の2倍にも届いてないのは明らかなんだから
暗黙にFermiに対するプレッシャーになるぞ

111 ：デフォルトの名無しさん：2009/10/16(金) 19:17:52

>>108
x86のおかげでどれだけ生産性が阻害されているのか理解できないの？
旧資産ばかりにたよってちゃだんごみたいな馬鹿になるだけだよ
IA64はコンシューマで流行らなかっただけでなかなかよくできたアーキテクチャだろ

112 ：デフォルトの名無しさん：2009/10/16(金) 19:22:15

理解できてないんだろうから説明してやれば？

113 ：デフォルトの名無しさん：2009/10/16(金) 19:23:13

x86のオーバーヘッドなんて
トランジスタ数の少ない昔と違って
誤差にしかならないだろ。

今時のCPUのトランジスタなんて
マルチコアでも殆どキャッシュが占めている。

114 ：デフォルトの名無しさん：2009/10/16(金) 19:38:03

x86のオーバーヘッドなんて未だに言ってるバカいるんだな
ハイパフォーマンス用途だとアドレッシングモードによる演算密度の高さなど
メリットのほうが大きいんだが。

115 ：デフォルトの名無しさん：2009/10/16(金) 20:02:21

Itanium（笑）

「IA-64」の公式名称も剥奪されて「EPICアーキテクチャに基づく〜」
になって久しいが、実効命令密度も低いし技術的に見るべきところはない。
整理されてるがゆえに閉塞感のある命令セットの代表格。
512ビットはおろか128ビットのSIMD拡張すら入れる余地が無い。

そんなのがなんで出てくるのか理解できない。

116 ：デフォルトの名無しさん：2009/10/16(金) 20:16:23

16バイトも固定で使ってRISC相当命令最大3つなのと、
最大11バイト程度使ってAGU, LSU, VPERM, VPUに
一気にオペレーションを供給できるのと、
どっちが命令セットの効率で優れてるかは明らかでしょう

117 ：デフォルトの名無しさん：2009/10/16(金) 22:27:01

>>116
うまく供給できればな。

お前らみんな間違い。
x86かIA-64が正解なんじゃなくて両方糞。

けれどそれでも他のメーカーが付いて来れないほど
Intelに力と互換性があるからみんな付いていくんだ。

ああAVXとか言ってないでなんちゃらモードとか作って
x86の命令フォーマットを作り直してくれないかなあ。
どうせロングモードでIA-32バイナリは動かないんだから
Intelも抜本的に変えるつもりだったんだろうけどなあ。

118 ：デフォルトの名無しさん：2009/10/16(金) 22:44:33

>>111
その勢いでIntel説得してくれｗ
Poulson早く出せってなｗｗｗｗ

119 ：デフォルトの名無しさん：2009/10/16(金) 22:48:50

>>117
普通に1サイクルでスルーする。

ちなみにお前の理想の命令セットは何よ？
過去のしがらみがない新規の命令セットとか言って鳴り物入りで
登場したCell（笑）とか言いだすなよ

120 ：デフォルトの名無しさん：2009/10/16(金) 22:50:24

> どうせロングモードでIA-32バイナリは動かないんだから

は？
Long modeは64bitネイティブモードとCompatibility(32bit互換)モードの総称だが？
勉強して出直してこい

121 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 00:42:17

Intelが出してるPentiumマイクロアーキテクチャの資料見てて素晴らしいと思ったのは俺だけじゃないはず

122 ：デフォルトの名無しさん：2009/10/17(土) 00:51:25

Larrabeeは2010年のQ4に１00TFlopsの性能だろ
一人勝ちだよな

123 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 00:55:48

x86のパフォーマンス上の障害ってのは浮動小数がスタックベースなのと
レジスタが少ないのと、あと演算が2オペランドだろ

SIMDレジスタ32本＋マスク8本で4レジスタオペランドに拡張したLarrabeeに文句つけるとか
どんだけ贅沢なんだよ

124 ：デフォルトの名無しさん：2009/10/17(土) 01:11:48

貧弱なx86コアに貧弱なSIMD。憤死ｗ

125 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 01:15:39

ぷっ
Larrabeeの多段SIMDを貧弱なんていったら
たった1ワープサイクル2オペレーションしか発行できないFermiは蠅以下ですか？

126 ：デフォルトの名無しさん：2009/10/17(土) 01:19:36

はいはいfermiの１／２程度ですね。

127 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 01:21:56

1SPあたりで見たらLSUやSFUの性能がGT200の1/2程度に落ちてるのがFermiです

128 ：デフォルトの名無しさん：2009/10/17(土) 01:28:37

N厨ｱﾜﾚｗｗｗｗｗｗｗ

129 ：デフォルトの名無しさん：2009/10/17(土) 01:38:46

は？SFUの数は変わってないし。他のロジックとの共有をやめたので効率は上がってるが？

130 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 01:39:21

Fermiってさ
あの巨大なダイの半分以上がテクスチャだのROPだの固定機能ユニットなんだろ
純粋にGPGPUとして使ったときに、役に立たないゴミでしかないんだが
なんでそんなものに拘り続けるの？

その分シェーダのコアの性能強化したほうがいいって発想には至らないの？
ま、LarrabeeはもともとGPUとして失うものがないからその点アグレッシブに
ほぼCPUコアのみにしてきたけどな。

Fermiが1サイクルに2オペレーション捌くところをLarrabeeはピークで
5〜6オペレーション相当捌けるから、効率には相当差ができる

131 ：デフォルトの名無しさん：2009/10/17(土) 01:41:51

ららび512レジスタに対してfermi32768レジスタｗ

132 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 01:46:28

馬鹿だなｗｗｗ
しかもレジスタ本数の計算間違えてるし

まあそのレジスタ本数をスレッド数で割ってみ？
キャッシュが小さいくて読み書きのレイテンシが大きいからスレッドを大量に動かさないと
パイプラインが遊んじゃうんだよ
そんなのは低効率の証明でしかない。

そしてHPCでは何の役にも立たない

133 ：デフォルトの名無しさん：2009/10/17(土) 01:50:12

まあ君みたいに前時代的アルゴリズムと使用用途に固着して時代に取り残されている人にとってはそうでしょうなあ。

134 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 01:53:36

レジスタはメモリみたいにアドレッシングできないし、容量が大きくなると
結局レイテンシが大きくなってしまうので、キャッシュのほうが使い勝手がいいってこともある。
シングルサイクルで読み出せてソースオペランドの一つに使えるLarrabeeの特権だけど。

135 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 01:54:33

>>133←レジスタ大量に載せれば速いなんて前世紀の発想の持ち主の電波をお楽しみください

136 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 02:03:44

スレッド数を大量に動かすことを要求する、すなわち結局1スレッドあたりの性能は悪いって事なんだぜ。
わかるかい？ぼうや。

137 ：デフォルトの名無しさん：2009/10/17(土) 02:04:23

133は間違いなくプログラム書いたことないな。

138 ：デフォルトの名無しさん：2009/10/17(土) 02:12:57

Larrabeeって光プロセッサなんだよね？

139 ：デフォルトの名無しさん：2009/10/17(土) 02:24:05

>>137
レンダリングファーム用プログラム組んでますがなにか？

140 ：デフォルトの名無しさん：2009/10/17(土) 02:26:25

僕はいまファイヤーウォールようのフィルタをCUDAで実装してますが何か？

141 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 02:27:21

Intelからシミュレータも提供して貰えないような自称レンダラ屋が聞いて呆れる

142 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 02:31:56

>>140
ご苦労なこって
ちなみにTeslaが他のHPC用プロセッサに比べて極端に安いのはひとえにメモリにECCが無いからだぞ
ファイアーウォールって結局は信頼性確保のためだろ
本末転倒じゃね？

ちなみにFermiはGT200ベースより倍精度の性能が上がってECC対応になるので
お値段はそれなりに上がる

143 ：デフォルトの名無しさん：2009/10/17(土) 02:34:27

OpenCLで文字列を扱いたいのですが
無理ですかね？

144 ：デフォルトの名無しさん：2009/10/17(土) 02:38:01

>>134
Radeonは少なくともR500の頃から間接アドレッシング出来るぞ。

145 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 02:39:37

文字列処理って可変長でそれほどコンスタントに処理対象データ沸いてくるわけじゃないから
1万とか2万とか処理を並列で動かさないと元が取れないぞ。

GPUのSIMDユニットでで扱うには1バイトのchar型でも4バイト整数に変換して処理するしかない。
その時点でCPUに対する優位性がない。

146 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 02:43:30

>>144
少なくともFusionまでにアーキ変わるのわかってたからRadeonのネイティブはノーマークだっ

147 ：デフォルトの名無しさん：2009/10/17(土) 02:47:17

団子が自分の非を素直に認めるとは
珍しい物を見た

148 ：デフォルトの名無しさん：2009/10/17(土) 02:51:08

非というか、予想以上にAMDがｇｄｇｄったせいで団子の読みが外れたんだろう。
そのFusionが待てど暮らせど出ない上に開発環境が長いこと微妙だったからなぁ。
R600の資料は早めに出てたんだから、始めからILかISAで書くつもりで弄ってればそれなりに遊べたんじゃない？

149 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 02:58:31

LarrabeeってSIMD演算は1クロックに1命令しかデコード・発行できないんだよね。
Store命令はスカラ側のデコーダからでもデコードできるけど
SIMDレジスタよりもL1キャッシュ上のデータを操作したほうが演算密度稼げるという
有る意味で変な仕様。

レジスタ間オペレーションだけなら2オペレーションできるぶんFermiにも勝機は有る。
もっとも、有効な組み合わせがあるかどうかだが
NVCCってレジスタ10何本までとかの制限未だにあるんだろ？
少なくともGT200までのコードはそのまま動かしたらLSUネックで性能出ない構図だよな

150 ：デフォルトの名無しさん：2009/10/17(土) 07:32:16

Innovation@Intel
ttp://www.intel.com/pressroom/innovation/innovation.htm#101609a
ttp://techresearch.intel.com/UserFiles/en-us/File/terascale/Mayo_IEEE_VIS2009_FINAL.PDF

151 ：デフォルトの名無しさん：2009/10/17(土) 08:04:40

>>119
いやAVXでもだいぶマシだよ。
エミュとか作ろうとすれば分かるが、それまでの命令は隣の命令との分離が難し過ぎる。

でも命令が最初から定義し直せるなら
たかがマーキングの為に2バイトも使う事無いよね。
Larrabeeの32レジスタ版は2バイトのマークにもう一つ新設するんだろうか。

>>120
ばーか。
その理論がならCell（笑）にCompatibilityモード付けてもいい事に気づかないか？つーかIA64…
結局今までのバイナリがそのまま動かない、逆を言うとモード切り替えで
互換性保てるようにするなら何やったっていいんだよ。

152 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 10:13:32

デコーダそのものも有る程度後方互換性を持つようにしてるだろ
てか、体系が変わっちまったら互換そのものが足枷になるだろ。
Intel自身が言うように8086の32ビット拡張、64ビット拡張はOpcodeテーブルを
極力再利用する形で行われている。

AVXのマニュアル見てもわかるが、整理したといっても
OpcodeテーブルはSSE*のものをほとんど再利用しているのがわかる。
代わったのは前置バイトだけ。

Opcodeテーブルを増やすことの負担考えて
別の体系のものを用意しろと言ってるんなら、正気じゃねーわ。
余計にデコーダが肥大化する。

153 ：デフォルトの名無しさん：2009/10/17(土) 10:39:44

命令長変わっても命令の実行速度は一定なんだっけ？

154 ：デフォルトの名無しさん：2009/10/17(土) 11:31:37

ララビ速すぎクソワラタ！団子先生大勝利Fermiガチ死亡ってことでファ！！

155 ：デフォルトの名無しさん：2009/10/17(土) 11:44:20

ララビこれ6TFLOPSぐらいでてるじゃん
化け物すぎだろｗ

156 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 11:54:47

>>150の内容まとめ。

>>1よ。お前みたいな奴をみると、あの日のことを思い出すよ。
２００９年１０月１６日。GPGPUの性能が本格的に頭打ちになりかけた日だよ。
転送量が多すぎて、CPU-GPU間の転送帯域がボトルネックになってるって発表されて、
あのときのIntelのTera-Scale Researchチーム、カッコよかったんだぜ。
「総力を結集」ってのはまさにああいう状態だよ。
転送量を１／３に削減しないと律速、ってもんだから、新しいプログラム組んでさ、
そしたらほんの何ヶ月かで完成したんだよ。それが聞いてくれよ、CPUの11倍で
バス帯域律速だったのが、29倍まで高速化しやがったんだよ。
職人技なんてもんじゃねえよ、神技だよ。
でもよ、そうやって頑張る人がいた一方で、「Fermi大勝利」とか駄レスつけてたバカも
いたわけだよ。ちょうど、今のお前みたいにな。
だからよ、俺たちは総力を結集して、お前のバカ度を１／３に圧縮しようと思うよ。
ま、それこそ神技をもってしても無理だろうけどな

157 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 12:17:48

ごめん19倍だ

158 ：デフォルトの名無しさん：2009/10/17(土) 13:16:59

Harpertown1コア12GFlopsだとしてその16コアで10倍って言ったら120GFlopsしか出てないやん。
Larabee得手の処理でこの程度なのか。

159 ：デフォルトの名無しさん：2009/10/17(土) 13:21:06

GPUはそれ以下なんだよね
悲しいね

160 ：デフォルトの名無しさん：2009/10/17(土) 13:28:42

Intelの作ったアプリだから他の所にやらせればまた違う結果が出る。
またもっともパフォーマンス的に優位なケースを選んだろうから他のケースではわからない。

161 ：デフォルトの名無しさん：2009/10/17(土) 13:53:31

心の拠り所は其処だけだなｗｗｗ

162 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 15:15:51

>>158
しかしよ〜
CPU（シングルコア・しかもSIMDなし）の５〜６倍出てマンセーやってるのがGPGPUだろ。
CUDAは不利とは思えんが？むしろCUDAが自称得意と言ってたバイオ・メディカル系
処理分野での「いつも通りの」性能だろ。
効率に振ったらどうなるかの解説としては優秀だろ

まあ可逆圧縮データの展開なんてGPUじゃ無理だろうから、上限はそこまでだろうよ。
そもそもCPU-GPU間のバス律速の境地にすら達してなかったわけで
所詮GPUの効率ってのはそんなもの

163 ：デフォルトの名無しさん：2009/10/17(土) 15:35:17

>>162
GPUは4コアSIMDありの10倍だろ。用途によっては100倍。
Harpertownより新しいNehalem4コアに対してCPU有利？とかほざいてた処理で20倍だよ
http://www.youtube.com/watch?v=8kXDiB1cdDg&feature=related

＞CPU-GPU間のバス律速の境地にすら達してなかった
GTX280で言われてもねぇ。
fermiの場合、特定の処理ではボトルネックになる可能性はあるね。

164 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 15:38:23

ところがどっこい
PCIeの帯域はどのカード刺そうがみんな同じなんです〜

HPC向けにはOpteronでHT-Xでダイレクトに繋げる実装も用意するんだっけ？
それ言ったらIntelもQPIが使えるわけで。

165 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 15:40:45

そもそも問題を選り好みするのは「汎用」とは言えないのでは？
それでよくCPUは不要になるとか言えたものだ。

166 ：デフォルトの名無しさん：2009/10/17(土) 15:45:09

>>164
は？だからfermiで律速に達しちゃうこともあるだろうね。と書いたんだが。
君は馬鹿なのかアホなのかわからない。

>>165
どんな処理でもGPUに勝ってから言えよ。

167 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 15:48:36

オールラウンドで勝たないと駄目なの？
特定の処理にフォーカスするのは特化であり汎化ではない。
可逆圧縮データのデコンプレスが出来るだけでも今までのGPUと比べても十分汎用性があるのでは？

168 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 15:56:31

まあFermiだとVRAM帯域がGT200の1.5倍程度だったりメモリオペレーションが相対的に弱いから
GT200の2倍を確実に下回るでしょ。
そうするとPCIeの帯域飽和しない可能性のほうが大きいと思うよ

倍精度などの強化された処理を除けばGTX295以下だと思っている。

169 ：デフォルトの名無しさん：2009/10/17(土) 16:00:04

とりあえずTeslaはLarrabeeによって死亡確定って事でｗ
GeforceもRadeonに殺されそうだがこのスレ的にはどうでもいいな
CUDAに手を出した奴涙目ｗｗｗｗｗ

170 ：デフォルトの名無しさん：2009/10/17(土) 16:15:15

>>167
その辺はfermi出てみないとわからん。
まあ将来的にデータ圧縮必須になれば30%も演算パワー食われるよりはハードウェアで積めばいい。

>>168
メモリ帯域はGTX295の２倍を上回るだろうしSLIのオーバーヘッドや効率化による性能向上分を考えれば
GTX295の性能を下回ることはまずあり得ない。

171 ：デフォルトの名無しさん：2009/10/17(土) 16:17:58

"GTX295の性能"は"GT200の2倍"ではない（笑）

172 ：デフォルトの名無しさん：2009/10/17(土) 16:18:02

＞メモリ帯域はGTX295の２倍を上回る
ミス
GDDR5 1200MHzならメモリ帯域はGTX295のを上回る

173 ：デフォルトの名無しさん：2009/10/17(土) 16:25:23

>>171
うむだからGTX285の２倍行くかは怪しい。たぶん処理によって順位入れ替わるだろう。
GTX295を下回ることはない。

174 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 16:26:09

＞まあ将来的にデータ圧縮必須になれば30%も演算パワー食われるよりはハードウェアで積めばいい。
キターｗｗｗｗｗ

俺が自作板でﾈﾀで書いた皮肉そのまんまな願望北ｗｗｗ
データフォーマットによって適切なコーデックは異なるんだし、そこはソフトウェアで柔軟性持たせたほうがいいぜ。
ハードウェア実装に向いた可逆圧縮アルゴリズムってどんだけあるのかしら？
その分だけハード載せるの？やめようよそう言うのは。何なの「General Purpose」って。

PCIeの帯域を上回るスループットで圧縮データを展開しないといけないんだぜ。
はっきり言ってIntelのコーデック実装は充分効率いいと言えるのでは？

175 ：デフォルトの名無しさん：2009/10/17(土) 16:29:10

>>174
俺の願望はfermiで圧縮余裕でした。だよ。

176 ：デフォルトの名無しさん：2009/10/17(土) 16:32:09

カスタムリヌクスが動くんだから出来るとおもうんだが
パフォーマンスが不明ゆえ何とも言えん。

177 ：デフォルトの名無しさん：2009/10/17(土) 16:35:40

SLIのオーバーヘッドとか何言ってるんだか。
CUDAからは別々のGPUとしてしか触れないよ。

178 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 16:36:14

そもそもゲームで使うシェーダなんて非プログラマブルハードウェアで定型処理やったほうが
電力効率遙かにいいんだぜ。

でも柔軟性は必要だろ？

179 ：デフォルトの名無しさん：2009/10/17(土) 16:39:36

>>177
そういう話がしたいならGTX295以下とか以上とかの話し出してこないよな。
何を動かしたときかはだいたい想定して書いたんだと思うんだが

180 ：デフォルトの名無しさん：2009/10/17(土) 19:30:26

>>152
うん、だからx86も糞だって言ったの。
それに対して頓珍漢なレスをした>>120が間違いなのであって
世の中理想だけではいかないと言っている団子は間違っていない。

でも度々出すようだけどやっぱSSEのrcpは酷いと思う。
トランジスタを端折る為だけに11bitにするなと言いたい。12bit用意しろ。
今でこそdivが速いからいいが、SSE出た当初は制度を要求する場面で使い物にならなかった。

181 ：180：2009/10/17(土) 19:35:24

同様に、ロングモードやAVXをもっと理想に近づける未来もあったかもしれない。

一つはAMD64の命令フォーマットが糞だった事。
もう一つは省力志向で毎度汎用性の低い方法で継ぎ足し拡張を行うIntel。
色々重なって今があるんだと思う。

182 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 20:42:16

愚者は木を見て森を見ず、ってか

あとから追加する命令が長くなることの何が問題なの？
最初からある命令は、汎用性のある利用頻度の高い命令たり得るわけで（まあ使われなくなった命令もあるが）
1〜2バイトと短くなってるのだから、コード密度は結果的に高いのですよ。

命令キャッシュを大きくするとレイテンシが大きくなるし、外すとパイプラインがストールする。
結局様々な要因でペイできてて妥当なトレードオフなんだよ。
もちろん汚いのは重々承知。

ま、文句があるならx86より性能が出せる俺的最強命令セットを提示してみなさい。

183 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 20:44:09

あと、x86のアドレッシングモードの優位性は散々説明してるので敢えて書かない。

184 ： ◆0uxK91AxII ：2009/10/17(土) 22:44:04

GPGPUが使い物にならないのは、スレの流れから確定的に明らか。

185 ：デフォルトの名無しさん：2009/10/17(土) 22:46:39

>>184
NASAが今注目している分野ですけどね

186 ：,,・´∀｀・,,）っ-○○○：2009/10/17(土) 22:59:02

NASAのニーズは世界市場のニーズとかけ離れてることで有名だが。
8インチのフロッピードライブをネットオークションで買いあさったり。

187 ：デフォルトの名無しさん：2009/10/17(土) 23:30:50

注目しているのはNASAにとって価値がある可能性があるというだけで、
途中で捨てられる可能性も、NASAにしか価値がない可能性もある。

188 ：デフォルトの名無しさん：2009/10/18(日) 01:07:54

成功すればNASAに引き抜かれるかもよ？

189 ：,,・´∀｀・,,）っ-○○○：2009/10/18(日) 01:18:31

先見性のNASAだけは最強

190 ：デフォルトの名無しさん：2009/10/18(日) 01:20:59

誰が上手いことを言えと

191 ：デフォルトの名無しさん：2009/10/18(日) 01:39:52

Larrabeeなんてどうせ注目もされずに消えるんだから
nVidiaとAMDの話しようぜ

192 ：,,・´∀｀・,,）っ-○○○：2009/10/18(日) 03:13:46

現実逃避はCUDAスレでどうぞ

193 ：デフォルトの名無しさん：2009/10/18(日) 08:05:20

アンチインテルを増やしているだけの疫病神

194 ：・´∀｀・：2009/10/18(日) 08:23:40

>>181みたいな断片的な知識でしかものを語れない頭の悪いニワカですねわかります

どうぞどうぞとしかｗｗｗ

195 ：デフォルトの名無しさん：2009/10/18(日) 10:24:06

>>182
誰も長くなる事が悪いなんて一言も書いてないんだけどな。
でもプリフィックスが増え続けるのは愚の骨頂だよね。AVXなんて無くて良かったとでも?

ていうかSSEに関しては最初の命令が酷いんだが。

196 ：｀・∀・´：2009/10/18(日) 12:20:09

やっぱわかってないな。
んで結局不満あるのはSSEだけなんだねｗｗｗ？
MMXが繋ぎだったようにSSEもトランジスタ性能と数が増えるまでの繋ぎなんだからどうでもいいよ
コンシューマPPCのクロック向上を停滞させた主犯がAltiVecと言われてるくらいだし
プロセスルール不相応に高価なSIMD拡張は逆効果だ

勘違いがあるが別にAVXはSSE*よりデコーダに優しいわけではない。
x86みたいな投機的にスキャンする上では冗長プリフィクス形式の方が優しいこともある。

66 0F XXてなコード列になってたとして、1バイトずれてスキャンして0F xxにと誤認してもModRMの検出には支障がない。
ひとつ前の命令の終端が確定してから1バイト戻せばいい。
その意味でVEX形式は冗長バイトがないぶん1バイトたりとも頭出しの失敗が許されないし、
調べないといけないビットフィールドが増えるのでスキャンのアルゴリズムを
根本から変えないといけない。
VZEROALLやVUPPERALLにダミーのModRMすがあるならいいが、無いからよけい大変だよ。
256ビット以上の拡張に備えたフィールドの確保とデスティネーション独立によりMOV命令の削減をねらうのが本質。
規格上1命令15バイトの上限があるんだから無尽蔵にプリフィクスは増やせないしね。
結局いつも通り、フロントエンドのコストかけてでもオペレーション密度をあげるというx86の歴史の繰り返しなんだよね。

197 ：,,・´∀｀・,,）っ-○○○：2009/10/18(日) 20:39:24

したがってVEXフォーマットの場合でも終端判定するにはOpcodeまで含めた3バイトないし4バイト読んで
一括で構造体を解析するしかないわけで
従来SSEでも4バイトまでの一括パターンマッチなら以下のような照合パターンを
用意すれば一括でModRM（あるいは命令終端）を検出できる

0F xx
0F {38,3A}
{66, F3, F2} 0F xx
{66, F3, F2} 0F {38, 3A}
REX 0F xx
REX 0F {38,3A}
{66, F3, F2} REX 0F {38, 3A}

この場合プリフィックスの深さによって、投機的な切り出しで1バイト〜2バイトのミスは許容される

198 ：デフォルトの名無しさん：2009/10/18(日) 21:27:00

アセンブラで書けるような単純な部分はたいていCUDAで爆速になるからな。
無駄な努力ですな。

199 ：デフォルトの名無しさん：2009/10/18(日) 21:58:40

CUDAで速くなる部分って、CPUのコードでアセンブラで
最適化すべき部分のうちのほんの一部のクラスに過ぎないだろ。
圧縮・展開みたいな入出力が可変サイズで、順序が重要なものの扱いは厳しい。

200 ：デフォルトの名無しさん：2009/10/18(日) 22:01:25

それは今あるアルゴリズムの問題だろう
CUDA用の新しいアルゴリズム開発すればいい

201 ：デフォルトの名無しさん：2009/10/18(日) 22:02:21

プログラム書いたことない人登場ｗ

202 ：デフォルトの名無しさん：2009/10/18(日) 22:06:30

不可逆でいい用途なら固定長圧縮は得意だろうが。
S3TCみたいなみたい奴ね。

203 ：デフォルトの名無しさん：2009/10/18(日) 22:09:57

>>199
最適化すべき部分のうちのほんの一部のクラスの実行時間が全体に占める割合次第。
その部分がクリティカルな用途なら効果的なわけで
一般論を語っても無益。

204 ：デフォルトの名無しさん：2009/10/18(日) 22:12:49

要するにN厨はアホ

205 ：デフォルトの名無しさん：2009/10/18(日) 22:12:59

>>200がツボに入ったww

206 ：,,・´∀｀・,,）っ-○○○：2009/10/18(日) 22:16:14

Fermiってアセンブラ使わないとレジスタ足りなくてすぐにL/Sネックになりそうなんだが

207 ：デフォルトの名無しさん：2009/10/18(日) 22:30:22

>>203
いや、一般論じゃなく用途によると言っているだけだよ。

アプリケーションに必要なアルゴリズムの
向き・不向きによってCPUとGPUを使い分けよう、と言うのは共通認識でしょ。

そういう意味でGPGPUが汎用的であればあるほどいいというのは余りに近視眼過ぎる。
汎用性だけで言うなら最新鋭のCPUに勝てるわけ無いから。
物理的な制限がある場合に
高いコストを払って絶対的な汎用性を実現するCPUと、
汎用性を制限する代わりにより高速に演算するGPGPU
どういう演算をどちらに担当させるのが正解かはおそらくまだ誰も知らない。

208 ：,,・´∀｀・,,）っ-○○○：2009/10/18(日) 22:32:24

というか、製品出してから「実は〜に向いてる」なんて言ってる時点で
明確なターゲットなんて無いんだろ。

その時点で効率を追求したストリームプロセッサには負ける。

209 ：,,・´∀｀・,,）っ-○○○：2009/10/18(日) 22:34:06

> 高いコストを払って絶対的な汎用性を実現するCPUと、
> 汎用性を制限する代わりにより高速に演算するGPGPU

GPGPUなんて結局遅いんだからCPUのSIMD命令で全部書かせろ
ってのはあり？

210 ：デフォルトの名無しさん：2009/10/18(日) 22:35:15

2倍遅いというだけで捨てられたアルゴリズムはたくさんあるからな。
そういうのがCUDAで逆転するのはよくある話で。
いろいろやる価値はあるよ。

211 ：デフォルトの名無しさん：2009/10/18(日) 22:36:51

なんでどっちかしか使わないという頭でっかちしかいないの？
汎用的な処理でGPGPUがCPUに勝てるわけないんだから、それぞれ有用な用途に使えばいい

212 ： ◆0uxK91AxII ：2009/10/18(日) 22:37:48

どこぞのゲームの動画を撮影するprogramを書いてみた時、
GPUでのXRGB to YUY2は使い物になるって感じだった。

VRAMから取り出す量が半分になるのが、オイシイ。

213 ：,,・´∀｀・,,）っ-○○○：2009/10/18(日) 22:40:30

並列はCUDAの特権でもないんだけど
むしろベクトル内の横方向の演算が無いのが致命的。
たとえばSSE2のPSHUFDみたいなオペレーション無いだろ。

メモリにストアしてロードでしか要素の入れ替えできないんじゃスループット稼げるはずもなく。
（特にFermiはロード・ストアがネックだし）
そのへんがSIMDとしての活用の幅を狭めてる。

214 ：デフォルトの名無しさん：2009/10/18(日) 22:41:59

gpuが得意とする演算は、基本的に一次変換とビット演算でしょ？
さらにフーリエ変換のライブラリが使えるんだから
そういう方向でアプリケーションを考えたらいい。
衝突演算のボードを追加したら、応用範囲は相当広い。
ビジネスアプリケーションに向くとは思わないが。

215 ：デフォルトの名無しさん：2009/10/18(日) 22:46:55

同一warp内のスレッド内でレジスタ間の直接シャッフル参照が
2サイクルとかで出来れば美味しいのに。
シャッフルのパターンも完全自由でなくて数パターンでもいい。

あと、ワープ内の分岐状態でtakenの数を数える命令と、
ワープ内のスレッドのうち自分より前にあるtakenのスレッド数を数える命令
があれば、ループが終了したスレッドのみに新たなデータを充填して
ループに戻るみたいな処理も簡単に出来るのに。

216 ：デフォルトの名無しさん：2009/10/18(日) 22:51:11

OEDとかいうエンジンを
高速化できんかね？

217 ：デフォルトの名無しさん：2009/10/18(日) 22:55:12

>>216
君が言ってるのは、CUDAは汎用的ではありませんという
当たり前のことだけじゃないか

218 ：デフォルトの名無しさん：2009/10/18(日) 22:56:15

>>217は>>213への間違い

219 ：,,・´∀｀・,,）っ-○○○：2009/10/18(日) 22:59:48

汎用（General Purpose）を捨てたらただのGPUなんだが。
まあIntelがある限りこっち方面は芽はないと思うよ
Radeonにシェア奪われるんじゃNVIDIAのためにもならん。

220 ：,,・´∀｀・,,）っ-○○○：2009/10/18(日) 23:04:36

そもそもOpenCLとかCUDA Cの構文ルール自体がベクトルの横方向の演算を表現できない
制約がある気がするんだが

221 ：デフォルトの名無しさん：2009/10/18(日) 23:04:55

どこまで汎用性を持たせるかで、
汎用性のために全体の構成を弄り過ぎるのは
GPUの構造上のメリットを薄める恐れがある。
小手先の対応でどこまで汎用化できるか
追求した方がいい結果を生むかもしれない。
AMDの路線はそんな感じだ。
RV730で一度粒度を小さくしたのに又戻したのは
実は余り意味がないと判断したんじゃね。
まあ、これが正解かと言われると微妙だが。

222 ：,,・´∀｀・,,）っ-○○○：2009/10/18(日) 23:05:49

730はただの下位モデルだろ

223 ：デフォルトの名無しさん：2009/10/18(日) 23:06:11

>>196
> コンシューマPPCのクロック向上を停滞させた主犯がAltiVecと言われてるくらいだし

トランジスタが足りなかったのは事実だろうけど、それでも外野の想像だろ。
今のIntelとゲーム機はどうなるんだ。

>>213
そこがまさに今までSSEが糞だった理由じゃねーか。
自分の愛するIntel様が完璧なシャッフル実装したら今度は他を叩くのかよ。

224 ：デフォルトの名無しさん：2009/10/18(日) 23:08:14

よしじゃあここでOpenDango言語を作って
高速化GPGPU言語仕様決めようぜ

言語仕様に不備があったら、コンパイラスレの奴拉致すればいいだろうし

225 ：,,・´∀｀・,,）っ-○○○：2009/10/18(日) 23:14:46

＞今のIntelとゲーム機はどうなるんだ

まさかCellのPPEとか？
同時命令発行数減らしてなおかつレイテンシも増大した劣化版VMXがどうしたって？

その更に元になったPPC970のVMXは命令セットこそAltiVecと互換だが
レイテンシその他の制約が全く変わっており、互換技術ではあってもAltiVecそのものではない。

＞自分の愛するIntel様が完璧なシャッフル実装したら今度は他を叩くのかよ。

完璧なシャッフル（笑）って何？
shufpsとかpshuflwとか自由がきかなかったけどパズル的で面白かったなー

pshufbで1ベクトル内の入れ替え系は全部表現できるがそれで全部置き換えたいとは
思わんな。1レジスタ消費するし。

226 ：デフォルトの名無しさん：2009/10/18(日) 23:24:16

>>220
そこら辺、実は関数っぽい形式の拡張でやろうと思えば
幾らでも対応できそうな気が。
AMDのレーンごとの共有レジスタみたいなのも
実質ハードウェアコスト0だから美味しいんだけど。
内部処理の特性でレーンのodd,even毎に
長いALU命令列が丸ごとatomicになっているから
reduce演算で使いであるよ。

まあ、OpenCLに組み込むのは難しいかな。

227 ：,,・´∀｀・,,）っ-○○○：2009/10/18(日) 23:29:26

Pentium IIにSSE付けてほぼ同じパイプライン構造でリリースしたPentium IIIは
クロックは1GHzオーバーまで伸びたよね

でもG3アーキテクチャにAltiVecを搭載したG4は高クロック化が困難で、パイプライン段数を
増やした通称G4+が出るまでは、Macに搭載される石ですら、クロック数の逆転現象を起こしていた。
まあAppleはOS XのUIを重たくしたりキャッシュ容量で差を付けたりしつつ
AltiVecが付いてる石を買わせた訳なんだが。

CPUのSIMD拡張はあくまでスカラの補助なわけで、スカラ演算の性能を縛っちゃ本末転倒だよ。

228 ：,,・´∀｀・,,）っ-○○○：2009/10/19(月) 00:10:36

>>236
OpenCLはベクトルの各要素の中で動かす処理を記述する形式だから
他の要素とのリレーションを記述するのに向かないでしょ

Intelに限ってはCtでいいと思う。
ベクトルをC++のコンテナ的に扱うことで生産性を上げる
というよりreduce周りは組み込みのオペレータ任せだから楽ができる

コード量半分以下でC+組み込み関数での性能の80%近い性能を実現できるんだからだいぶ楽だと思うよ。
それでもオレは余すことなく使うためにアセンブるわけだが。

229 ：,,・´∀｀・,,）っ-○○○：2009/10/19(月) 01:44:42

226だた

230 ：デフォルトの名無しさん：2009/10/19(月) 02:53:32

>>228
別スレッドあるの前提でlocalメモリ使っているんだから余り変わらないだろ。
localメモリ使ったshuffleコードを最適化でshuffle機能に落とすのでもいいけど
素直に拡張関数みたいな形式の方がコンパイラもコード書くほうも楽。

231 ：,,・´∀｀・,,）っ-○○○：2009/10/19(月) 03:19:01

どう表現するのか次第だがな。
kernel関数って原則要素毎に実行だろ。

ベクトル全体で1つのシャッフル操作とか、向かないだろ

232 ：デフォルトの名無しさん：2009/10/19(月) 05:44:03

>>225
> まさかCellのPPEとか？
ほれ、日本で大失敗してるもう一個の方の奴。

233 ：デフォルトの名無しさん：2009/10/19(月) 07:05:55

>RV730で一度粒度を小さくしたのに

演算粒度自体は変わらず、演算サイクルが倍に増えたという

234 ：デフォルトの名無しさん：2009/10/19(月) 08:36:32

>>225
GPGPUを見下すために面白かったで逃げるのかよ。
お前の用途ではいらないかもしれないけど実際使うんだよ。

>>227
だから旧モトローラの力がなかった理由をお前の勝手な想像で話を進めるな。
その前で話題にしていたCellだってXboxだってPPC G5だってVMX持ってるだろうが。
Intelにはごり押しする力があるが、モトローラにはなかったという事実があるだけだ。

235 ：´・∀・｀）：2009/10/19(月) 09:42:18

どこまでも理解のない奴だ。
つか、Appleに公約したクロックを達成できなかったのIBMも同じだし。

元ローラは元々DSPの置き換え用として設計したんでターゲットは組み込み。
高クロックに向かないのは当然。
単純にパイプラインの1ステージに演算を詰め込みすぎたんでクロックが上がらなかった。
IBMはクロックをあげるためにExecutionステージを細分化したが、その分レイテンシが増大し性能が悪化した。

CellのPPEと360のPXがVMX128を除いて同一アーキであることは中の人が暴露してるが、
単純なビット論理ですら4サイクルという大きいレイテンシの埋め合わせを、2WayのシンメトリックFGMTでやっている。それで劣化を補い切れるわけがなく、
PXはvレジスタを128本に拡張し、既存命令空間を潰してVMX128を作った。

アンロールして埋め合わせてくださいってな。
あのな、アンロールしたらただでさえ容量効率よくないL1命令キャッシュさらに食っちまうだろうがよと。
なんやかんやで、いろいろひどい設計だよ。
MACヲタのオッサンすらあれの設計のひどさは擁護できないとな。

236 ：｀・∀・´）：2009/10/19(月) 09:53:07

ついでにIntelの資金力とは言うが、当時の元ローラよりよっぽど金持ってないAMDが
Athlonを投入し、性能競争においてIntel相手にタメはれてたわけで、
POWERアーキが性能競争力がなくなったんでなければ、
よっぽど企業努力が足りないんだろうな。IBM含め。

237 ：デフォルトの名無しさん：2009/10/19(月) 10:08:00

>>236
技術の時流にもはや合わなくなったriscにしがみついた
ストラテジーの失敗だろうな。

238 ：デフォルトの名無しさん：2009/10/19(月) 10:33:11

同じISA、同じ市場で勝負したAMDと、POWER他を比較するのがそもそも変だろ

239 ：デフォルトの名無しさん：2009/10/19(月) 10:41:59

>>238
お前GPGPU否定したな。
ISAが同じじゃないとCore i7やXeonと性能比較しちゃいけないらしいぜ。

240 ：デフォルトの名無しさん：2009/10/19(月) 11:48:55

特定のPhotoshopプラグインとか一部の処理において
PPC G4 500MHzがPentium III 800MHzの性能を上回るとか
みっともないプレゼンやってたけどな。
昔どっかのジョブズさんが。、

241 ：デフォルトの名無しさん：2009/10/19(月) 13:18:46

でもさ、Intelは資金力、技術力ももはや独走状態でしょ。こういうのは良くないね。
素晴らしいアーキテクチャがあったとしても、結局はx86の資産がものいうから、Intelの土俵で戦わないといけないので、Intel有利はいつまでも続くのだろう。
どんな条件でも100倍速いというものでないかぎりは。

242 ：デフォルトの名無しさん：2009/10/19(月) 13:49:05

同じ土俵って？
別にLinuxの同一オープンソースアプリでベンチやってもいいんだぜ。

x86否定論者はまずRISCがデメリットが無い万能な命令セットという
脳内補正ありきで物を語るから始末に困るが、実際には異種命令セット
対抗でも十分性能上の強みがあるから残ってるわけだが。
デコーダが複雑だから使えない云々の話が通用するのは
今は組み込みのミッドレンジまで。

ARMみればわかるように可変長命令には新たに採用してもいい
くらいの合理性はある。
Thumb-2ではモードレスで2バイト命令と4バイト命令の混成が可能になり
高いコード密度と性能をシームレスで両立できるようになった。
この際だから8バイト命令を追加して、2つ以上のオペレーションを
1命令にパックとかやれば、x86に迫るハイパフォーマンス設計が
可能かもしれない。

243 ：デフォルトの名無しさん：2009/10/19(月) 13:54:45

まあIntelの資金力を引き合いに出して没落RISCに同情するのは
貧乏AMDが作ったOpteronの性能に勝ってからにしろと。

244 ：デフォルトの名無しさん：2009/10/19(月) 15:38:34

まあ日本の大学には未だに老害が大量にいるからな

http://ist.ksc.kwansei.ac.jp/~ishiura/2003arc/note/arctrend.pdf
学生がかわいそうだよな
Pentium 4が内部RISCだからこれからはRISCの時代だと思っちゃったんだろけど
ごらんのありさまだよ。
x86マイクロアーキテクチャのパフォーマンス戦略はCISCというか
シンプルなLIW路線へと回帰している。

245 ：デフォルトの名無しさん：2009/10/19(月) 15:43:54

まあ日本の大学には未だに老害が大量にいるからな

http://ist.ksc.kwansei.ac.jp/~ishiura/2003arc/note/arctrend.pdf
いや学生がかわいそうだよな
Pentium 4が内部RISCだからこれからはRISCの時代だと思っちゃったんだろけど
ごらんのありさまだよ。
x86マイクロアーキテクチャのパフォーマンス戦略はCISCというか
シンプルなLIW路線へと回帰している。

246 ：デフォルトの名無しさん：2009/10/19(月) 18:38:56

RISCの命令を、内部で可変長のマイクロコードに変換して実行すれば良いんじゃね
命令L1にはマイクロコード置いとく、と…あれ？これ（ｒｙ

247 ：デフォルトの名無しさん：2009/10/19(月) 18:46:28

字面どおりのRISCのメリットはスーパースカラの時点で終わっているだろ。

248 ：デフォルトの名無しさん：2009/10/19(月) 19:07:04

逆NetBurstか
まあ、そこで可変長である意味はないんだが。

結局メモリアドレッシングは汎用ALUで処理するより専用のAGUで
処理したほうが効率がいいという罠。

ちなみにRISCの内部コード結合はPOWERでもやろうとはしてるみたいだが
あまり効果を発揮してないようで・・・。
アセンブラからCのソースへの逆コンパイルが難しいように、
単純命令から高級命令への変換はあまり効果を発揮していない。

249 ：デフォルトの名無しさん：2009/10/19(月) 19:41:57

>>235
> 単純にパイプラインの1ステージに演算を詰め込みすぎたんでクロックが上がらなかった。

Pentium4の事ですね、分かります。

>CellのPPEと360のPXがVMX128を除いて同一アーキであることは中の人が暴露してるが、
>単純なビット論理ですら4サイクルという大きいレイテンシの埋め合わせを、2WayのシンメトリックFGMTでやっている。それで劣化を補い切れるわけがなく、

出来上がった物が良い物だったかどうかは分からないが、
IBMの提案とハードウェアメーカーの要求が折り合った結果だろ。
どっちにしろIBMでさえ人の金使ってカスタマイズするのが関の山なんだよ。

Intel並に資金力があったらAppleの要求に挫折する事無くPPCをガンガン速くしたかもしれないぜ。
実際G5はVMXを載せたままモトローラより高クロックで作っている。
言っておくが、要らない子なのは分かってるからな。

>>236
AMDはx86がなくなったら息の根が止まっちゃう子だもん。
モトローラやIBMはもっと儲かる物があるから。
儲からない物に金をかけたくない＝予算が降りない＝資金力が無い

あと団子以外の人間で勘違いしている奴がいるみたいだが、
俺はあまりに尖った言い方してるからもっと一般的に見ようぜって言ってるだけで、PPCとかRISC寄りじゃないからな。

250 ：デフォルトの名無しさん：2009/10/19(月) 19:52:25

> > 単純にパイプラインの1ステージに演算を詰め込みすぎたんでクロックが上がらなかった。
>
> Pentium4の事ですね、分かります。

これ逆だと思うけど。
クロック上げたけどパイプライン段数が増えすぎて実効効率が落ちた。

251 ：デフォルトの名無しさん：2009/10/19(月) 19:53:48

現段階ではAMDはx86事業止めたら黒字化すると思うけどな

252 ：デフォルトの名無しさん：2009/10/19(月) 19:59:50

ATI Stream SDK v2.0 beta
http://www.amd.com/us/press-releases/Pages/amd-leads-industry-as-2009oct19.aspx

253 ：デフォルトの名無しさん：2009/10/19(月) 20:00:50

極低温OCだとP4はぶっちぎりに高クロックまで回ってた記憶があるが

254 ：デフォルトの名無しさん：2009/10/19(月) 20:07:14

ぼくのかんがえたさいきょうのめいれいせっとマダー？

255 ：デフォルトの名無しさん：2009/10/19(月) 20:17:11

pen4はリーク電流とかの絡みで思ったよりクロックが上がらんかったような

256 ：デフォルトの名無しさん：2009/10/19(月) 20:22:08

「x86を貶す俺ｶｺｲｲ」な彼は言ってることが頓珍漢だし
どうすればいいんでしょうかね

257 ：デフォルトの名無しさん：2009/10/19(月) 20:38:12

>>255
Dellから4.2GHz動作のPentium Dマシンが出てたが
たぶん有名メーカー製PCとしては歴代最高クロックじゃないかな。

258 ：デフォルトの名無しさん：2009/10/19(月) 20:45:14

>>257
当初はもっと行く予定じゃなかったっけ

259 ：デフォルトの名無しさん：2009/10/19(月) 21:09:50

それがどうした？
内部処理を固定長RISCに置き換えたら結局使えない糞になるって
証明じゃないか。

都度デコードしてでもアドレッシングモード付きの命令を
μOPs Fusionして捌いたほうが性能が出るってことで
x86の従来フォーマットの優位性が示されたわけだが。

260 ：デフォルトの名無しさん：2009/10/19(月) 21:35:52

>>259
コテつけ忘れているよｗ

261 ：デフォルトの名無しさん：2009/10/19(月) 21:53:17

Core i7はそれほど大きくないループに対しては
デコードに対してキャッシュが利くので十分だな。
SIMD使ったとしてもアンロール要求されることもないし。

262 ：デフォルトの名無しさん：2009/10/19(月) 21:58:06

http://www.donanimhaber.com/AMDden_Nvidia_Fermi_atagi_iste_detaylar-16160.htm

AMDからも馬鹿にされてるなFermi

263 ：デフォルトの名無しさん：2009/10/19(月) 22:07:12

AMD必死だなｗ

264 ：デフォルトの名無しさん：2009/10/19(月) 22:35:43

AppleのOpenCLが加速してまうで、どうすんのよNV・・・

265 ：デフォルトの名無しさん：2009/10/19(月) 22:42:54

"Paper Dragon"
まあ事実だからしょうがない

　　　　　　,,,
(　ﾟдﾟ)つ┃
　　　（・´ω`・）

266 ：デフォルトの名無しさん：2009/10/19(月) 22:53:12

はげども、答えろ。はげっが。

267 ：デフォルトの名無しさん：2009/10/20(火) 00:25:27

>>264
OpenCLはCUDAベースだから涙目なのはAMDだよ
OpenCL SDKのサンプルを動かしてみると歴然としすぎ
OpenGLと違ってコード共通の意味が無いｗ

268 ：,,・´∀｀・,,）っ-○○○：2009/10/20(火) 01:56:04

紙竜！
紙竜！

269 ：デフォルトの名無しさん：2009/10/20(火) 07:59:37

実物が存在するというのは強みだな
あとはハンダ不良率が高くないのも

270 ：,,・´∀｀・,,）っ-○○○：2009/10/20(火) 08:42:24

電源ピンが途中で切れてるが故にTDPが0W


　　　　　　,,,
(　ﾟдﾟ)つ┃
　　　（・´ω|

271 ：デフォルトの名無しさん：2009/10/20(火) 18:05:38

OpenCL版がbrook+より遅い理由がAMDのフォーラムに書いてあるが
大きな理由としてOpenCLのデフォルトのポインタがrestrictじゃない事が上げられている。
こんな糞仕様だったのかと。

272 ：デフォルトの名無しさん：2009/10/20(火) 18:46:49

ガツガツ解析して最適化するようなことはしてないのね。
ヌビはやってるのに。

273 ：デフォルトの名無しさん：2009/10/20(火) 20:16:55

amdだもの

274 ：デフォルトの名無しさん：2009/10/20(火) 20:34:48

はっきり言ってポインタなんかある方がおかしくね？
大体CUDAでC言語云々言い始めた頃から、違和感を感じてた。
HLSL程度の仕様で十分じゃん。

275 ：,,・´∀｀・,,）っ-○○○：2009/10/20(火) 21:29:42

AVX版AESの方が1バイト短いよね
だからなんだって言うレベルだが

276 ：,,・´∀｀・,,）っ-○○○：2009/10/20(火) 21:30:29

589

277 ：デフォルトの名無しさん：2009/10/22(木) 15:14:02

FermiのLoad/Storeユニットの相対的なスループットは一般のプロセッサに対し低くなっている。
GPUの処理はレジスタ上の同じ値に対して同じ値との積和算を繰り返すだけでほぼ完結するからだ。
だがそれが汎用ストリームプロセッサとしてどうかというのは別問題。
倍精度まで大幅強化してLSUネックじゃ、使える用途は大幅に限られる。
確かにPaper Dragonかもしれん。

違う方向のものを追いかけてブレてるNVIDIA。合掌。

278 ：デフォルトの名無しさん：2009/10/22(木) 18:23:03

globalメモリへのアクセスだったらどうせ実帯域狭いから
L/Sユニットのスループットは余り性能に響かないんじゃない？
localメモリへのアクセスが遅いのは厳しそう。

279 ：,,・´∀｀・,,）っ-○○○：2009/10/22(木) 22:15:06

TSUBAMEも2.x世代になるとOpteron + FermiとXeon + Larrabeeの競演になるんだろうな
ある意味楽しみで仕方がない

280 ：デフォルトの名無しさん：2009/10/23(金) 02:27:57

fermiのLSUは単純に考えてGT200の1.75倍の性能だね。

281 ：,,・´∀｀・,,）っ-○○○：2009/10/23(金) 07:44:05

単純に考えてLarrabee 2コア分（32SP相当）の1/4の性能だけどね。

282 ：デフォルトの名無しさん：2009/10/23(金) 19:36:33

　　　　　　　　　　　∬
　　　　　 　 　 　 　 |:|
　　　 　 　 _＿＿＿|:|＿＿＿
　　　 　,ｲ´　 　ノ´　　　　ヽ. ｀ヽ.　新しいバイトも入って
　　 　 {　　 ●　　（__人__） 　●.}　　Win7どころじゃ
　 　 　 ﾞ'ゝ、 　　　｀ ⌒´ 　 _ .,ノ　　ないんだよね
　　　 　/　 ￣￣￣￣￣￣ｨヽ
　 　 　/ 　　　　　　　　　　　　|
　　 　 |.　⌒＼　　　 ,.────.､　ｷﾞｰｺ　ｷﾞｰｺ
　　 　 ｌ　＼/￣＼（(| i'￣￣￣｀i | ).））　　
　　 　 ｌ　 　uUUU二| |..||￣,','￣| |￣￣￣￣￣.「＿＿＿＿＿　
￣￣￣￣￣￣￣￣|_|~|| 　~~~~|_|.　 Fermi　　.|
　　　　　　　　　　　 　　||＿＿＿＿_　　　　 　__|]
　　　　　　　　　　　　　　　　　　　 ┌!!_______!!.!
　 　 　 　 　　　　　　　　　　　　　　

283 ：デフォルトの名無しさん：2009/10/23(金) 19:56:51

目がキモイ

284 ：,,・´∀｀・,,）っ-○○○：2009/10/23(金) 23:23:08

　http://www.fixstars.com/company/event/gpu_seminar.html

せこい商売だ

285 ：デフォルトの名無しさん：2009/10/24(土) 00:44:24

>>284
これ人集まらなくて
困ってるらしいから行ってやれよ

286 ：,,・´∀｀・,,）っ-○○○：2009/10/24(土) 01:15:17

たとえばだよ、、Larrabee用のコンパイラで普通のC++/OpenMPのコードをビルドするだけで
CUDAの半分でも性能でたら、馬鹿馬鹿しくてGPGPU専用言語なんて勉強しませんって。
何のための言語なの？何のための機械なの？

ニーズなんて殆ど無いのは最初から解ってる。
頭の悪い零細企業騙すだけの悪徳セミナーだよ。

287 ：デフォルトの名無しさん：2009/10/24(土) 01:23:21

larabeeだってIntel独自のLN何とかという糞命令覚えないとならないんだろ？

288 ：デフォルトの名無しさん：2009/10/24(土) 01:33:45

ていのうおつ

289 ：デフォルトの名無しさん：2009/10/24(土) 01:36:08

ララビーってコンシューマレベルの価格帯に降りてくるの？
それなら団子の言っていることは正論だが、たぶんそれはない
所詮ララビーはインテルのメニーコア路線においての実験プログラムにしか過ぎないじゃん

290 ：デフォルトの名無しさん：2009/10/24(土) 01:44:59

>>289
CPUへの統合まで仄めかしているのに永遠にコンシューマ帯に
降りてこないと決めつける根拠を述べてみろよ。

291 ：デフォルトの名無しさん：2009/10/24(土) 01:45:46

>>285

1日目はいらんな。

団子さんがLarrabeeのセミナー開いたら？
土日だけでも結構集まると思うぞ。

292 ：デフォルトの名無しさん：2009/10/24(土) 01:46:31

仄めかしてるって言うか、IDFで公式に認めたよな。時期が秘密ってだけで。

293 ：,,・´∀｀・,,）っ-○○○：2009/10/24(土) 01:54:35

>>289
TeslaならともかくGeForce（笑）みたいなコンシューマレベルが買うようなハードで動く
泡沫ソフトで元が取れる技術だとでも思ってるのか？

もともとエンプラ向けだよ。

まあ、FermiもLarrabeeも1台100万程度は覚悟したほうがいいね。
でもさ、エンタープライズの世界じゃ請負でプログラマ1人を一人雇うだけでもひと月100万。
特殊技能が必要になればそこに更に上乗せ。
OpenCLでカバーできるような自動並列化なんてIntel C++コンパイラの自動並列化で充分ってことになれば
まあそんな金のかかるプログラマいらねって話になる。

Fixstarsもまだ名前が売れてるうちに技術売りつけようと必死必死。

294 ：デフォルトの名無しさん：2009/10/24(土) 02:30:14

Tesla C1060が10万切ってたから衝動買いしてしまったｗ
ま、自分でCUDAでゴリゴリ書くの断念してもCUBLASで使えればそれでいいや。

295 ：,,・´∀｀・,,）っ-○○○：2009/10/24(土) 02:46:44

なんにせよ言語取得のためのセミナーとしては異常に高すぎるだろ。
Ruby On Railsのセミナーの参加料なんて全国各地でやってるがたかだか数千円レベルだぞ。
まあ、席が埋まればたった二日で100万以上売り上げるわけだからな。
OpenCLという虚構に満ちた技術で最も稼ぐ手段とは、
よくわかってない開発者向けのFixstars自身によるぼったくりセミナーという罠。
やってることがネズミ講レベル。

そもそもOpenCLだとかCUDAだとか、コンシューマの需要そのものがないに等しい。
VB6やCOBOLでソフト作ってくれって需要はあっても、実績すらないOpenCLで作ってくれなんて
何処の顧客だって言わないのよ。
ソフトウェア開発言語として実績もなければ、（安い技術者がそのへんに転がってないという意味で）
保守性も悪い。

求められてるとすれば「スループットが欲しい」のであって、ハードと言語の縛りから選択の余地がないだけ。
その点FermiなんざLarrabee程には望まれてない。

296 ：デフォルトの名無しさん：2009/10/24(土) 03:01:34

>>295
言いたいことはわかったから、団子さんLarrabeeのセミナーを開いてよ。

だめなら、このスレでいいからセミナーライクなことをしてよ。
期待しているよ。

297 ：デフォルトの名無しさん：2009/10/24(土) 03:11:39

>>295
今日は語るねぇ。

まぁスパコン業界が壊滅したことを引き合いに出すまでも無く、HPCなんて
CUDAだろうがOpenCLだろうがLarrabeeだろうがMPIだろうがニッチなもんな
ことは当たり前。

ニッチ向けだから商売になる（大学とか研究所とかに深く入り込むと、そこで使う
技術がニッチになればなる程、自分とこ以外受託できなくなる）ってこともあるので、
純粋にそういう所の人たちが聴きに来ることもあるだろうし、まぁ、そもそも
そんな怒るような内容でもあるまい。

298 ：デフォルトの名無しさん：2009/10/24(土) 09:26:14

Appleが全力でOpenCLに・・・
どうすんのよNV・・・

299 ：デフォルトの名無しさん：2009/10/24(土) 09:29:04

AMDもIntelもGPU統合のCPU出た時点で
Geforceは動作しないからなぁ

300 ：デフォルトの名無しさん：2009/10/24(土) 10:12:49

一般向けのGPGPUがCSとOpenCLに収斂していくのは既定路線だからどうでもいい
CPUとGPU統合が非常にまずい、廃業レベルにまずい

301 ：,,・´∀｀・,,）っ-○○○：2009/10/24(土) 11:39:02

GPGPUという市場自体HPCのごく一部じゃないの
「GPGPUで置き換えよう」という発想そのものを潰すのが目的だろう


あとはエンプラ方面ではクラウド（笑）かね

302 ：デフォルトの名無しさん：2009/10/24(土) 12:58:01

超究武神覇斬コンピューティング

303 ：デフォルトの名無しさん：2009/10/24(土) 13:36:41

エアリス使う奴は心が醜い

304 ：デフォルトの名無しさん：2009/10/25(日) 00:21:43

PGIがCUDA対応のFORTRAN2003出すよう棚

305 ：デフォルトの名無しさん：2009/10/25(日) 00:30:57

PGIはAMD見捨てたからなぁ
どうなるか解らんなぁ

306 ：デフォルトの名無しさん：2009/10/25(日) 14:01:09

S3の新しいGPUはOpenCL対応らしいな。

307 ：デフォルトの名無しさん：2009/10/25(日) 15:54:32

死にそうで死なないなS3

308 ：デフォルトの名無しさん：2009/10/25(日) 22:05:04

>>297
基本的にわかってない奴らからぼったくるのがFixs○tarsの方針に思える。
商売としては正しいと思うが.....
全体的に値段が高すぎる。それほどの価値はない。

309 ：デフォルトの名無しさん：2009/10/25(日) 22:19:21

>>307
取りあえずVIAのチップセット用ので最低限会社回せるだけは稼いでるのかもな。

310 ：デフォルトの名無しさん：2009/10/25(日) 22:43:14

>>308
まあ、CUDAの環境セットアップやら、文法やらデバッグの基礎辺りを
自習できない程度の人間じゃぁ何にもならないから、こういうの
金払って聴きに行ってるようではしょうがないと言えるかもね。

並列アルゴリズムの徹底的な講義なら自分も聴いてみたいが、
そういうのはどっかの大学院で情報系のマスターの講義でよさげなのを
聴講させてもらうとか何かするほうがまだ余程役に立つだろうな。

311 ：デフォルトの名無しさん：2009/10/25(日) 22:45:46

ＧＰＧＰＵでErlangが動作するＶＭってないですか？

312 ：デフォルトの名無しさん：2009/10/26(月) 10:28:03

>>310
高卒のくせに上等ぶるなよ。

313 ：デフォルトの名無しさん：2009/10/26(月) 14:02:34

>>312
僻みみっともないｗ

314 ：デフォルトの名無しさん：2009/11/01(日) 10:30:19

いきおいないぞ

315 ：デフォルトの名無しさん：2009/11/01(日) 20:32:22

ASCII.technologiesがGPGPU特集。買ってないけど。
あと来月CUDA、1月にOpenCLの和書だって。

316 ：デフォルトの名無しさん：2009/11/01(日) 23:27:41

BulletのOpenCL対応計画は確かに動いているらしい。
ttp://bullet.googlecode.com/svn/branches/OpenCL
GPU Computing SDKとStream SDKがあればサンプルの幾つかはビルド可能だけれど、
どれもまだドラフト段階だね。

317 ：デフォルトの名無しさん：2009/11/03(火) 21:54:40

Fermiまた延期になりそう
騎神館の精神はもつのか
すべてがうまくいって２月に出る見込み

318 ：,,・´∀｀・,,）っ-○○○：2009/11/03(火) 22:13:08

Havok党のための「鬼神館ブログ」でも立ち上げようか

319 ：デフォルトの名無しさん：2009/11/04(水) 02:07:00

騎神館って何だろうと思ったら、前に検索でたまたま見た英語まともに訳せてないblogのことか。

320 ：,,・´∀｀・,,）っ-○○○：2009/11/04(水) 02:14:32

Excite翻訳そのまんまなブログ
知識的にも残念な人なんだろうな

321 ：デフォルトの名無しさん：2009/11/04(水) 02:21:09

そういう罵倒の仕方をするおたくも相当残念な人だな。

322 ：デフォルトの名無しさん：2009/11/04(水) 07:47:18

事実なんだから仕方ないだろ

323 ：デフォルトの名無しさん：2009/11/04(水) 19:27:20

騎神館が残念なのは中の人がラデスレ荒らすのに忙しいからですよ

324 ：デフォルトの名無しさん：2009/11/05(木) 16:55:44

事実だとしても、罵倒せずには居られない時点でダメさ。

325 ：デフォルトの名無しさん：2009/11/05(木) 17:14:12

835 名前：Socket774[sage] 投稿日：2009/11/05(木) 06:30:10 ID:XS/Hw4x0
ttp://www.semiaccurate.com/2009/11/04/nvidia-crushes-msis-lucid-based-board/
LucidがハードウェアでGPU負荷を分散するhydra200を発表、
10月29日にMSIから塔載マザーボードBig Bang Fuzionが発売予定
→NVIDIAはSLI税が取れなくなるのでMSIにカチコミをかける
→発売日になってみるとhydra200の載ったBig Bang Fuzionはどっかに消えて
　nForce 200の載ったBig Bang Trinergy登場
→でも実際はTrinergyなんて存在しないのでFuzionの写真にPhotoshopでアレして公開、即バレる

外向けにはhydra200のドライバが間に合わないから発売延期とか云わせてるようですが
ttp://www.4gamer.net/games/048/G004815/20091031002/
実際はNVIDIAが「hydra200が載ってたらドライバで検出して動かなくしてやる」と
強迫しているのでした。あーコワイコワイ。マザーボードメーカーみんな敵に回しちゃったら
みんな一斉にSLIにグッバイしちゃったりするんじゃないのかな？?

326 ：デフォルトの名無しさん：2009/11/05(木) 21:59:07

スレ違い

327 ：,,・´∀｀・,,）っ-○○○：2009/11/05(木) 23:00:46

いつぞ騎神館（笑）はLucidがIntelだと思い込んでアホな記事書いてたなぁ
恥ずかしい恥ずかしい

328 ：デフォルトの名無しさん：2009/11/05(木) 23:05:15

Intelが出資してるベンチャー企業だけどな

329 ：,,・´∀｀・,,）っ-○○○：2009/11/05(木) 23:18:55

製造元がIntelそのものなら今回みたいな沙汰になってないだろう
もっと恐ろしいことになる

330 ：デフォルトの名無しさん：2009/11/05(木) 23:21:30

>製造元がIntelそのものなら
ラグナロクが始まるお・・・

331 ：デフォルトの名無しさん：2009/11/06(金) 12:55:03

亀ですまん。
>>214
＞さらにフーリエ変換のライブラリが使えるんだから
cufftのことなら、あれは遅いよ。

332 ：デフォルトの名無しさん：2009/11/06(金) 13:48:43

インテルからいろいろいわれてNVかわいそうとか思ってたけど
NVも弱者にはえげつないんだな

333 ：デフォルトの名無しさん：2009/11/06(金) 14:02:36

チャーリーが書いてたパートナーに恨まれてるというのはガチ臭いな
Geforce専業だったEVGAがLarrabeeカード売るって時点でNV離れ始まってたのか

334 ：デフォルトの名無しさん：2009/11/06(金) 14:20:10

結局、GPUが得意な演算ってなんなの？
密行列とかの一部の演算以外はCPUにぼろ負けしてるよね
ビット演算だってSSE命令使えばCPUも高速化するし

335 ：デフォルトの名無しさん：2009/11/06(金) 19:22:51

なんでわかんないの？

336 ：デフォルトの名無しさん：2009/11/06(金) 19:59:32

なんでこんなアホがこのスレにいるんだよ
初心者スレ池

337 ：,,・´∀｀・,,）っ-○○○：2009/11/06(金) 22:47:54

大量のスレッドに食われるから物理レジスタ本数の割にはロード・ストア回数をセーブできないのが弱点

338 ：354：2009/11/07(土) 02:20:52

なんだ、わからない人間しかいないのか

339 ：デフォルトの名無しさん：2009/11/07(土) 10:39:57

おまえの名前がわからないよ
GPGPUの話なんてその辺に転がってるんだから調べろ

340 ：デフォルトの名無しさん：2009/11/07(土) 19:03:03

>>354
その問題は現代科学じゃ無理だぜ…

341 ：,,・´∀｀・,,）っ-○○○：2009/11/07(土) 19:08:26

>>354に期待

342 ：デフォルトの名無しさん：2009/11/07(土) 19:44:42

>>354
後のノーベル物理学賞受賞者である

343 ：デフォルトの名無しさん：2009/11/08(日) 02:07:19

ｰ-ニ _　 ＿ヾV, --､丶､ し-､
ﾆ-‐'' ／／　ヾｿ　､　!ヽ　 `ヽ ヽ
_／,.ｲ /　/ミ;j〃ﾞ〉 }�U ｝ ハ ヽ､}
..ノ /ﾊ　 〔　　 ∠ノ乂 ｛ヽ　ヾ丶ヽ　 　 ヽ
　ノﾉ　.>､_＼　{ j∠=, }、 l ＼ヽヽ ',　　_ノ
ｰ-=ﾆ二ﾆ=一`'´__,.ｲ<::ヽリ　j　`､ ）　＼　　　>>354ッ！
{¨丶､＿ｎ_,. イ　|{.　 |::::ヽ（　{　〈　（　 　　〉
'|　　| 　 　 　　小,　|:::::::|:::l＼i　',　ｌ　　 く　　ユーの意見を聞こうッ！
_| 　｜　 　　`ヾ:ﾌ　|::::::::|:::|　 }　}　|　　　）
､|　　| 　　 ∠ﾆﾆ}　|:::::::::|/　/　/ /　　／-‐-､
トl、　ｌ 　　{⌒ヽr{　|:::::::::|,／／／　　　　　　　 ＼／⌒＼/⌒丶/´￣`
::＼丶、 　 ヾ二ｿ　|:::::::/∠-''´
/＼＼.丶、 ｀''''''′!:::::::ﾚ〈
　　 〉::￣::｀'ｧ--‐''ﾞ:::::::/::::ヽ
＼;/:::::::::::::/::／::::::::::::/／:::::〉
::`ヽ:::ｰ-〇'´::::::::::::::::/-ﾆ::::（

344 ：デフォルトの名無しさん：2009/11/08(日) 03:33:31

結局OpneCLもちゃんと性能が出るNVIDIAに最適化されるわけか
http://www.4gamer.net/games/032/G003263/20091104040/

345 ：デフォルトの名無しさん：2009/11/08(日) 10:01:25

えーと

346 ：デフォルトの名無しさん：2009/11/08(日) 12:02:17

OpenCLは配列扱うのに単純にポインタで渡すなんて
物凄い並列化と相性悪い仕様だよね。

347 ：デフォルトの名無しさん：2009/11/08(日) 12:47:50

エイリアスが無い事が保証されてれば問題ないんじゃねぇの

348 ：デフォルトの名無しさん：2009/11/09(月) 02:12:32

OpenCLだとカーネル呼び出し時にエイリアスの有無判別できそうだけど
エイリアスありなしの2種類バイナリ用意して実行時に選択とかさせるのもアホ臭い。
それも2種類で済めば良いんだが。

せめてimage以外の多次元配列オブジェクト用意してくれたらなぁ。
どうせdeviceメモリならHost側で直接弄れないのだから
linear配置に拘る必要ないのに。

いちいち配列サイズを引数で渡して
アクセスのたびにアドレス計算なんてするくらいなら
fortranみたいに書けた方が楽だし分かりやすい。
それに加えてhardに応じた最適化もかけ易い。

349 ：デフォルトの名無しさん：2009/11/09(月) 23:13:01

OpenCLの本ってどれ？
いつ発売なの？

350 ：デフォルトの名無しさん：2009/11/10(火) 19:28:44

工学社から1月予定だそうな。

351 ：デフォルトの名無しさん：2009/11/11(水) 00:20:39

>>350
OpenCLだぞ
CUDAじゃねーぞ？

352 ：デフォルトの名無しさん：2009/11/16(月) 00:13:46

いつになれば出てくるのかわからないFermi
すでに製品はあるがやる気がないAMD
NVを邪魔するためだけに生まれてこようとしているララビー、が未だ姿は見えず・・・

353 ：デフォルトの名無しさん：2009/11/16(月) 00:56:13

Larrabeeはどっかのモックアップと違って実働デモまでしてるだろうが

354 ：デフォルトの名無しさん：2009/11/16(月) 01:04:02

　 ,,・´∀｀・,,）っ-○○○

団子さんの目って「・」か「´（｀）」のどっちなんですか？？

355 ：,,・´∀｀・,,）っ-○○○：2009/11/16(月) 01:54:39

>>354
失望した

356 ：デフォルトの名無しさん：2009/11/16(月) 02:33:20

　 ,,・´∀｀・,,）っ-○○○
　↑　　　　↑
　　　これが目

357 ：デフォルトの名無しさん：2009/11/16(月) 02:38:27

>>354
お前の目の付けどころにﾜﾛﾀｗ

358 ：デフォルトの名無しさん：2009/11/16(月) 15:04:59

騎神館、もとい気振韓はねた切れ気味だな

359 ：デフォルトの名無しさん：2009/11/16(月) 22:07:11

GPUって浮動小数点演算と固定小数点演算＋ビット演算なプログラムだとどっちが早いですか？
GPUの整数演算やビット演算ユニットはおまけみたいなもんですか？

360 ：デフォルトの名無しさん：2009/11/16(月) 22:19:12

CUDAを勉強してて思ったんですけど、これ、CPU→GPU→CPUの転送がめちゃくちゃ足引っ張ってません？？
ほんとに大量の演算が必要か、ガッツリ最適化かけないとメリットが出ない･･･
リアルタイムの画像処理演算とかに使えるかな、と期待したんですが、そういうのには向いてないですよね？

もうCPUの隣にGPU付けれるようにしたらいいのに、とｵﾓﾀｗ

361 ：デフォルトの名無しさん：2009/11/16(月) 23:33:20

GPU内蔵になるCore i5 6XXだと少しは転送早くなんのかね？

362 ：デフォルトの名無しさん：2009/11/16(月) 23:36:15

Tesla20シリーズ出たね

363 ：デフォルトの名無しさん：2009/11/16(月) 23:40:32

Tesla20は爆速だなぁ
これすげーわ

364 ：デフォルトの名無しさん：2009/11/16(月) 23:42:26

来年Q2てなめてんなこの会社

365 ：デフォルトの名無しさん：2009/11/16(月) 23:46:54

圧倒的過ぎるだろ…
CPUなんていらんかったんや

366 ：デフォルトの名無しさん：2009/11/16(月) 23:48:39

倍精度が速くなったのは良いとして単精度はその2倍しかないってなめてんのか

367 ：,,・´∀｀・,,）っ-○○○：2009/11/16(月) 23:56:40

理論スループットの額面なんて最初からわかってるだろ

368 ：,,・´∀｀・,,）っ-○○○：2009/11/17(火) 00:00:49

案の定ペーパーローンチなわけだが

369 ：デフォルトの名無しさん：2009/11/17(火) 00:02:01

しょぼ…

370 ：360：2009/11/17(火) 00:03:25

>>361
おお、そんなものが出るのですか。
楽しみですね。

371 ：デフォルトの名無しさん：2009/11/17(火) 00:04:57

clarkdaleの事かな？
統合チップだと速度は上がるけどメモリの量、バスに多くは望めないよ

372 ：デフォルトの名無しさん：2009/11/17(火) 00:15:38

単精度 1.26TFLOPS
倍精度 630GFLOPS

なにこれ・・・インパクトがなさ過ぎる

373 ：デフォルトの名無しさん：2009/11/17(火) 00:19:56

225Wで630GFLOPSは素直に凄い

374 ：デフォルトの名無しさん：2009/11/17(火) 00:26:07

>>373
HD5870は180Wで約550Gの性能だが。

375 ：360：2009/11/17(火) 00:26:23

>>371
しかし、現状のようにCPUとGPUが遥か遠く離れている状況よりはだいぶ効率が良くなりませんか？
少なくとも、リアルタイム系の処理での適用範囲がグっと広がるように感じます。
何か今はいくらカーネルの効率をがんばって上げても、CPU⇔GPU間転送が台無しにしてくれそうで･･･orz
今までDirect3Dでグラフィックスに使ってたときも、CPU⇔GPU転送をできるだけしないように
（ゲーム等では幸い少なくできますが）気を遣いましたし。

376 ：デフォルトの名無しさん：2009/11/17(火) 00:26:46

よし、Fermi死亡確認っと。Larrabeeに期待！

377 ：デフォルトの名無しさん：2009/11/17(火) 00:32:12

>>360
LIano｢呼んだ？｣

378 ：デフォルトの名無しさん：2009/11/17(火) 00:35:25

>>370
ララビーじゃないインテルGPUで演算とか出来るわけないから期待するな。
AMDのLianoだけが当面の最強統合プロセッサだよ。

379 ：,,・´∀｀・,,）っ-○○○：2009/11/17(火) 00:35:55

Larrabeeはその気になればWindowsが動かせそうだけど

380 ：360：2009/11/17(火) 00:42:36

>>377-378
ありがとうございます。
そういえばATIとAMDがくっついたのはCPUとGPUの統合を狙ってだったということを
すっ　　かり忘れてましたｗ

CPU⇔GPU転送のコストを思い知った今、この統合チップの構想には非常に期待できます。
そのほか、CellやLarrabeeなど、各プロセッサ同士の距離を感じないのは心地よいものですね。

nVidiaのGPUはポテンシャルはものすごいのに、ほんとうに惜しいです･･･

ああ、この先、並列コンピューティングの勢力図はどうなってしまうのでしょうか･･･

381 ：デフォルトの名無しさん：2009/11/17(火) 00:46:02

この先の事を考えるならNVIDIAが言ってる事は無視していいです

382 ：360：2009/11/17(火) 00:52:45

やっぱりそうなりますよね･･･
nVidiaも生き残りを賭けて必死でしょうけど、あまりにもハンデが大きい･･･

団子さんのご意見も拝借したい。

383 ：,,・´∀｀・,,）っ-○○○：2009/11/17(火) 01:08:06

ディスクリート版のLarrabeeにはあんまり期待していない。

統合CPU+GPUになってからが本領発揮。
Haswell 4GHzの4コア＋Larrabee 2GHz 16コアくらいで倍精度1TFLOPSな。

384 ：360：2009/11/17(火) 01:12:01

>>383
ありがとうございます。恐縮です。

OpenCL勉強しますｗ
今度出る本が楽しみだなぁ。

385 ：デフォルトの名無しさん：2009/11/17(火) 01:50:32

第一世代LarrabeeはLRBniの勉強用やね。

386 ：デフォルトの名無しさん：2009/11/17(火) 04:07:52

>>383
ダイサイズや消費電力はどの程度になるんだろうか。

387 ：デフォルトの名無しさん：2009/11/17(火) 07:20:50

OpenCL本ってどれですか？

388 ：デフォルトの名無しさん：2009/11/17(火) 08:09:30

>>387
>>315

389 ：デフォルトの名無しさん：2009/11/17(火) 12:24:29

> Haswell 4GHzの4コア＋Larrabee 2GHz 16コアくらいで倍精度1TFLOPSな。
実効250GFLOPS弱か。

390 ：デフォルトの名無しさん：2009/11/17(火) 13:27:45

GPUと一緒にするなよｗ

Intelは常に実効9割超える設計にする

391 ：デフォルトの名無しさん：2009/11/17(火) 13:36:13

逆にtop500で実効9割超えてないのはGPGPUやGRAPE-DRみたいな
色物ばかり。

392 ：デフォルトの名無しさん：2009/11/17(火) 15:05:29

それこそ、CPUとGPGPUを比較してもしょうがない。

393 ：デフォルトの名無しさん：2009/11/17(火) 15:30:42

LarrabeeはCPUばりに実効性能重視設計だぜ。
それこそすべてのFPUが同時稼動することのほうが稀なGeForce/Teslaと
一緒にすべきじゃない。

394 ：デフォルトの名無しさん：2009/11/17(火) 16:37:32

Sandy Bridgeは3.2GHzの6コア×2ソケットで
SP 600GFLOPS / DP 300GFLOPSに達する。

Fermiが実効性能5割切るようじゃ電力効率でもCPUに負ける。
もうLarrabeeが出るまでもなく使い物にならない。

GPGPU終了。

395 ：デフォルトの名無しさん：2009/11/17(火) 17:10:51

225Wで630GFLOPSは素直に
凄い

・
・
・
・

低
効
率

396 ：デフォルトの名無しさん：2009/11/17(火) 20:21:33

>>390
> Intelは常に実効9割超える設計にする
えー？Intelって性能誇示する時はかなり都合のよい架空の状態のみを想定するじゃん。

397 ：デフォルトの名無しさん：2009/11/17(火) 20:27:59

77.48TFLOPS(max)/170TFLOPS(peak)
東工大「うわっ・・・Tesla性能悪すぎ・・・」

398 ：デフォルトの名無しさん：2009/11/17(火) 20:35:32

おまえ馬鹿だろ。top500のスループット比率見てみろよ。
Xeonクラスタは軒並み実効性能90%オーバーばっかしだ。

GPUのピークFLOPS数って酷いぞ。
コンスタントにデータ供給しながら出せる数字じゃないから。
2命令同時発行なのにSP(MAD)とSFU(MUL)両方同時に動かしたら
ロード・ストアは走らせることができない。
「はまる条件」すらないのがGPU
単純に浮動小数ユニットの数を足し算掛け算やってるだけ。
全部同時に動くことは決してない。

399 ：デフォルトの名無しさん：2009/11/17(火) 21:06:41

Fermiはピークは出ないけど実行効率上がるって記事見たけどどうなるんだろうか。

400 ：デフォルトの名無しさん：2009/11/17(火) 21:49:43

>>399
Fermi: 16Way FMA×2に対し16Way LSU
Larrabee: 16Way FMA＋16Way Loadに対し16Way Store

ぜんぜん話にならん

401 ：デフォルトの名無しさん：2009/11/17(火) 21:52:12

TOP500の1位はOpteronだけどな
Intelの設計思想は数値計算じゃ向いてないってこと

402 ：デフォルトの名無しさん：2009/11/17(火) 22:00:27

米国のITゼネコン最大手のIBMが自社開発SOIプロセスの製品を使ってるだけの
話だけどな。

本当に向いてないならXeon搭載スパコンが８割とかありえない。

403 ：デフォルトの名無しさん：2009/11/17(火) 22:00:41

実行効率の話をしてるのにTOP500の順位を持ち出すバカなAMDerは不要

404 ：デフォルトの名無しさん：2009/11/17(火) 22:04:56

>>315
もうどこにも売ってなかった(´・ω・`)

405 ：デフォルトの名無しさん：2009/11/17(火) 22:08:40

>>404
何か、数が少なかったね。
自分も大型の書店で何とか入手した。
まぁ、こんな特集でもない限り、滅多に買わないんだけどね。

406 ：,,・´∀｀・,,）っ-○○○：2009/11/17(火) 23:02:46

吠える吠えるｗｗｗｗｗ

407 ：デフォルトの名無しさん：2009/11/17(火) 23:06:02

わんわん

408 ：,,・´∀｀・,,）っ-○○○：2009/11/17(火) 23:30:51

1ワープで処理するブロック単位を64×n行列とかそれ以上にすれば原理上ロード回数を抑えられるが
ワープあたりのレジスタ本数を多めに取る必要が生じる。

もっと言うとD3DMatrixとか使ってCPU側で処理してた4x4行列の操作も数命令でLarrabee側で処理出来る。
何がおいしいかって？
頂点にせよピクセルにせよ、CPUで処理した後はGPUに流さないといけないじゃん。

409 ：デフォルトの名無しさん：2009/11/17(火) 23:43:30

団子は自分の領域外の話に首を突っ込むとすぐバグるなぁ

410 ：デフォルトの名無しさん：2009/11/17(火) 23:57:45

デバッグ、デバッグ

411 ：,,・´∀｀・,,）っ-○○○：2009/11/18(水) 00:00:09

君が理解出来ないだけでしょ。

http://msdn.microsoft.com/ja-jp/library/cc372315.aspx
に書かれてるような4x4行列の四則演算程度なら実装出来るよ。というかコード書いてる。
オンレジスタで処理出来るからね。

転置行列作る場合はいっぺんL1にストアしてからvgatherdやったほうがいいかも

412 ：デフォルトの名無しさん：2009/11/18(水) 00:06:05

Borderlandsときいて飛んできたらこれだよ！

413 ：デフォルトの名無しさん：2009/11/18(水) 00:09:39

なんの誤爆だよ

414 ：デフォルトの名無しさん：2009/11/18(水) 01:11:23

これ本当に団子なのか？

415 ：,,・´∀｀・,,）っ-○○○：2009/11/18(水) 01:48:58

swizzleが便利すぎて4x4行列程度は楽勝すぐる

416 ：デフォルトの名無しさん：2009/11/18(水) 07:23:52

1月に出る本ってどれよ
ちょっと名前教えろよ

頼むね

417 ：デフォルトの名無しさん：2009/11/18(水) 10:16:49

何度も書くけど、SIMDって詐欺じゃね？
SIMDを前提として性能を語るだけ無駄じゃね？
Larrabeeは16並列だと聞くけど、そんなに必要か？
誰が16x16の行列積なんて使うんだよ、どっかのラボじゃないんだからさぁ
larrabeeを8並列で使ったら、途端に性能半分だよ、4並列なら1/4、
SIMDの実行性能なんてどうせこんなもんだろ、賞味1/4だよ
大体SoAを要求するって、どうやってライブラリ化すんだよ
こうすんのか？↓

struct float4{float& x,y,x,w;}
static float x[1024], y[1024], z[1024], w[1024];
float4 v = {::x[0], ::y[0], ::z[0], ::w[0]};

めんどいわ、馬鹿にしてんのか？
FPUx2にした方がよっぽど使えるわ

418 ：デフォルトの名無しさん：2009/11/18(水) 10:52:57

何故このスレに来た

419 ：デフォルトの名無しさん：2009/11/18(水) 10:56:47

>>417
画像処理なら16並列くらい使うが面倒なのは確かだな。

420 ：,,・´∀｀・,,）っ-○○○：2009/11/18(水) 13:03:32

4x4行列積はLarrabeeではこんだけだ。
メモっとけアホ共

vloadd v0, [rax]
vloadd v1, [rcx]{4to16}
vloadd v2, [rcx+0x10]{4to16}
vloadd v3, [rcx+0x20]{4to16}
vloadd v4, [rcx+0x30]{4to16}
vmulps v5, v1, v0{aaaa}
vmadd231ps v5, v2, v0{bbbb}
vmadd231ps v5, v3, v0{cccc}
vmadd231ps v5, v4, v0{dddd}
vstored [rdx], v5

421 ：,,・´∀｀・,,）っ-○○○：2009/11/18(水) 13:22:56

ちなみにCUDAはもっと不自由で
Load/StoreユニットはHalf Warp単位でデータを読み書きするが
同一キャッシュラインに収まる分しか1サイクルで取れないから
結局ロードネックで性能が出ない。
swizzleするのもいったんShared Memoryにストアして読み直し。
性能ウンコにもほどがある。

LarrabeeもAoS-SoA相互変換できるが、ロード・ストアユニットが
ネックになるのでやらないに越したことはない。
1サイクルにロードできるデータ構造のままダイレクトに処理したほうが
まず効率がいいしｗ

>>417の教養のなさに全米が脱糞だ

422 ：デフォルトの名無しさん：2009/11/18(水) 13:43:17

並列処理が必要な処理をしたことないだけじゃないか？
SIMDの有用性なんて、特定の人が限られた条件下でしか
使わない機能なんてのは、MMXで十分わかっているわけで、
万人が使うものじゃないよ。
だから用途がない人は、無理して使わなくていい。

423 ：デフォルトの名無しさん：2009/11/18(水) 13:56:09

>>420
それ行列 * ベクトルじゃね？
まあでも、それをそのまま拡張すれば16要素フルに使って
行列4x4 * 行列4x4出来そうだな。
つーかララビはノーペナルティでswizzleし放題なの？
だとしたら、まあちょっといいかも。
しかしSIMDがクソに変わりない、調子こくなカス。

424 ：デフォルトの名無しさん：2009/11/18(水) 14:06:42

>>422
特定の人しか使われず、
PC使ってるあいだ殆ど動作せず、
C言語で自然に扱えない機能を
パーソナルコンピュータに入れるなっつー話しよ。
スパコンだけに入れとけや、代わりにFPUいっぱい積めや。
水増し計算で1TFlopsとか、あたかも1T回浮動小数点演算出来るとか
JAROに訴えますよ。

425 ：,,・´∀｀・,,）っ-○○○：2009/11/18(水) 14:07:36

積和算がfused multiply-addならLarrabeeの演算ユニットは
fused (load-)swizzle-accumulateな。

だから最初から言ってるんだ。理論FLOPS数が同等なら
Larrabeeが圧倒すると。

426 ：デフォルトの名無しさん：2009/11/18(水) 14:30:27

>>424
コンパイラが使ってくれますよ。
逆に寧ろ、FPUをたくさん積んでもその方が使いきれないと思うけど。

427 ：デフォルトの名無しさん：2009/11/18(水) 14:53:14

>>424
書き捨てのプログラムを自分で書いて使うならSIMDなんて効率悪いだろうけど、
汎用的な処理なら誰かが苦労して最適化したライブラリ動かせば一般人にもメリットあるし。
エンコとか暗号化とかな。

428 ：デフォルトの名無しさん：2009/11/18(水) 16:37:40

>>424
巣に帰れよ低脳

429 ：デフォルトの名無しさん：2009/11/18(水) 17:24:37

>>416
工学社「はじめてのCUDAプログラミング」
なら出てるよ。東工大の先生の本。
ASCII.techも買った（分量は６０ページ）が、
両方とも初心者向けの本。

430 ：デフォルトの名無しさん：2009/11/18(水) 18:28:14

実効性能1006GFLOPS(SGEMM)キタコレ
http://www.heise.de/newsticker/meldung/SC09-Intel-demonstriert-Larrabee-mit-ueber-1-Teraflops-862305.html

431 ：デフォルトの名無しさん：2009/11/18(水) 18:55:30

>>429
あれで初心者向けなのか･･･！
すごい世界を覗いてしまった気がする（汗）
泣きそうｗ

432 ：デフォルトの名無しさん：2009/11/18(水) 19:24:38

gemmが効率出しやすい演算だってのは知ってるけれどsgemmでスピード測っても仕方ないよなあ。
こういう分野ではgemmを沢山使う用途よりも大きな配列でgemmする用途の方が多いだろ。
でも配列が大きいとsgemmじゃ精度が足りないだろ。
何やってんだかって感じ。

433 ：デフォルトの名無しさん：2009/11/18(水) 19:28:30

PCでもスパコンでもIntelはベンチマーク詐欺（笑）

434 ：デフォルトの名無しさん：2009/11/18(水) 19:30:56

ベンチマークですら理論性能とかけ離れたGPU信者の負け犬の遠吠え

435 ：デフォルトの名無しさん：2009/11/18(水) 19:32:38

2.7TFLOPS(自称)のEvergreen大勝利！！

436 ：デフォルトの名無しさん：2009/11/18(水) 19:36:34

>>435
RadeonのSGEMMはACML-GPUでめいっぱい最適化して理論値の40%前後なので、
実はいい勝負だったりする。

DGEMMではLarrabeeはSGEMMの半分程度の値になると思われるが
Radeonは倍精度の理論値が1/5程度だから（以下略）

437 ：デフォルトの名無しさん：2009/11/18(水) 19:49:30

>>436
RV770ではDGEMM性能はSGEMM性能の1/2弱
GPGPU#2のログにあった。
>952 ：デフォルトの名無しさん[sage]：2009/03/15(日) 21:53:50
>ttp://forum.beyond3d.com/showthread.php?t=52990
>ACML gpu benchmark numbers
>
>>170 gflops for DP and 380 gflops for SP.
>>Remember to run your CPU at full speed (i.e. disable powersave)!!
>
>DPのわりにSPが速くないような
>（RV770ってDP/SP=1/5だったように思うが)

438 ：デフォルトの名無しさん：2009/11/18(水) 19:56:58

Radeonはそもそも全部の演算ユニットを浮動小数に使いながら
データ操作もできるような構造じゃない。
ちょっと複雑なロード・ストアやシャッフルが絡むとユニットを
浮動小数演算にまわせなくなる。

GeForceはロード・ストアユニットとFPUが分かれてるが慢性的なロードネック。

Larrabeeの場合はFMAにLoad, Swizzleを組み合わせても浮動小数演算の
パフォーマンスが落ちないようなパイプライン構造になってるから
理論性能は冴えないが実際のアプリでの性能低下も少ない。

439 ：,,・´∀｀・,,）っ-○○○：2009/11/18(水) 22:05:53

【>>420の別解】
vloadd v0, [rax]
vshuf128x32 v1, v0, {3210}, {aaaa}
vshuf128x32 v2, v0, {3210}, {bbbb}
vshuf128x32 v3, v0, {3210}, {cccc}
vshuf128x32 v4, v0, {3210}, {dddd}
vmulps v5, v1, [rcx]{4to16}
vmadd231ps v5, v2, [rcx+0x10]{4to16}
vmadd231ps v5, v3, [rcx+0x20]{4to16}
vmadd231ps v5, v4, [rcx+0x30]{4to16}
vstored [rdx], v5

【本当はこう書きたいけど制約で書けないコード】
vloadd v0, [rax]
vmulps v1, v0{aaaa}, [rcx]{4to16}
vmadd231ps v1, v0{bbbb}, [rcx+0x10]{4to16}
vmadd231ps v1, v0{cccc}, [rcx+0x20]{4to16}
vmadd231ps v1, v0{dddd}, [rcx+0x30]{4to16}
vstored [rdx], v1

440 ：デフォルトの名無しさん：2009/11/18(水) 22:46:27

>>439
4to16ってわかりづらいなー
4byte目から16byte目まで、計16byteをロードしろって意味？
リトルエンディアンじゃないの？
vmadd231psの231もわかんねーなー、なんだそりゃ

つーか、3オペランドで書けるなら、HLSL的な擬似Cコードで十分書けるよね
そっちにして欲しいよ
読みづらくてかなわん

441 ：,,・´∀｀・,,）っ-○○○：2009/11/18(水) 22:52:27

4to16は4つのデータ（この場合128bit）を4回ブロードキャストしろって意味
つまり
abcd abcd abcd abcd

他に、1データを16要素にコピーする {1to16} とか、512ビットそのまんま使う{16to16}（あるいは省略）
てなswizzleモードがある

442 ：,,・´∀｀・,,）っ-○○○：2009/11/18(水) 22:54:16

ちなみにこれ読めばいいと思うよ
http://techresearch.intel.com/articles/Tera-Scale/1514.htm

443 ：デフォルトの名無しさん：2009/11/18(水) 22:59:02

貧乏で過去にも先にも、GPGPU環境なんて組めないから
資料なんか読まねーよウンコたれ野郎が

444 ：デフォルトの名無しさん：2009/11/18(水) 23:04:56

団子さん、すげー･･･
マジ尊敬する。

445 ：デフォルトの名無しさん：2009/11/18(水) 23:16:50

>>439
レジスタ無駄に使っている様に見えるのは
レイテンシからの制限か何かなの？

446 ：,,・´∀｀・,,）っ-○○○：2009/11/19(木) 06:56:44

>>445
レイテンシは確かにあるんだけど、どっちかというとload+broadcastあるいはshuffleよりも
積和算のレイテンシのほうが大きいんで微妙杉。
なんで、積和のレイテンシ埋めるにはほかに何かインターリーブしてやんないといけない。

Larrabeeはアウトオブオーダ実行がないから、アセンブリ言語使うと
レイテンシを考慮したスケジューリングが必要なのが厄介。
実際に使うならC/C++で組み込み関数使ってコンパイラに任せたほうが楽かもね。

あとLarrabeeはネイティブ命令レベルで水平演算も可能。
隣の要素同士の水平加算はこれだけ。
　vaddps v0, v0, v0{cdab}
4要素の水平加算なら上のに更にこれを実行。
　vaddps v0, v0, v0{dbca}
これはどっかの大学のプレゼンそのまんまだけど。
ほかmul, and, xorなんでもあり。

この辺はCtのReduce演算子あたりで抽象化されている。
たぶん、OpenCLのLarrabee向け拡張よりCtのほうが覚えやすい＆使いやすいと思う。
もともとCtのAPIを想定してLarrabeeの命令セットが作られたふしがあるようだし。

なんにせよLarrabeeはレジスタ上でのレイアウトの制限がないのでTeslaより圧倒的に柔軟性がある。
float4を4並列実行したほうがいいのか、16個のfloat4をx, y, z, w各要素ごとのベクトルに再パックして
実行したほうがいいかは処理次第。

447 ：,,・´∀｀・,,）っ-○○○：2009/11/19(木) 09:30:33

4要素はこうだな
　vaddps v0, v0, v0{cdab}
　vaddps v0, v0, v0{badc}

448 ：デフォルトの名無しさん：2009/11/19(木) 21:58:52

LarrabeeってSPUみたいに特定命令の組み合わせのみ2並列で実行できるんだよね？
使い物になるの、これ？Cellみたいに大失敗するんじゃないの？

449 ：デフォルトの名無しさん：2009/11/19(木) 22:38:33

第2のIA-64になりそうで怖い
でもアレは当時の需要が小さすぎたのが問題だったから
nVidiaとAMDがスパコン市場でGPGPU分野を作った今なら問題無いか

450 ：デフォルトの名無しさん：2009/11/19(木) 22:57:34

AMDもNVも何もしてない
HPCに貢献したのはIntelとIBMだ

451 ：デフォルトの名無しさん：2009/11/19(木) 23:02:08

>>450
Intelはいつになったら世界一のスパコンに返り咲くんですか

452 ：デフォルトの名無しさん：2009/11/19(木) 23:03:56

お前らそんなこと言ってる間にFermiの実物大カード来たぞ

http://www.4gamer.net/games/099/G009929/20091119001/

453 ：デフォルトの名無しさん：2009/11/19(木) 23:04:35

フレームワークでｇｄｇｄなAMDはGPGPU分野を作ったと言えるのだろうか？？

454 ：デフォルトの名無しさん：2009/11/19(木) 23:09:26

>>453
それでも中国のスパコンに大量納入されて日本国内のスパコン抜いちゃったんだよね…

455 ：デフォルトの名無しさん：2009/11/19(木) 23:17:10

ピーク値を見るとTOP3に入れそうなのに実行効率が悪すぎて5位(´；ω；｀)ﾌﾞﾜｯ

ってかこれでGPGPU分野を作ったって事になるの？

456 ：デフォルトの名無しさん：2009/11/19(木) 23:27:39

これからどんどん増えそう
CPU+GPUシステム

457 ：デフォルトの名無しさん：2009/11/19(木) 23:38:05

>>455
TOP1〜4は全部PowerPCかOpteronなんだよね
開発時期的にGPUが前世代の4870X2になるのは仕方無いとして
何でXeonなんかを採用したんだろうｗ

458 ：デフォルトの名無しさん：2009/11/19(木) 23:44:09

もうなりふり構わずAMDを誉めないと気が済まないんだろうな

性能が悪いのはXeonのせい！(ｷﾘｯ

459 ：,,・´∀｀・,,）っ-○○○：2009/11/20(金) 00:22:29

>>457
逆になんでXeonが圧倒的シェアを占める中1〜4位がIBM絡みなのか考えてみたら？

20年前くらいのNECの構図と大して変わらんよ。
そのときはまだIBMは攻める側にいたという違いがあるが。

460 ：デフォルトの名無しさん：2009/11/20(金) 00:34:55

CrayっていつIBM陣営になったの…？

461 ：デフォルトの名無しさん：2009/11/20(金) 00:35:36

Intel信者ウゼエよ
実製品が出てから来い

462 ：デフォルトの名無しさん：2009/11/20(金) 00:36:00

Top500がアム厨唯一の希望だからな

463 ：,,・´∀｀・,,）っ-○○○：2009/11/20(金) 00:49:26

ごめん、Crayは別だね


>>462
氷山の一角しか見てないけどな。

464 ：デフォルトの名無しさん：2009/11/20(金) 00:57:50

Top500の結果だけで性能語るのもどうかと思うけど。

465 ：デフォルトの名無しさん：2009/11/20(金) 01:00:33

AMDerに言ってやれ

466 ：,,・´∀｀・,,）っ-○○○：2009/11/20(金) 01:03:13

なんにせよテーマが必要だよな。
「地球シミュレータ」は解りやすい目的があったが、「京速」にはそれがない。

Lucilleの中の人も言ってたけど、レイトレーシングなり一般の消費者にもっと身近な演算を
高速にこなすようなニーズさえあれば10PFLOPSにも意味は出てくる。
明確な用途も無いのにただ速ければなんかの役に立つでしょってのは何の役にも立たない。

467 ：デフォルトの名無しさん：2009/11/20(金) 01:08:42

>>456
10年以上前からそうなってるが・・。

468 ：,,・´∀｀・,,）っ-○○○：2009/11/20(金) 01:13:55

よろしい。ならば重力演算だ。

469 ：デフォルトの名無しさん：2009/11/20(金) 01:17:57

>>466
京速は理研と提携組織のバイオ・物性研究に使う明確な用途があったが…？

470 ：デフォルトの名無しさん：2009/11/20(金) 01:28:43

レンホウにはわかりません

471 ：デフォルトの名無しさん：2009/11/20(金) 01:28:56

>>469
後付けだから。。それ。

472 ：デフォルトの名無しさん：2009/11/20(金) 01:30:23

10年前は、高速な演算をアピールするために動画のエンコードとかがもてはやされたよね･･･

473 ：デフォルトの名無しさん：2009/11/20(金) 01:35:32

>>469
理論値でだけ性能高くてソフトウェア的にガッタガタで使い物にならない未来が目に見えてます

474 ：,,・´∀｀・,,）っ-○○○：2009/11/20(金) 01:42:54

>>469
神戸空港含めポートアイランド二期の経済効果は予想を下回ってるんだよね。
んで、用地が埋まらない神戸市が格安で理研に土地を提供したから京速の設置が
決まったようなもんでそれ以上でもそれ以下でもない。
羽田＋成田のハブ化で神空は関空もろともハブられ化。
現政府の意向と反してるんだよね。

用途も明確にすべきだし、強いて言えば、ポートアイランドである理由も必要。
神戸市が格安で土地提供するから安い？
その神戸市の予算はどこの市県民税・地方交付税で成り立ってるの？的な。

辛くも3期目の当選を果たした矢田立郎神戸市長は民主党推薦ではあるものの
型にはまった元高級官僚。


おっと、これはスパコンスレ向けの話題だな

475 ：,,・´∀｀・,,）っ-○○○：2009/11/20(金) 01:46:21

ごめん、元助役だから高級官僚の犬、が正解。

476 ：デフォルトの名無しさん：2009/11/20(金) 01:48:33

団子さんって何者･･･！？

477 ：,,・´∀｀・,,）っ-○○○：2009/11/20(金) 01:58:39

「首都圏に大震災が来たらチャンス」だとか言っちゃう市長の事業を諸手をあげて支持するのは
どこの理研、というか利権関係者ですか

478 ：デフォルトの名無しさん：2009/11/20(金) 07:37:47

団子25日　AMDいくよね？

479 ：デフォルトの名無しさん：2009/11/20(金) 09:23:30

http://www.hardware-infos.com/news.php?news=3308
実効･･･性能･･･?

480 ：デフォルトの名無しさん：2009/11/20(金) 16:16:38

要約すると
1GHzの24コア(8コア無効化)で実効スループットは417GFLOPS,
瞬間最大実効712GFで、理論最大768GFってこと考えればかなり効率がいい。
1.5GHz程度にクロックアップして1TF達成。

32コアフルに動くのは選別品になるんだろうな。

481 ：デフォルトの名無しさん：2009/11/20(金) 17:02:04

オーバークロックしたときの理論スループットは？

482 ：デフォルトの名無しさん：2009/11/20(金) 17:22:49

1152

483 ：デフォルトの名無しさん：2009/11/20(金) 17:36:15

2wayインオーダーか
P54/54C/55Cの頃は手で並べ替えていたがもうメンドクサイ

484 ：デフォルトの名無しさん：2009/11/20(金) 18:08:02

最適化コンパイラまかせでいいよね。

485 ：デフォルトの名無しさん：2009/11/20(金) 19:32:03

>>474
非国民め！日本が世界一にするために無制限に金をつぎ込むべきだろうが！
お前みたいなサヨクが日本をダメにするんだよ！

486 ：デフォルトの名無しさん：2009/11/20(金) 19:37:21

というか何で京速の開発目的の話をナチュラルに立地の裏事情に摩り替えてるんだ？
京速コンピュータは神戸に決まる数年前から始まっていたプロジェクトだが、
神戸市の誘致前提で始まったプロジェクトとでも思ってんのかね

487 ：デフォルトの名無しさん：2009/11/20(金) 19:39:32

お前らGPUの話しろよ

488 ：デフォルトの名無しさん：2009/11/20(金) 20:01:57

>>436
おっと、その主張はなおさら京速の存在意義を失わせることになるな。
神戸に作ることで医療産業都市構想（京阪神メディカルクラスター構想）
の一端を担うという一応の大義名分が得られる。

神戸空港で国際空港と連絡して世界中の研究者を呼び込める期待されてたんだよね
ふたを開けてみたらあの有様。二期工事の埋め立て地はまだガラガラ。

結論：第２の本状工区。

489 ：デフォルトの名無しさん：2009/11/20(金) 20:12:02

Folding@homeと京速はどっちが速いの？

490 ：デフォルトの名無しさん：2009/11/20(金) 20:22:35

>>477
それは神戸市長ではなく兵庫県知事の発言です。

兵庫県知事　震災「不適切」発言　広がる波紋
http://sankei.jp.msn.com/politics/policy/081111/plc0811112157042-n1.htm

>>485
京速コンピュータの説明者の説得力があなたと同レベルだったのが残念です。
仕分人側は筋道立てて理屈を考えて京速コンピュータを切ったようです。

私の印象は違うかな。　(仕分人と説明者のやりとり)
http://slashdot.jp/comments.pl?sid=475072&cid=1673731
行政刷新会議、事業仕分けのメディアと実際の違い　(仕分人による解説)
http://www.chieichiba.net/blog/2009/11/by_paco_113.html

>>487
GPGPUはCPUがメニーコア化するまでの徒花ではないでしょうか。
LarrabeeがあればGPGPUは必要ないと思います。

491 ：デフォルトの名無しさん：2009/11/20(金) 21:22:56

主張するなら理由も書いて。根拠レスじゃ反論不能。

492 ：デフォルトの名無しさん：2009/11/20(金) 22:31:33

>>491
それではGPGPUはCPUがメニーコア化するまでの徒花説について理由を書きます。

プログラマの立場からすると有効利用するのが容易なアーキテクチャが良いです。
言語仕様レベルでマルチコアに対応しているプログラミング言語が増えているので
あとは処理を無数のスレッドや軽量プロセスに分けるようにコーディングするだけで
CPUがシングルコアだろうとメニーコアだろうと有効利用できます。
しかしGPGPUの場合はCPUとGPU間の転送オーバーヘッドが大きいため、
アーキテクチャを意識して粒度を変えないと性能がでません。
どちらの方が有効利用しやすいかは明白です。

いままではCPUが素子の増加をシングルスレッド性能の向上につぎ込んだために
CPUとGPUの演算性能向上ペースに差があり、そのためGPGPUの意義がありました。
しかしCPUがメニーコア化に方針転換したことにより差は消滅すると考えられます。
GPGPUがCPUに対して圧倒的に優れた性能を出せなくなれば、
手間暇かけてGPGPUに対応する意義はなくなると考えます。

493 ：デフォルトの名無しさん：2009/11/20(金) 22:40:37

>>CPUとGPU間の転送オーバーヘッドが大きい
というのは誰もが認識する現状のGPGPUの大きな問題点の一つだが、
誰もが認識しているだけあって、誰もがそこを埋めようとしている。
というかCPUとかGPGPUとか区別するより、両者が
アーキテクチャ的にも物理的な距離的にも
近づいて来ているというのが近いような。

494 ：デフォルトの名無しさん：2009/11/20(金) 22:56:23

そこでSandy、Fusionの登場ってわけだ

495 ：デフォルトの名無しさん：2009/11/20(金) 23:10:52

Fusionに期待！

496 ：デフォルトの名無しさん：2009/11/21(土) 00:02:26

GMAを統合する意味ってあるのだろうか・・・・・・

497 ：デフォルトの名無しさん：2009/11/21(土) 00:07:58

32nmプロセスだとダイ上に統合してもあんま意味無いだろ
22nmでも>>383みたいなのは難しい
Geneseo(PCI-E3.0)みたいなのが間に挟まる

498 ：354：2009/11/21(土) 00:19:56

SandyもFusionもGPGPUとしては２流品だぞ
SandyのGPUはオンチップをのせたやつだし、FusionもHD4xxx世代のもの
結構保守的なGPUを乗せてくるらしい
このペースだとGPGPUコアがCPUに統合されるのは１０年先だよ

499 ：デフォルトの名無しさん：2009/11/21(土) 00:21:25

だったらいいな！

500 ：498：2009/11/21(土) 00:23:40

名前の354はどっかからの間違いです

501 ：デフォルトの名無しさん：2009/11/21(土) 00:33:24

FusionはHD5xxxシリーズ
LlanoがHD46xxクラス

502 ：デフォルトの名無しさん：2009/11/21(土) 00:33:47

>>498
AMDのFusion→LlanoはDX11対応のHD5ｘｘｘベースでDirectComputeとOpenCL共にReadyだぞ？

503 ：,,・´∀｀・,,）っ-○○○：2009/11/21(土) 01:10:08

>>500
目はたぶん「・」なんじゃね？

504 ：デフォルトの名無しさん：2009/11/21(土) 05:52:33

NVIDIA「このペースだとGPGPUコアがCPUに統合されるのは１０年先だよ」

505 ：,,・´∀｀・,,）っ-○○○：2009/11/21(土) 11:41:35

Llanoは統合じゃなくて「くっつけただけ」だからな。
初期のPentium Dがダイが切り離されてないのと同じようなもの。
キャッシュを共有して協調動作とかすらしない。

その点でSandy Bridgeは面白い

506 ：デフォルトの名無しさん：2009/11/21(土) 12:14:53

BIOSでGPU機能を切るやり方とか誰かが見つけてくれるはず

507 ：デフォルトの名無しさん：2009/11/21(土) 14:37:29

ハードレベルに統合されてるのに外部から切る方法なんてあるのか？

508 ：デフォルトの名無しさん：2009/11/21(土) 17:08:11

はあ？

509 ：,,・´∀｀・,,）っ-○○○：2009/11/21(土) 17:24:59

何で切る必要あるの？

510 ：498：2009/11/21(土) 17:46:39

GPGPU向けコアが統合されるのは、もしかしたらDRAMがCPUに統合されるのよりも後かもね
ちなみに、メインメモリのレイテンシが大きいのもアクセス速度が遅いのもCPUとメインメモリが
物理的に離れているのが原因なんだってね
DRAMも内部では1GHzぐらいで動作しているらしいよ

511 ：デフォルトの名無しさん：2009/11/21(土) 18:14:16

良い事考えた。コアごとにローカルメモリを用意してやればいいんじゃね？

512 ：デフォルトの名無しさん：2009/11/21(土) 18:20:05

sandyのGPU部分は不要でしょー
非統合版あればそれを買う

513 ：デフォルトの名無しさん：2009/11/21(土) 18:58:16

NVIDIA「メインメモリの帯域が狭いからCPUはもう伸びしろがない。CPU終焉の時代に向かっている(ｷﾘｯ」

514 ：デフォルトの名無しさん：2009/11/21(土) 19:47:06

ClarkdaleではCPUとGPUではそれぞれ独立したベースクロックを供給されるらしい
BIOSから切ることは簡単だろう

515 ：,,・´∀｀・,,）っ-○○○：2009/11/21(土) 22:11:49

切る必要ないじゃん。

CPUのSIMD性能2倍→相対的にGPGPUの価値半分

516 ：デフォルトの名無しさん：2009/11/21(土) 22:25:49

GMA X3100以下のエクスペリエンスインデックスのclarkdaleに未来はあるのか？
過去の情報だから現状については不明だけど…

517 ：デフォルトの名無しさん：2009/11/22(日) 00:02:06

イミフ

518 ：498：2009/11/22(日) 00:23:15

　　 　／￣￣￣＼
　　　　　／　─　 　 ─ ＼
　　　 ／　 <○> 　<○>　 ＼.
　　　 |　　　　（__人__）　　　　| 俺も店に着くなりワゴンに行けって言われたんだけど・・・
　　　 ＼　　　 ｀ ⌒´　　　　／
　　　 ／ 　 　GT 240 　 　 ＼

519 ： ◆0uxK91AxII ：2009/11/22(日) 04:06:54

GPUのメモリ操作は長く、予想も容易だから、インチキしやすい。
CPUだと難しい。
CPUに統合すると、GPUの性能が落ちそうな予感。

>>510
えっ。

520 ：デフォルトの名無しさん：2009/11/22(日) 09:26:11

プロセッサアーキテクチャの違いなんて意識したくないな.

プログラマがスレッド作ったら, 適当に空いてるプロセッサに

割り当ててほしいんだけど.

521 ：デフォルトの名無しさん：2009/11/22(日) 12:50:05

>>519
オバカ
インチキしたらいけないとあれほど言ったのに

522 ：デフォルトの名無しさん：2009/11/22(日) 14:56:46

プログラマブルシェーダだけでも画期的だったのにさらに負担を増やせというのか

523 ：デフォルトの名無しさん：2009/11/23(月) 00:09:16

AMDのGPGUだと3年後でもせいぜいCPUの3〜4倍程度の
速度しかでないけど、Nvidiaなら3年後だと1200倍〜3500倍ぐらい
高速になるみたいだけど

524 ：デフォルトの名無しさん：2009/11/23(月) 00:14:51

IntelやAMDの場合は2年後までにCPUにGPUが統合されるから
「3年後のCPU」と比較してGPUはそんなに差が出ない

525 ：,,・´∀｀・,,）っ-○○○：2009/11/23(月) 00:16:30

IBMは結局Cell 32コアは中止らしいな。
必然的に終息ですな。

526 ：,,・´∀｀・,,）っ-○○○：2009/11/23(月) 00:17:11

>>523
笑うしかないわｗｗｗｗ

527 ：デフォルトの名無しさん：2009/11/23(月) 03:02:54

Cellの終焉はGPGPUの未来の姿

Cellの方がはるかに注目を集めて、ゲーム産業でCUDAの数百倍の
プログラマーがプログラムを書いていたのに、まともに応用できなかった

Cellよりも最適化が難しいGPUは、大学の研究者みたいな暇人意外には手が出せないと思う
GPUチャレンジだって変態アルゴリズムを実装してたけど、Cellチャレンジの方は逆に
単純なアルゴリズムだったよね
超変態アーキテクチャ向けにアルゴリズムから設計しないといけないなんて現実的じゃない

528 ：,,・´∀｀・,,）っ-○○○：2009/11/23(月) 03:09:16

GPGPUとか高性能FPGAで解く問題って単純だけど量の多い問題だ
そういう問題に限ってだけ汎用CPUで解くより遙かに効率がいいが
CPUの代わりにはなり得ない。

529 ：デフォルトの名無しさん：2009/11/23(月) 06:56:02

larrabeeもな

530 ：デフォルトの名無しさん：2009/11/23(月) 11:18:15

>>527
> 大学の研究者みたいな暇人
研究だけやってるやつは暇かもしれないが、
最近では研究だけじゃなく授業もできない奴は雇わない方針の大学がほとんどだよ。
そして授業やってると雑務が増えて研究できない。

531 ：,,・´∀｀・,,）っ-○○○：2009/11/23(月) 12:27:59

>>529
GPGPUをLarrabeeと同格に扱いたいならせめてOSが動くレベルになってからにしろよ・・・
というか普通のC/C++が動くようにしろよ

532 ：デフォルトの名無しさん：2009/11/23(月) 12:39:42

GPGPUをC/C++が動くような方向に持っていく事自体が間違い。
もっと高級なレベルでプログラミングさせないと、
最適化のチャンスが減るだけ。
ポインタ見せるのではなくて、配列やリンクリストみたいな
オブジェクトを見せてマップ関数とか呼ばせるようなプログラミングスタイルじゃないと

まあ、そういう意味でもCtのほうが進んでいるのが皮肉っぽいが

533 ：デフォルトの名無しさん：2009/11/23(月) 14:47:40

ブロック図を繋ぐような感じで

534 ：デフォルトの名無しさん：2009/11/23(月) 15:02:53

そこでGoですよ

535 ：デフォルトの名無しさん：2009/11/23(月) 15:42:01

>>518
ﾜﾛﾀｗ

536 ：デフォルトの名無しさん：2009/11/23(月) 17:38:36

matlabでいいじゃん。

537 ：デフォルトの名無しさん：2009/11/23(月) 20:59:01

とりあえずどのくらい高速なのか試してみたいと思っているのですが、
静音性が高くてそこそこ高速なGPUって何がありますか？

538 ：デフォルトの名無しさん：2009/11/23(月) 21:00:42

>>537
Radeon5890 CFがお勧めですね