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:[email protected]/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〃ﾞ〉 }￤｝ハヽ､}
..ノ /ﾊ　〔　　 ∠ノ乂｛ヽ　ヾ丶ヽ　　ヽ
　ノﾉ　.>､_＼　{ 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がお勧めですね

539 ：デフォルトの名無しさん：2009/11/24(火) 02:14:57

>>527
> プログラマーがプログラムを書いていたのに、まともに応用できなかった
それはもしかしてギャグで言っているのか？

540 ：,,・´∀｀・,,）っ-○○○：2009/11/24(火) 03:34:59

>>532
C/C++が動く意味が解ってないようだが、たとえばCPU用のPOSIXアプリが
コンパイルして動く、と言うレベルでのソース再利用性すら売りになる。

Intelは直接触らせることでの最適化も期待してるからネイティブのSIMD命令を
露出させてるわけで。
まあCtによるハードの抽象化ももちろん期待してるだろうが。

541 ：デフォルトの名無しさん：2009/11/24(火) 19:31:50

>>540
C++が動く意味はもちろん分かっているよ。
でも、GPU陣営がCPUと同じ汎用性を目指すなんて
Intelに真っ向から勝負挑んで勝てるわけ無いじゃない。

あくまで汎用性を制限した特定用途での性能で勝負しないと。

542 ：デフォルトの名無しさん：2009/11/24(火) 19:58:38

例え動いたとしても容易に許可すべきじゃないよなぁ
間違いなくそいつがボトルネックになってそのクソ遅いモジュール
何とかしろよってことになる

543 ：,,・´∀｀・,,）っ-○○○：2009/11/24(火) 22:42:51

そうでもないでしょ。

理想はSSE intrinsicsで書かれてるコードを更に4レーンパックして並列化してくれると楽
x86だからエンディアンも一致してるし、基本的に128ビットアラインメントは
保証されてるから、スカラのコードを16並列に展開してベクトル化するよりは
圧倒的に簡単じゃないかな？

まあ書き直した方が性能出るだろうけどね。

544 ：デフォルトの名無しさん：2009/11/27(金) 21:55:31

Femiが最強らしいね
GrapeDRは罵倒されてひどいらしいし
Radeonは選定対象にもならないそうだw

Radeonってほんとう捏造性能だけで全然だめだよなぁ

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

えっと、GPGPU性能が良いと言いたいんですよね
まずはLarrabeeを圧倒しないとね、モックではなくね

546 ：デフォルトの名無しさん：2009/11/27(金) 23:21:58

AMD君こうゆうのはいけないなぁ

http://developer.amd.com/documentation/articles/pages/OpenCL-and-the-ATI-Stream-v2.0-Beta.aspx

547 ：デフォルトの名無しさん：2009/11/28(土) 00:29:39

わらびーが出てからが本番よね

548 ：デフォルトの名無しさん：2009/12/02(水) 12:40:19

「Larrabeeは実効性能が出ないから糞。俺は最初からこんなもん失敗すると思ってたけどね。Cellの方がまだマシ。」
1～2年後には団子はこんな感じの事を言ってそう。

549 ：デフォルトの名無しさん：2009/12/02(水) 13:35:45

それが団子のいいところ

550 ：デフォルトの名無しさん：2009/12/02(水) 14:03:34

Intelの悪口は言わないと思う。
でもディスクリートには最初から期待していないとか後だしは案の定やってる。

551 ：,,・´∀｀・,,）っ-○○○：2009/12/02(水) 20:03:45

>>548
それは能無しが言うことですね。
精鋭ががんばっても理論値の3割で御の字、そもそも実際のアプリで
理論値をたたき出すことが理論的にありえないどっかのGPUとは違って
積和算にいろんなロード操作をたたみこめるLarrabeeは
いくらでもチューニングのしようがある。

俺の用途だとスクラッチパッドメモリあるいはL1のロード・ストア帯域が
そこそこ必要になるんで、Cellは話にならんしFermiは残念にも程がある。

552 ：,,・´∀｀・,,）っ-○○○：2009/12/02(水) 20:42:17

たとえば>>420のD3DMATRIX互換データ構造の4x4行列積を求めるコードの場合
v1-v4で表現したベクトルが回転行列で、
複数の座標にたいして同じ回転を加えたい、というケースならば
対象となる行列の数が増えればFLOPS数は理論値の70％程度に近づく。

Larrabeeだとvloadd 1回に対しvmulpsを1回, vmadd231psを3回。
vstoredはスカラパイプ側で処理できる。
スカラ側にあと4命令分、何か命令を挟み込める。
たとえばvprefetchとかでデータの先読みができる。

Cellで同じことをやると、積和がevenパイプ16回の操作に対して
oddパイプの操作は計24回（4ロード＋16シャッフル＋4ストア）
しかもストリーム処理に必要なMFC DMAコマンドを発行するにもodd
パイプラインなんで、ますますodd側がネックになる。

Cellは128ビットSIMDのくせして実はLarrabeeよりも小回り利かない。

553 ：,,・´∀｀・,,）っ-○○○：2009/12/02(水) 20:58:56

Fermiの場合だと、1ワープ(32スレッド)で2つの行列を処理みたいな
感じになるのかな。
FP積和4回に対してロード1回、ストア1回、あとアドレス算出のために
整数演算１～2回？

データのアラインメントさえしっかりしてればロードネックにならずに
意外とLarrabeeなみの数字出るかもね。
落とし穴さえなければ、の話だけど。

554 ：デフォルトの名無しさん：2009/12/03(木) 01:19:20

1～2年後には「なんでL1に乗らなきゃ速度全く出ない設計にしたのか理解できない。Larrabeeは糞。」って言ってそう。

555 ：,,・´∀｀・,,）っ-○○○：2009/12/03(木) 01:27:32

L2のバンド幅でも余裕でFermiのL1帯域以上出ますが。

むしろGPUなんてレジスタに載らなきゃ性能出ないから。

556 ：デフォルトの名無しさん：2009/12/03(木) 02:12:58

HPC向けなら今でもTeslaやFirestreamが10倍以上の性能出せる分野は結構多いけど、
PC向けでi7の倍～数十倍の性能が出せる用途というのはエンコや編集、圧縮解凍、ウイルスチェック位の認識でいいのかな。
比較対象はi7 920と最近発売もしくは来年予定の2万円程度のGPU。
(HD5770/GTX275/Larrabeeの16コア位)

557 ：デフォルトの名無しさん：2009/12/03(木) 02:20:10

それと、RADEやGefoが苦手(同価格帯のCPUの倍以下、或いは下回る性能)で
Larrabeeが得意(数倍の性能)なジャンルがあれば教えてくれ。

558 ：,,・´∀｀・,,）っ-○○○：2009/12/03(木) 02:31:27

IBMの中の人もLarrabeeは文字列検索なんかが相対的に有用だと言ってるな。

559 ：デフォルトの名無しさん：2009/12/03(木) 02:38:46

なら、遺伝子みたいなパターン検索にも使えそうだな

560 ：デフォルトの名無しさん：2009/12/03(木) 07:30:17

Larrabeeは最強だぜ
なんせIntel様が開発しているんだ

561 ：デフォルトの名無しさん：2009/12/03(木) 08:42:34

Intel様の最強は実は結構少ないんだぜ？
ぶっちゃけ過去10年の成功作はPenM/Core2の2つだけなんだぜ。
IGPは語るだけ無駄
SSDは毎回ファームウェアがアレ
ネットバーストは黒歴史
Nehalemはハイエンドだけをi5とi7、1156と1366で取り合ってるし、
しかも来年互換しない1155/新1366?(DMI2)に変わる。
結局Core2の成功だけで後はパッとしない。

562 ：デフォルトの名無しさん：2009/12/03(木) 08:55:30

勝てばよかろうなのだ

563 ：デフォルトの名無しさん：2009/12/03(木) 09:38:32

妄想アム厨乙

> IGPは語るだけ無駄
寝言はGMAほどのシェアとってからほざけ

> ネットバーストは黒歴史
ハイエンドRISCを蹴散らしTop500のシェアを30パーセント以上にまで
引き上げた功績がありますが？

> Nehalemはハイエンドだけをi5とi7、1156と1366で取り合ってるし、
> しかも来年互換しない1155/新1366?(DMI2)に変わる。
それが功績と何の関係が？
リプレースのコストがかかるのは懐がさびしい人にはきついだろうが
それでもAMDのCPUは売れてない現実

564 ：デフォルトの名無しさん：2009/12/03(木) 09:43:51

Phenom IIはハイエンドの955ですら最弱のCore i5にも勝てない要らない子

565 ：デフォルトの名無しさん：2009/12/03(木) 10:03:11

>寝言はGMAほどのシェアとってからほざけ
性能の事じゃねーの？

566 ：デフォルトの名無しさん：2009/12/03(木) 10:06:15

大衆が買わせるだけの訴求力がない性能なんて無駄

567 ：デフォルトの名無しさん：2009/12/03(木) 10:39:34

全部セロリンでいいな

568 ：デフォルトの名無しさん：2009/12/03(木) 11:25:09

>>563
> 妄想アム厨乙
>
> > IGPは語るだけ無駄
> 寝言はGMAほどのシェアとってからほざけ
所詮CPUのおまけでシェア取ってるだけ。
性能や機能には誰も期待していないのが現実。

> > ネットバーストは黒歴史
> ハイエンドRISCを蹴散らしTop500のシェアを30パーセント以上にまで
> 引き上げた功績がありますが？
圧力とリベート。

> > Nehalemはハイエンドだけをi5とi7、1156と1366で取り合ってるし、
> > しかも来年互換しない1155/新1366?(DMI2)に変わる。
> それが功績と何の関係が？
ミドル以下は相変わらずCore2まかせが1年続いていて、
世代交代やプラットフォームの更新がイマイチ。
半年くらいでi7/i5/i3でCore2を更新も出来ない開発力

> リプレースのコストがかかるのは懐がさびしい人にはきついだろうが
> それでもAMDのCPUは売れてない現実
圧力とリベート

569 ：デフォルトの名無しさん：2009/12/03(木) 11:26:59

ピンク色の妄想にとりつかれてるな

「圧力とリベート」(ｷﾘｯ

（笑）

570 ：デフォルトの名無しさん：2009/12/03(木) 11:29:42

> ミドル以下は相変わらずCore2まかせが1年続いていて、
> 世代交代やプラットフォームの更新がイマイチ。
> 半年くらいでi7/i5/i3でCore2を更新も出来ない開発力

モバイルは相変わらずK8コア任せが4年以上続いていて
世代交代やプラットフォームの更新がイマイチ。
K8のSSEを128ビット化しただけのコアを3年連続で続投するだけの開発力

こうですかわかりません＞＜

571 ：デフォルトの名無しさん：2009/12/03(木) 11:32:57

AMDは圧力なんてかけなくても勝手に死んでるんですよ性能悪いから
ダンピングまがいの安売りも焼け石に水

Radeonが好調でも本体のAMDが足引っ張って赤字
ATIが報われなさ過ぎる

572 ：デフォルトの名無しさん：2009/12/03(木) 11:47:38

> モバイルは相変わらずK8コア任せが4年以上続いていて

ノートPCのK8はもう5年以上前から投入されてます。
http://journal.mycom.co.jp/news/2004/09/21/101.html

ノートという成長市場を後回しにし続けた結果がこのざま。

573 ：デフォルトの名無しさん：2009/12/03(木) 11:49:12

赤字の主要因は工場じゃねえの？

574 ：デフォルトの名無しさん：2009/12/03(木) 11:55:16

淫照は所詮犯罪行為と圧力で独占的地位にいてシェアを維持しているだけの糞企業だろ。
まともに競争したら、流石に逆転するとは言わないが、その差は7：3か6：4程度で、8：2も差は付かない。
そもそもAMD排斥でDellに60億$とかありえないだろw
6000億円もリベートしないとAMDに勝てないと言ってるようなもの。
勿論HPやNECとかにも規模に応じた多額の排斥リベートしている。
お前らの金が犯罪行為に使われてるんだぜ。
もしかしてIntelは無実で反トラスト法には違反してないとかほざくつもりですか？

575 ：デフォルトの名無しさん：2009/12/03(木) 11:59:00

＞寝言はGMAほどのシェアとってからほざけ

GMAってあれだね金魚の糞みたいなものだし
windows使うと勝手についてくるIEとか見たいなもんだからね
Intel様も早くララビー出してGPUもすごいんだってところ見せて欲しいね

576 ：デフォルトの名無しさん：2009/12/03(木) 12:04:51

CPUは普通物理原価より工場の減価償却費や人件費のほうが高くなる。
大したマーケットも無いのに、200mm²以上のダイを1万円台とか、
コストを考えればあり得ない。

実力拮抗してるメーカーが存在すれば普通はダンピングになるところだが、
Intelを揺るがすほど売れてない上にAMDが自分の首を締めてるだけだから
誰も訴えないだけ。たいした商慣行だよ。

577 ：デフォルトの名無しさん：2009/12/03(木) 12:05:40

AMD厨が大量に釣れてますな

578 ：デフォルトの名無しさん：2009/12/03(木) 12:22:56

一企業だけで6000億のリベートが大したことないですか
揺るがさないならリベートや圧力無しでお願いしますよ淫照さん

579 ：デフォルトの名無しさん：2009/12/03(木) 12:23:12

製造コストと市場規模から考えればPhenom II X4の適正価格は4～5万程度。
今の状況はアブダビからもらった札を同梱して強引に売ってるようなもん。
連結子会社ではなく完全にGFをアブダビに売り払ってファブレス化する
くらいしか健全化の手立てはないだろう。

580 ：デフォルトの名無しさん：2009/12/03(木) 12:25:21

完全に資本関係を絶つという噂もあるな。
絶った直後に大量受注で涙目とかになったりして

581 ：デフォルトの名無しさん：2009/12/03(木) 17:46:55

ハードウェア板か自作板でやれゲハ脳ども

582 ：デフォルトの名無しさん：2009/12/03(木) 17:48:29

圧力とリベート(ｷﾘｯ

583 ：デフォルトの名無しさん：2009/12/03(木) 18:19:36

せっかくのIntelの投資を無駄にして欲しくないですねAMDさん

584 ：デフォルトの名無しさん：2009/12/03(木) 19:49:16

Larrabeeなど我々の中では小物！
http://pc.watch.impress.co.jp/docs/news/20091203_333078.html

585 ：デフォルトの名無しさん：2009/12/03(木) 20:08:21

>>583
和解金を使ってPhenom IIをダンピングする作業が続くお

586 ：デフォルトの名無しさん：2009/12/03(木) 20:56:49

Intelの投資(ｷﾘ
盗人猛々しすぎw

587 ：デフォルトの名無しさん：2009/12/03(木) 20:58:46

>>585
それ以上のダンピングをIntelがするから無意味だぜ

588 ：デフォルトの名無しさん：2009/12/03(木) 21:15:20

アム厨必死だなあ

589 ：デフォルトの名無しさん：2009/12/03(木) 21:51:47

AMDのダンピングは正当行為だ(ｷﾘｯ

って何のスレだっけここ

590 ：,,・´∀｀・,,）っ-○○○：2009/12/03(木) 23:24:16

俺がCUDAをまくスレ

591 ：デフォルトの名無しさん：2009/12/03(木) 23:57:08

CUDAらねー

592 ：デフォルトの名無しさん：2009/12/04(金) 00:36:26

AMDってEUに不当廉売で排除されそうなんだけど

593 ：,,・´∀｀・,,）っ-○○○：2009/12/04(金) 00:45:32

昨日の味方は今日の敵

594 ：デフォルトの名無しさん：2009/12/04(金) 02:30:48

ダンピング：不当に安い価格で商品を販売すること。
赤字で潰れそうなAMDが出来るわけないだろJK
基本的に強者が弱者を排除するための行為だからな

そろそろ淫厨vsアム厨は下記スレででもやってくれ
http://pc11.2ch.net/test/read.cgi/jisaku/1257308022/

595 ：デフォルトの名無しさん：2009/12/04(金) 02:34:29

アム厨まだ粘ってるのか

596 ：デフォルトの名無しさん：2009/12/04(金) 04:15:20

>>594
残念、クアッドコアが1万円台などの破格の価格設定の結果として
大幅な赤字が出てるわけで、製造コストに見合った価格設定でないと
それはEUの定めるところの不当廉売の排除対象になりうることがある。

競争はIntelとだけやってると思ってるだろ？違うんだよな。
x86しか見てないからそう思うだけだ。

597 ：デフォルトの名無しさん：2009/12/04(金) 05:55:12

>>596
60億$のリベートしちゃったIntelが真っ先に提訴されてるけどね。
ほとんどタダ同然の多額のリベートは明らかに不当廉売。
違うにしても、正常な競争の範囲じゃないことは明らか。
ちなみに市場の低価格は、相対的な性能やブランド、需要差にもよるから仕方ない部分もあるね。

そもそもなんでIntelなんかを擁護してるんだあんたらは？
Intelが違法商行為やめて正々堂々競争すればいいだけだろ。
その結果のAMD敗北なら構わんよ。

そういうのがCPUに比べ少ないGPU/GPGPUの競争は、つまらん足の引っ張り合いはせずに、
製品とソリューションでの殴り合いのガチンコ競争でお願いしたいところ。

598 ：デフォルトの名無しさん：2009/12/04(金) 08:34:06

赤字＝原価割れ　ではないと思うけど

599 ：デフォルトの名無しさん：2009/12/04(金) 10:15:31

なんかデジャブ感があるな。

600 ：デフォルトの名無しさん：2009/12/04(金) 10:33:11

人件費・減価償却費を回収できない価格設定にするのはおかしいだろう。

601 ：デフォルトの名無しさん：2009/12/04(金) 10:37:19

アホ乙

602 ：デフォルトの名無しさん：2009/12/04(金) 10:46:04

まあ価格上げたらますます売れないけど

603 ：デフォルトの名無しさん：2009/12/04(金) 12:48:59

>>584
>同社ではSCCを第2世代のメニイコアプロセッサとして位置付けている(第1世代はLarrabee)。
>現在、IntelとHP、Yahoo!による「Open Cirrus」コラボレーションの研究者は、
>クラウドアプリケーションを、データ集約型のJAVAソフトウェアフレームワークである
>Hadoopを使い移植を進めている。

Intel自身もGPGPUは通過点に過ぎず、メニーコアが理想解だと考えているのですね。
Apache HadoopがSCCをサポートするなら、ソフトウェアをHadoopに対応させるだけで
メニーコアにもグリッドコンピューティングにも対応済みとなり、大変ありがたいです。

604 ：デフォルトの名無しさん：2009/12/04(金) 12:53:04

LarrabeeはGMAの置き換え＆HPC用アクセラレータであって
アプリケーション用プロセッサではない。

>同社ではSCCを第2世代のメニイコアプロセッサとして位置付けている(第1世代はLarrabee)。
あとこれは嘘。第一世代は80コアのプロトタイプのPolaris。
いまだにPolarisとLarrabeeの区別のつかないアホ記者がいるのはうんざりする。

605 ：デフォルトの名無しさん：2009/12/04(金) 13:18:51

SCCのダイ写真からすると1コアがかなり小さいから、
Larrabeeのようなベクタユニットもってないだろうしな。

606 ：デフォルトの名無しさん：2009/12/05(土) 02:19:35

>>552
団子さんに聞きたいのだが、Ｌａｒｒａｂｅｅって2GHzくらいで動くんでしょ。
仮にCellが進歩していたとして、4.5GHz位だったとして、どっちの方が速くなるの？
今Cellは3.2GHzで、Larrabeeを2GHzと仮定したら、Cell1サイクルに対してLarrabeeは1.6サイクルになる。
命令数とトータルのサイクル数は違うように思えるんだけど、どうなんだろう？

607 ：デフォルトの名無しさん：2009/12/05(土) 03:35:12

何をさせるかによるだろｗ

608 ：デフォルトの名無しさん：2009/12/05(土) 04:19:02

GHz馬鹿ってまだ居たんだな

609 ：デフォルトの名無しさん：2009/12/05(土) 09:29:15

>>606
Larrabeeは命令で消費サイクル大幅に変わるから何倍も遅くなる。

610 ：デフォルトの名無しさん：2009/12/05(土) 12:19:00

> 消費サイクル大幅に変わるから何倍も遅くなる
逆にいえば何倍も早くなることもあるのね

611 ：,,・´∀｀・,,）っ-○○○：2009/12/05(土) 12:36:29

>>606
Larrabee 8コア対Cell 8コアなら勿論Larrabeeだろう
・1サイクルあたりの浮動小数演算数がCellの4倍
・1サイクルあたりのロード・ストア帯域の合計はCellの8倍
・1命令にswizzleあるいはbroadcast付きのロードを畳み込める

この問題、ちょっと後で考えてみたんだが、Cellの場合は転置行列の積を求めてから
転置したほうが速くてld×4, + shufb×8 + st×4 で、Even, Oddともに
16サイクル程度に抑えられることが判明。
つまり1行列あたり、Larrabee 5サイクルに対しCellは16サイクルのスループット。
Larrabeeが1.5GHz程度ならCellは4.8GHz以上で動けば引き離せる。

キャッシュ/ローカルメモリ外のデータを取ってくるってことになると、
メモリ帯域ベンチになっちゃう（今度は演算ユニットを持て余す）ので
あまりコアの効率を論じることは無意味になるかもしれない。

>>609は言ってることは本当だがこのケースでは嘘つき。
scatter/gatherで複数キャッシュラインに跨るロード・ストアをやったとき以外は
1サイクルに収まる。
シャッフル＋積和算みたいなのは、パイプラインステージ間での受け渡しの可能なCISC形式の方が
RISC的にシャッフルユニットと積和で別々のユニットになってる方式よりもレイテンシの面で有利。

612 ：,,・´∀｀・,,）っ-○○○：2009/12/05(土) 13:26:12

とか書いているうちにディスクリートGPU版のキャンセルが報じられたようです

613 ：デフォルトの名無しさん：2009/12/05(土) 13:30:27

４G越えは無理だろう。Cellは。

614 ：,,・´∀｀・,,）っ-○○○：2009/12/05(土) 13:34:08

HPC向け製品が棚上げになったCell
コンシューマ向けが棚上げになったLarrabee

当分（永久に？）直接対決はなさそうだな

俺はしばらくNVIDIAの顔色伺っておくか。

615 ：デフォルトの名無しさん：2009/12/05(土) 13:47:11

http://www.geocities.jp/andosprocinfo/wadai09/20091205.htm

616 ：デフォルトの名無しさん：2009/12/05(土) 13:53:55

>>614
NVidiaお終いだろ
Intelと同様にAMDに多額の金支払わないと
独禁法で排除されそうだぞ

617 ：デフォルトの名無しさん：2009/12/05(土) 16:01:37

Phenomの廉売による損失補填費をNVIDIAが負担ですね。わかります。

618 ：デフォルトの名無しさん：2009/12/05(土) 16:47:01

NVIDIAって訴えられるほど儲かってんの？
なんか定期的に赤字のニュースを見るような

619 ：デフォルトの名無しさん：2009/12/05(土) 17:21:38

ありゃま。
安く遊ぶには当分CUDAと付き合わざるを得ないな。

620 ：,,・´∀｀・,,）っ-○○○：2009/12/05(土) 17:25:40

CPU側の進化に任せるって手もあるけどね。
文字列探索みたいな1バイト単位のオペレーションならSSE*にまだまだ優位性がある。

621 ：デフォルトの名無しさん：2009/12/06(日) 09:44:05

トリップ検索？

622 ：,,・´∀｀・,,）っ-○○○：2009/12/06(日) 11:52:23

普通にBLASTとかその他テキスト全文検索

623 ：デフォルトの名無しさん：2009/12/06(日) 12:23:25

団子てめぇトリつけろ
ATI Streamで解析してやんよ

624 ：,,・´∀｀・,,）っ-○○○ ◆/tise/KisQ ：2009/12/06(日) 12:35:46

そういえばこんなネタ鳥あったな

625 ：,,・´∀｀・,,）っ-○○○ ◆xvt3t9gVzFz9 ：2009/12/06(日) 12:36:55

これ解析して

626 ：デフォルトの名無しさん：2009/12/07(月) 20:41:21

Intel、Larrabeeグラフィックスチップの計画を破棄
http://www.itmedia.co.jp/news/articles/0912/07/news041.html

さようならLarrabee
こんにちはSCC

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

ぼくちゃんの最強プロセッサを考えてみたはいいが、大風呂敷だったって事だよな。
ただ最終的にはLarrabeeのような方向にシフトしていくのは間違いないだろう。

だがそれにしても団子は痛い。
他の団子のレスは大体いいと思うが
>>89-90,95,98,101,156とかはブーメラン過ぎる。
出てもいないもので比べるなとあれほど(ry

628 ：デフォルトの名無しさん：2009/12/07(月) 23:26:51

>>626
関連記事を読んで気がついたのですが、
http://www.itmedia.co.jp/news/articles/0808/05/news017.html
>x86コアを多数集積した初の「メニーコア」アーキテクチャだとしている。
「だとしている」のはIntelですね。つまり、
http://pc.watch.impress.co.jp/docs/news/20091203_333078.html
>同社ではSCCを第2世代のメニイコアプロセッサとして位置付けている(第1世代はLarrabee)。
この「第1世代はLarrabee」という説明は正しいという事になります。
Intelの考えではPolarisは第2世代メニーコアのプロトタイプの一つなのでしょう。

>>604
>あとこれは嘘。第一世代は80コアのプロトタイプのPolaris。
>いまだにPolarisとLarrabeeの区別のつかないアホ記者がいるのはうんざりする。
見事なブーメランです。

629 ：デフォルトの名無しさん：2009/12/07(月) 23:32:37

ええぇぇぇえええ

630 ：デフォルトの名無しさん：2009/12/07(月) 23:39:38

Intelオフィシャルもみない情弱ワロタｗｗｗ

631 ：デフォルトの名無しさん：2009/12/07(月) 23:40:20

しかも見事なブーメランとか勝ち誇ってるのが痛々しいｗｗｗｗｗｗ

632 ：,,・´∀｀・,,）っ-○○○：2009/12/07(月) 23:45:49

SCC発表のPDF読めよ。
ああそうか英語読めないからバイトの中国人のこと真に受けるのか

633 ：・´ω｀・）・´ω｀・,,）*・´ω｀・）っ-○○○：2009/12/08(火) 00:07:56

いずれにせよ当分NVIDIAに寝返るわ（・´ω｀・）

634 ：デフォルトの名無しさん：2009/12/08(火) 01:03:06

　　　　　　ﾊ,,ﾊ
　　　　　（ﾟωﾟ )　　お断りします
　　　　／　　　＼
　 ((⊂ 　）　ﾉ＼つ))
　　　　　（＿⌒ヽ
　　　　　　ヽ　ﾍ　}
　ε≡Ξ　ﾉノ｀J

635 ：・´ω｀・）・´ω｀・,,）*・´ω｀・）っ-○○○：2009/12/08(火) 01:08:51

（・´ω｀・）

636 ：628：2009/12/08(火) 02:55:23

>>632
SCC発表のPDFというのはこれですよね。
http://download.intel.com/pressroom/pdf/rockcreek/SCC_Announcement_JustinRattner.pdf
14ページを見ると、Teraflops Research Processorの後継プロセッサが
Single-chip Cloud Computerである事は明らかです。
ですが、Intel自身がSCCをsecond generationと呼んでいる
ソースは発見できませんでした。

検索範囲を広げてみると、下記のニュースが見つかりました。
http://www.theregister.co.uk/2009/12/02/intel_scc/
>The SCC is the second-generation experimental processor
>in Intel's Tera-scale Computing Research Program,
>the first being the 80-core Polaris, which it demoed in 2007.
SCCはIntelテラスケールコンピューティング研究プロジェクトの第2世代実験プロセッサであり、
第1世代は2007年にデモが行われた80コアPolarisである。
(Intel関係者発言の引用ではなく地の文による解説です)

「第1世代はLarrabee」は>>604の言う通り、嘘ですね。失礼しました。
「同社ではSCCを第2世代のメニイコアプロセッサとして位置付けている」も不正確です。
「同社ではSCCをPolarisの後継実験プロセッサとして位置づけている」が妥当な所です。
第1世代、第2世代という表現は報道側から出てきたように見えます。

637 ：デフォルトの名無しさん：2009/12/08(火) 03:26:55

うぜえ

638 ：デフォルトの名無しさん：2009/12/08(火) 09:08:45

ブーメランｗｗｗ

639 ：デフォルトの名無しさん：2009/12/09(水) 00:46:38

団子の自殺ﾏﾀﾞｰ？

640 ：デフォルトの名無しさん：2009/12/09(水) 01:04:51

だれか、Larrabee発表からキャンセルまでの団子の奇跡をまとめてサイト
つくってくれないかな。

641 ：デフォルトの名無しさん：2009/12/09(水) 03:01:04

信じられない話ってLの件ですか？

投稿者 F田 : 2009年12月07日 23:01

いえいえ、あれは商品として登場したらその方が信じられなかったでしょうw

投稿者 ohara : 2009年12月08日 00:39

大原もLarrabeeが商品化なんてことは信じられなかったとか言ってるぞｗ

642 ：,,・´∀｀・,,）っ-○○○：2009/12/09(水) 03:23:06

Ctのβ来たね

643 ：デフォルトの名無しさん：2009/12/09(水) 03:34:47

Ctはロードマップどおりか

644 ：デフォルトの名無しさん：2009/12/09(水) 07:38:49

なんつーか

これはひどい

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

CELLのときみたいに
団子のIntel叩きがはじまるかな?

646 ：,,・´∀｀・,,）っ-○○○：2009/12/09(水) 12:58:52

別の遊び道具を用意してくれたので別に叩く理由はない

647 ：デフォルトの名無しさん：2009/12/09(水) 19:47:29

そして第2弾計画発表
http://www.pcgameshardware.com/aid,701071/Larrabee-2-is-still-possible/News/

648 ：デフォルトの名無しさん：2009/12/09(水) 20:57:16

>>647
P5前提じゃあ周波数あげるか数を増やすかキャッシュメモリを増やすかしかないと思うけど、どうやるんだ？

649 ：デフォルトの名無しさん：2009/12/09(水) 21:11:38

32nm

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

狼少年

651 ：デフォルトの名無しさん：2009/12/10(木) 23:45:34

2009/12/10 GPUコンピューティングの現状とスーパーコンピューティングの未来
http://www.slideshare.net/pfi/20091210-gpu

652 ：デフォルトの名無しさん：2009/12/11(金) 03:50:37

こうやって宣伝して人を錯覚させていくんだなぁ。

653 ：デフォルトの名無しさん：2009/12/11(金) 05:20:13

緑のGPUの写真はモックアップで遅れまくり、青いのは失敗でキャンセル。
今頃ショックで引き篭もってんじゃないかな。

654 ：デフォルトの名無しさん：2009/12/11(金) 12:20:27

>>652
いろんな思惑がある人が宣伝するから、結果的に平均値に収まる。

655 ：デフォルトの名無しさん：2009/12/11(金) 13:02:29

緑もキャンセルしたら笑えるな

656 ：デフォルトの名無しさん：2009/12/11(金) 14:21:51

>>651
＞青のGPU

VIA?

なんかOpenCLにも対応するらしいしな。
ttp://pc.watch.impress.co.jp/docs/news/20091211_335237.html

657 ：デフォルトの名無しさん：2009/12/11(金) 15:42:43

Larrabeだろ明らかに

658 ：デフォルトの名無しさん：2009/12/11(金) 22:30:39

実はchrome400/500がcpu技術を用いられて開発された最初のgpuだったりする

659 ：デフォルトの名無しさん：2009/12/11(金) 22:40:20

いらねーよ、お絵かきには

660 ：デフォルトの名無しさん：2009/12/11(金) 23:09:05

>>658
あやまれ！renditionにあやまれ！（AAｒｙ

661 ：デフォルトの名無しさん：2009/12/11(金) 23:12:21

最近でたGPGPUベンチの名前って何だっけ

662 ：デフォルトの名無しさん：2009/12/12(土) 00:44:18

VIA始まった。
この調子でがんばって･･･なの。

663 ：デフォルトの名無しさん：2009/12/12(土) 02:56:32

アジア諸国vs全世界
核使わないならアジアが圧倒的有利だな

664 ：デフォルトの名無しさん：2009/12/12(土) 04:35:23

食糧難で終わるかもしれんぞ

665 ：デフォルトの名無しさん：2009/12/12(土) 10:05:59

じゃあ戦略シミュレーションをGPGPUしてみろよ。

666 ：デフォルトの名無しさん：2009/12/12(土) 16:54:39

IntelのNvidaの買収確定だな

667 ：,,・´∀｀・,,）っ-○○○：2009/12/12(土) 16:55:19

ソウスだせ

668 ：デフォルトの名無しさん：2009/12/12(土) 16:59:04

Nvidaってどこの会社ですか？

669 ：,,・´∀｀・,,）っ-○○○：2009/12/12(土) 16:59:56

Nidaってど（ｒｙ

670 ：デフォルトの名無しさん：2009/12/12(土) 17:17:33

ロバート・クリングリーが犯人のようだな

671 ：,,・´∀｀・,,）っ-○○○：2009/12/12(土) 17:22:58

ああ、それは日本文化研究してる韓国大学教授なみには説得力あるな

672 ：デフォルトの名無しさん：2009/12/15(火) 17:17:03

Adobe's Mercury Playback Engine for CS5 is CUDA-only! - Bright Side Of News*
http://www.brightsideofnews.com/news/2009/12/14/adobes-mercury-playback-engine-for-cs5-is-cuda-only!.aspx

673 ：デフォルトの名無しさん：2009/12/15(火) 21:53:00

Kaspersky enlists CUDA to kill viruses
ttp://www.fudzilla.com/content/view/16849/38/

674 ：デフォルトの名無しさん：2009/12/15(火) 22:45:30

>>672
PhotoshopやFlashで嘘ついて恥をかいたのをまた繰り返すみたいだな

675 ：デフォルトの名無しさん：2009/12/17(木) 11:42:16

なんというか言葉が見当たらない

SemiAccurate :: Oak Ridge cans Nvidia based Fermi supercomputer
ttp://www.semiaccurate.com/2009/12/16/oak-ridge-cans-nvidia-based-fermi-supercomputer/
【PC Watch】米FTC、独占的地位を利用し競争を阻害したとしてIntelを提訴
ttp://pc.watch.impress.co.jp/docs/news/20091217_336397.html

676 ：デフォルトの名無しさん：2009/12/17(木) 20:23:23

すごい商習慣だな

677 ：デフォルトの名無しさん：2009/12/17(木) 20:25:20

アメリカではよくあること

678 ：デフォルトの名無しさん：2009/12/17(木) 22:19:23

Intelは世界中で悪の組織扱い
MSですら非を認めて各ブラウザに配慮しているのに

しかしIntelの反論が小沢や亀井みたいに尊大で往生際が悪くて笑える。
ttp://enterprise.watch.impress.co.jp/docs/news/20091217_336454.html

679 ：デフォルトの名無しさん：2009/12/17(木) 23:29:58

もうORNLスパコンにHD5xxxをぶち込めば

680 ：デフォルトの名無しさん：2009/12/18(金) 00:23:02

FOXC最高～

681 ：デフォルトの名無しさん：2009/12/18(金) 01:08:06

アメリカ自体がintelの味方だから・・。

682 ：デフォルトの名無しさん：2009/12/18(金) 02:05:45

IntelもAMDもNVIDIAもBig Blueもアメリカ企業だから、潰し合いしたところで結局内部抗争なんだよね。
半導体産業を韓臺にもぎ取られてヒイヒイいってる日本とは次元が違う。

683 ：デフォルトの名無しさん：2009/12/18(金) 02:44:29

AMDはもう油でしょ

684 ：デフォルトの名無しさん：2009/12/18(金) 12:40:28

韓国は大嫌い

685 ：デフォルトの名無しさん：2009/12/21(月) 00:18:46

お前ら板間違えてね？ｗｗｗ

686 ：デフォルトの名無しさん：2009/12/22(火) 05:31:02

ATI Stream SDK v2.0 reaches production status - The Tech Report
ttp://techreport.com/discussions.x/18177
AMD Developer Forums Forums - AMD's new release of ATI Stream SDK v2.0 w/ OpenCL(tm) 1.0
ttp://forums.amd.com/forum/messageview.cfm?catid=390&threadid=124123&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+AmdDeveloperForums-Opencl+%28AMD+Developer+Forums+-+OpenCL%28TM%29%29

687 ：デフォルトの名無しさん：2009/12/22(火) 06:13:36

ATI Stream対応C++言語コンパイラ登場(CUDAも)
ttp://pc.watch.impress.co.jp/docs/news/20091221_338330.html

688 ：デフォルトの名無しさん：2009/12/22(火) 08:39:15

過疎ﾜﾛﾀ
↓燃料投下
ttp://www.kfcr.jp/goose.html

689 ：デフォルトの名無しさん：2009/12/22(火) 13:04:21

そのコンパイラーだと、Atiのほうが早いのか。
HD4850のほうがGTX280より早いってのがね。

てか、これでOpenCLがいらなくなったんじゃね？

690 ：デフォルトの名無しさん：2009/12/22(火) 13:38:00

対応ツールなんか１種類でいいから手放せないぐらい便利に
なるもの作りゃいいのに。

691 ：デフォルトの名無しさん：2009/12/22(火) 17:23:10

汎用品は便利だけど速度は出ないんだろうな。

692 ：デフォルトの名無しさん：2009/12/22(火) 20:14:37

>>688
GTX280　1.47
HD4850　3.44

GeForce遅い
GPGPUに特化したんじゃなかったのか

693 ：デフォルトの名無しさん：2009/12/22(火) 21:23:40

http://www.amazon.co.jp/exec/obidos/ASIN/484432814X/masafumislabo-22/

694 ：デフォルトの名無しさん：2009/12/22(火) 21:50:47

はいはいワロスワロスｗ

168 ：Socket774 [↓] ：2009/12/21(月) 22:13:41 ID:X38nbLUj
GTX280の倍精度は理論値でも77.82gflops
4850は200gflopsか

695 ：デフォルトの名無しさん：2009/12/22(火) 22:02:57

転載するのは構わんが、アフィは外してやれよ

696 ：デフォルトの名無しさん：2009/12/22(火) 23:02:27

>>692
CUDAの最適化が甘いんだろきっと。
単精度でそんな遅いはずがない。

697 ：デフォルトの名無しさん：2009/12/22(火) 23:20:19

おまえわざとか

698 ：デフォルトの名無しさん：2009/12/23(水) 00:08:07

いくらめんどくさいからってリンク先の内容を読んでからレスしてくださいよ

699 ：デフォルトの名無しさん：2009/12/23(水) 00:50:58

単精度で動かしたデータ見てみたいな。

700 ：デフォルトの名無しさん：2009/12/23(水) 01:27:29

明日はイブですよ。
皆さんの恋人はGPUですか？

701 ：,,・´∀｀・,,）っ-○○○：2009/12/23(水) 02:05:11

ほんじつは

へいかの

たんじょうびです

みなさまの

へいわを

いのります

702 ：デフォルトの名無しさん：2009/12/23(水) 08:52:08

ほ

へ

た

み

へ

い

おまえにはがっかりだよ

703 ：デフォルトの名無しさん：2009/12/23(水) 21:04:57

>>702
俺も702を読む前に1～2分考えてがっかりした。
時間返せw

704 ：デフォルトの名無しさん：2009/12/23(水) 21:52:17

>>703
ヒントよろ

705 ：デフォルトの名無しさん：2009/12/24(木) 01:51:37

なんのことだかさっぱり・・・

706 ：デフォルトの名無しさん：2009/12/24(木) 22:21:07

コンパイラでただけでこうも過疎るとは

707 ：,,・´∀｀・,,）っ-○○○：2009/12/24(木) 23:11:34

ヒント：クリスマス

708 ：デフォルトの名無しさん：2009/12/25(金) 04:50:53

これだからATiは使えん
AMD: 4000-series Radeons have 'known performance issues' with OpenCL - The Tech Report
ttp://techreport.com/discussions.x/18201

709 ：デフォルトの名無しさん：2009/12/25(金) 09:40:33

>>708
お前馬鹿だな
今更旧世代のHD48xxシリーズを検証した記事持ってきてどうするんだ
今論じるべきは今後主流になる最新のHD5xxxシリーズの性能だろ

710 ：デフォルトの名無しさん：2009/12/25(金) 10:59:35

まあしかし既存のユーザーは問題にするだろ。
大量に使ってるところなんかは簡単に買い換えられないだろうしさ。

711 ：デフォルトの名無しさん：2009/12/25(金) 13:13:35

DX11に対応した固定機能以外は、ただのHD4kのSP2倍、メモリ帯域1.2倍でしかないので
HD4kがダメなら当然5kもダメ

712 ：デフォルトの名無しさん：2009/12/25(金) 13:59:18

そのほかに4倍増しの部分があったりする

713 ：デフォルトの名無しさん：2009/12/25(金) 15:52:34

>>711
HD4xxxのLDSは実質使えないから、
ローカルがグローバル状態なのがまずいんじゃないの？

714 ：デフォルトの名無しさん：2009/12/25(金) 19:19:22

DirectComputeのcs4.1なら使えるんだけどな。
OpenCLの仕様ではコード上のshared領域と
LDSのmappingが難しい。

715 ：デフォルトの名無しさん：2009/12/26(土) 04:16:59

EvergreenのISAドキュメント出たけど、結構変わったんだな。

716 ：デフォルトの名無しさん：2009/12/26(土) 04:35:59

ATI Stream SDK v2.0 Documentation
http://developer.amd.com/gpu/ATIStreamSDK/pages/Documentation.aspx

717 ：デフォルトの名無しさん：2009/12/26(土) 09:51:42

SADがかなり笑える。
普通に32bitでの|A-B|+Cかと思ったら
8bitでの|A[7:0]-B[7:0]|+|A[15:8]-B[15:8]|+|A[23:16]-B[23:16]|+|A[31:24]-B[31:24]|+C
でCに指定できるのがXYZW命令スロットの隣の結果。
1サイクルで4x4のSADが完了する。
物凄い用途を絞った命令だ。

718 ：,,・´∀｀・,,）っ-○○○：2009/12/26(土) 10:04:12

何を今更
SSEやCellに実装されてるSADも元々8ビット単位の絶対差の和だよ。

719 ：デフォルトの名無しさん：2009/12/26(土) 10:11:42

いや、SIMD>VLIWの中にさらにSIMD命令を入れちゃったのが勘所

720 ：,,・´∀｀・,,）っ-○○○：2009/12/26(土) 10:30:25

たしかに変態だな

721 ：デフォルトの名無しさん：2009/12/26(土) 13:38:32

結局、Larrabeeなんて出ねーよと言っていた連中が正しかったか
団子も途中から悟ったのか、Larrabeeの時代がくるっていってのをやめて
nVidia批判に切り替えてたからな

722 ：デフォルトの名無しさん：2009/12/26(土) 14:04:04

もう次のRADEONは演算単位を8bit整数にして実数はバイトシリアルで
処理すればいいんじゃないかｗ

723 ：,,・´∀｀・,,）っ-○○○：2009/12/26(土) 14:08:26

>>721
ﾌﾟｯ

>>722
どのみちFusionでSSEユニットとの統合を実現するにはバイト単位のオペレーションは必須

724 ：デフォルトの名無しさん：2009/12/26(土) 14:12:23

団子も赤っ恥掻いて言い返せなくなったみたいだなｗ

725 ：デフォルトの名無しさん：2009/12/26(土) 14:15:00

大丈夫、団子なら何食わぬ顔でLarrabee2の時代が来るって言い始める。

726 ：デフォルトの名無しさん：2009/12/26(土) 14:52:37

暇な奴らだな

727 ：,,・´∀｀・,,）っ-○○○：2009/12/26(土) 14:54:47

ﾆﾔﾆﾔ

728 ：,,・´∀｀・,,）っ-○○○：2009/12/26(土) 23:09:15

http://www.geocities.jp/andosprocinfo/wadai09/20091226.htm

> ２．NVIDIAはFermiのSP数を削減
>
> 　　2009年12月21日のSemiaccurateが，NVIDAがFermiのStream Processor数を512から448に削減と書いています。
> 確かに，NVIDIAのC2050とC2070ボードのドキュメントでは，448SPになっています。クロックは1.25GHｚから1.4GHｚと
> なっており，ピークの倍精度浮動小数点演算性能は，560～627.2GFlopsとなります。そして24個のGDDR5メモリを
> 搭載したボードの消費電力は225Wとなっています。
>
>　　Semiaccurateは，64個のSPを止めてもやっと225Wと消費電力が大きく，2009年12月16日の記事では，Oakridge
> 国立研究所のJaguarの将来世代でFermiを使うという話はご破算になったと報じています。
>
>　　そして，$2499と$3999というGPUボードより1桁高い値段のボード用のチップでも2クラスタを殺さないと良品が
> とれない状況では，量産のGPUボードはどうなるのか。Fermiは時期が遅れ，性能が低く，発熱が大きく失敗作で，
> GPUとしてはAMDに勝てないと結論付けています。

729 ：,,・´∀｀・,,）っ-○○○：2009/12/26(土) 23:16:01

Intelが敢えてLarrabeeキャンセルした理由がようやくわかったね

730 ：デフォルトの名無しさん：2009/12/26(土) 23:32:54

なんだ
S3の独壇場じゃないかGPUは
いつ追いつけるんだ、お前らは

731 ：デフォルトの名無しさん：2009/12/26(土) 23:55:01

IntelがS3を買収・投資すればすぐにGPGPU(APU)時代が来るな

732 ：,,・´∀｀・,,）っ-○○○：2009/12/26(土) 23:59:08

むしろNanoと統合して頑張ってくれ

733 ：デフォルトの名無しさん：2009/12/27(日) 00:01:03

逆にいえば、300W枠をギリギリまで使いきっても許されるGeforceのハイエンドなら
512SPのまま出るんじゃないの

734 ：デフォルトの名無しさん：2009/12/27(日) 00:06:38

歩留まりも悪かったのでは

735 ：デフォルトの名無しさん：2009/12/27(日) 00:28:59

電力は言い訳で歩留りだろうな
1割切るって予測だったし

736 ：,,・´∀｀・,,）っ-○○○：2009/12/27(日) 00:38:07

HPC向けにまで2シェーダ落ちを使わなければならないほどだから
GPUとしての競争力は（ｒｙ

737 ：デフォルトの名無しさん：2009/12/27(日) 00:40:45

>>729
> Intelが敢えてLarrabeeキャンセルした理由がようやくわかったね
>
ララビーキャンセルはラデオンに3D性能で勝てないことと、ドライバが糞で、開発環境も整っていないからだが。
サンプルすら存在せず比較も出来ないFermiなんか、要因の一つでしかない。

738 ：デフォルトの名無しさん：2009/12/27(日) 00:52:08

なんだかんだ言っても結局CUDA一択なんですけどね

739 ：,,・´∀｀・,,）っ-○○○：2009/12/27(日) 01:08:15

Radeon向けのコードでも書くとするか

740 ：,,・´∀｀・,,）っ-○○○：2009/12/27(日) 02:13:41

おまいらこれ応募した？
http://www.makebettercode.com/scc_software_research/form.php

741 ：デフォルトの名無しさん：2009/12/27(日) 07:52:34

>>730-732
VIAの場合別に技術リーダーになるつもりはないので
CPUとの統合なんてのは、今後数年先にもやりはしない
逆に費やすトランジスタに対して、効果の大きい改良は施す

まず現nanoの課題としてプリフェッチのバグを改善し、パフォーマンス改善したものを3000シリーズとして出す
次に45nm世代でダイサイズ確保のために何か増設しなきゃいけないので
CPUコアを増やし、徐々に増えてきたマルチスレッド対応ソフトに対応させる
この時点でGPUを統合しても、演算器を使う標準命令が存在しないため無駄になる
OpenCLで良いだろうと思うかもしれないが、APIレベルなら別に統合する必要はない

VIAが32nm使うまでにIntelが命令普及させてれば、そのときは統合するかもね
いやぁAVXなGPU作っちゃうかもしれないけど

742 ：,,・´∀｀・,,）っ-○○○：2009/12/27(日) 21:14:33

VIA（というかCentaur）ってSSEの型変換の特許持ってるから比較的有利な条件でx86ライセンス使えるんだっけな

743 ：デフォルトの名無しさん：2009/12/27(日) 21:27:47

少人数集団Centaurヤバス

744 ：デフォルトの名無しさん：2009/12/27(日) 21:34:18

armフリー＆x86フリーの環境で生きたい。
むしろSPARC

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

富士通社員乙

746 ：デフォルトの名無しさん：2009/12/29(火) 00:01:29

兄貴退社でRadeonはGPGPUから脱落したぞ

747 ：デフォルトの名無しさん：2009/12/29(火) 00:31:57

DQN風貌で、聞き取りづらい発音で淡々と喋るだけだったんでクビにして良かったと思う
AMDのイメージダウンだよあの男は

748 ：デフォルトの名無しさん：2009/12/29(火) 01:04:15

アニキはCore i7ユーザーになったみたい

749 ：デフォルトの名無しさん：2009/12/29(火) 01:17:49

開発者じゃないし。。

750 ：デフォルトの名無しさん：2009/12/29(火) 07:59:15

兄貴はAMDの開発、宣伝の中心人物だったのか・・・

751 ：デフォルトの名無しさん：2009/12/29(火) 15:02:00

辞めた途端土井のあんちゃん叩くとか最低だよな

752 ：,,・´∀｀・,,）っ-○○○：2009/12/29(火) 15:17:28

そりゃ「Core i7のマシン組みます」なんて円満退社の人間が言うことじゃないし

753 ：デフォルトの名無しさん：2009/12/29(火) 17:07:12

Pat Gelsingerは円満退社(笑)

754 ：デフォルトの名無しさん：2009/12/29(火) 17:31:33

あれはワロタなｗ
何したんだ日本AMDｗｗｗｗ

755 ：,,・´∀｀・,,）っ-○○○：2009/12/29(火) 17:41:13

>>753
ヴイエムウェア、Intelと VMware vSphere? 4 の販売拡大で合意
http://www.vmware.com/jp/company/news/releases/intel-oem-vmworld09.html

UMCはVMwareの親会社

756 ：デフォルトの名無しさん：2009/12/29(火) 17:47:31

1/22のOpenCLの本
糞本っぽいなぁ

757 ：デフォルトの名無しさん：2009/12/29(火) 18:08:09

>>755
UMCはファウンドリだろJK
しかも日付的にPatGelsinger関係ないし

758 ：,,・´∀｀・,,）っ-○○○：2009/12/29(火) 18:09:36

ごめん寝ぼけてたEMC

759 ：デフォルトの名無しさん：2009/12/29(火) 18:13:49

この前の「はじめてのCUDAプログラミング」も糞本を通り越して
よくこれで出版したなという出来だったし、競争の無い分野の
和書入門書はほんと酷いもんだ。

760 ：,,・´∀｀・,,）っ-○○○：2009/12/29(火) 18:15:42

http://www.internetnews.com/infra/article.php/3846461/Intel+EMC+Team+on+More+Efficient+Cloud+Storage.htm
これでいいかな？

ゲルたんは良い椅子貰ったな

761 ：,,・´∀｀・,,）っ-○○○：2009/12/29(火) 18:24:28

ゲルたんと同時期に退職したBruce Sewellも9月15日付けでApple法務顧問。
パートナー企業との根回しのために幹部移籍させるなんてよくあることじゃん。
なんでもかんでも懲戒処分にしちゃうのは浅はかなんじゃない？

土居ちゃんなんてまだ就職先決まってないんだし。

762 ：デフォルトの名無しさん：2009/12/29(火) 18:31:20

円満退社じゃない＝懲戒
とは誰も言ってないけどね

Gelsingerに関してはIntel側の状況証拠が悪すぎるでしょ
IDFのスピーチしかりLarrabeeしかり
しかもGelsingerはIntelに30年間勤めた生粋のたたき上げ
そのIntelのCEOを狙える座にもあったんだからなおさらです

まあEMCへの移籍はGelsingerにとってはキャリアアップには繋がるだろうけど
引き抜きって言われるのもその辺が所以だろう

763 ：,,・´∀｀・,,）っ-○○○：2009/12/29(火) 18:39:36

まあ根回しの状況証拠もあるわけだし
Larrabeeは天野さんも言ってるが長期的な計画だし

764 ：デフォルトの名無しさん：2009/12/29(火) 18:49:20

NVIDIA、「Fermi」の第1弾製品の開発を中止

NVIDIAは米国時間の2009年12月28日、「Fermi」の開発コード名で呼ばれていた、外付けグラフィックス製品の開発中止を明らかにした。
当初は2009年末から2010年にかけて出荷する予定だった。
プロジェクト自体は継続する。外付けグラフィックスチップに関する新たな計画は2010年に改めて公開する。

765 ：デフォルトの名無しさん：2009/12/29(火) 19:28:36

>>762
IntelのCEO狙えるって言っても次の次のくらいの話でしかも本命馬じゃなかったからな

766 ：デフォルトの名無しさん：2009/12/29(火) 19:37:42

土井氏ってIntelの人間でしょ
情報筒抜けになったのバレたから
この解雇劇でしょ

767 ：デフォルトの名無しさん：2009/12/29(火) 19:43:57

なんでAMD厨って>>766みたいな電波ばっかしなの？

768 ：デフォルトの名無しさん：2009/12/29(火) 19:49:03

>>759
ああ、あれはひどかったな。

769 ：デフォルトの名無しさん：2009/12/29(火) 20:38:21

外資ではよくあること、らしいが･･･

770 ：デフォルトの名無しさん：2009/12/29(火) 21:48:10

>>768
そうか？
入門書だぞ？

771 ：デフォルトの名無しさん：2009/12/29(火) 22:46:21

入門者や初心者を容赦無く苛め抜くのが日本のプログラマーの特徴ですから

772 ：デフォルトの名無しさん：2009/12/30(水) 00:26:04

>>770
本当に読んだ？あれ、初心者に紹介する気になる？
あのタイトルであの内容は絶対にあり得ん。
少なくとも英語圏では編集者があのまんま出版させることはしないよ。
書籍としての構成になって全くなっておらず、blogに書き散らしたのを
そのまま印刷したような作りだ、あれじゃ。

773 ：デフォルトの名無しさん：2009/12/30(水) 04:50:32

同業者向けの入門でしょ。なのであれで十分だな。
英語圏ではってのが視野が狭いというか短絡的だけど、
ただお前が分からなかった、ってだけの事だな。

774 ：デフォルトの名無しさん：2009/12/30(水) 09:21:37

世の中にはびっくりするぐらい技術レベルの低い人間が
びっくりするぐらい低コストで劣悪な入門書を書く事がある
そういうのは大概すぐ消えるが、よくわかっていない初心者が
間違えて買ってしまうだけでも元が取れたりする
>>759 もそういう類の本。まともな人間なら一笑に付す内容
同じ枚数の便所紙の方がまだ役に立つ

775 ：デフォルトの名無しさん：2009/12/30(水) 10:41:31

やべ、買っちゃった

776 ：デフォルトの名無しさん：2009/12/30(水) 12:48:01

>>774
どうせ
技術(プログラミング)は自信あるが、数学がわからないとかじゃないの？
後半の例がわからなかったんだろ

777 ：デフォルトの名無しさん：2009/12/30(水) 13:20:27

>>776
後半の数式と説明に矛盾あるし
余計混乱させるだけの糞本じゃねーかw

778 ：デフォルトの名無しさん：2009/12/30(水) 14:07:14

著者乙って言えばいいのかこれは

779 ：デフォルトの名無しさん：2009/12/30(水) 15:36:08

別に悪い本とは思わないけど、若干まとまりがなかったのも事実だな
まあ簡単な初歩＋TSUBAMEでやってる計算の紹介と思えば悪くない

780 ：,,・´∀｀・,,）っ-○○○ 【だん吉】：2010/01/01(金) 13:27:05

　　　　　今年のGPGPU市場↑

781 ：デフォルトの名無しさん：2010/01/01(金) 16:23:55

だんごのだん吉吹いた

782 ：【小吉】【699円】：2010/01/01(金) 17:09:28

test

783 ：デフォルトの名無しさん：2010/01/02(土) 16:57:56

団子は的には興味ないの？

784 ：,,・´∀｀・,,）っ-○○○：2010/01/03(日) 16:29:58

林檎飴とかおみくじとか売る商売のこと？
無いよ。

785 ：デフォルトの名無しさん：2010/01/03(日) 21:37:55

団子てめぇ俺がマジレスするのを待ってやがるな

786 ：,,・´∀｀・,,）っ-○○○：2010/01/06(水) 02:30:13

なんだ他に言いたいことがあるなら言って良いぜ？

787 ：デフォルトの名無しさん：2010/01/06(水) 07:30:27

今年こそは童貞卒業したいです！

788 ：,,・´∀｀・,,）っ-○○○：2010/01/06(水) 23:35:03

俺ですら腐女子だけど相方がいるのにおまいらときたら

789 ：デフォルトの名無しさん：2010/01/07(木) 00:19:31

それって肉風船？それともメガネブス？

790 ：デフォルトの名無しさん：2010/01/07(木) 00:21:44

自慢してるの？死ぬの？

791 ：デフォルトの名無しさん：2010/01/08(金) 21:53:50

>788
gpgpuで腐女子人格を再現したの？

792 ：,,・´∀｀・,,）っ-○○○：2010/01/10(日) 23:56:34

再現するもなにも俺は元々女の腐ったような精根だが？

793 ：デフォルトの名無しさん：2010/01/11(月) 02:30:35

とーみーこー

794 ：デフォルトの名無しさん：2010/01/11(月) 10:10:48

腐女子に失礼だろ！

795 ：デフォルトの名無しさん：2010/01/11(月) 11:05:36

GPUボードの箱に描かれてる女のことを言ってるんだよ

796 ： ◆0uxK91AxII ：2010/01/11(月) 16:49:04

>>788 は、一人称が『俺』な腐女子らしい。

797 ：デフォルトの名無しさん：2010/01/11(月) 16:52:26

チームはこれまで右サイド、左サイド、トップ下、ボランチと茸がやりたいというポジションをすべてやらせた
それでもまったく機能しないどころかチームの大きな足枷となった
後半残り時間わずかで1点ビハインドという局面でものんきにバックパスし、サポからも大きなブーイングを得る
昇格自体が奇跡といわれ最下位でダントツの降格候補であるシュレス戦というボーナスゲームにも先発させているが
いつものようにピッチ上で迷子になり無得点に貢献しただけだった

そんな中村俊輔のせいでチームは勝てなくなり最悪の状態になってしまった
さすがに中村俊タケに見切りをつけ、茸抜きで戦うことを決めて2戦目、アルメリア戦では
3部から上がってきた若手を初先発させてみたらなんとこれが大成功！！
これが同じチームか？と思うほどまともなサッカーをして快勝！！
初先発の若手は先制点を挙げ、2点目にも大きく貢献
こうして完全にピッチ上での居場所を失った中村口ダケｗｗｗｗｗ
2010年初戦のバレンシア戦に後半途中から出場させるも見方ゴール前のデンジャラスバックパス、
さらには2人に挟まれた見方へのアンビリバボーバックパスで相手サポを笑わせた
しっかりと疫病神振りをも遺憾なく発揮してチームの敗戦に貢献
茸抜きのサラゴサ戦は2得点をあげてしっかりと勝利ｗｗｗｗ

チームを弱体化させてしまうキングクズ、それがキノコ村ｗｗｗｗｗ

フルベンチ　　　　　　　 4勝1分1敗
1分でも出場すると　　　1勝3分7敗
↑の内スタメンの試合　0勝3分3敗 ←この全試合で、チームは1度も得点できないｗｗｗ

茸抜きだとEL出場言争いをしていたであろうし、茸をフルに出せば降格してしまうだろう
1人でこれだけチームを変えられる、凄まじい影響力こんな凄い選手はめったにいないぜ
サッカー界の疫病神ｗｗｗｗｗ

バレンシア戦クソ村クソ輔の全ボールタッチ集
チームの足かせだと一目瞭然ｗ
ttp://www.youtube.com/watch?v=10WGZRngL4w

798 ：,,・´∀｀・,,）っ-○○○：2010/01/11(月) 17:16:57

>>795
ジャックフロストたん？

799 ：デフォルトの名無しさん：2010/01/11(月) 21:46:19

クソッ、ダメだ。人生の勝ち組に何を言っても負け犬の遠吠えにしかならねぇ。

800 ：デフォルトの名無しさん：2010/01/12(火) 11:54:14

>>793
おっさん、ワカメは好きか？

801 ：デフォルトの名無しさん：2010/01/14(木) 22:54:44

Jan 6, 2010
Tom Forsyth / Intel Corporation
The Challenge of Larabee as a GPU
http://stanford-online.stanford.edu/courses/ee380/100106-ee380-300.asx

802 ：デフォルトの名無しさん：2010/01/14(木) 23:05:50

AGE

803 ：デフォルトの名無しさん：2010/01/14(木) 23:16:25

チョー氏ロートなんだけど、linuxとかで一般的なpthreadsをGPGPUで
（しかもハードの最適な性能で）動かすっていうのは簡単にできる
もんなのでしょうか？
つまり、そういうランタイムを簡単に作れるかっていうことです。
漏れの周囲に出来ると主張する香具師がいるんだが、どうも
胡散臭くてそんなもん出来やしないというのを証明したいんです。
もし出来ないのであれば、出来ない理由も御教示くだされれば
すごく感謝します。

804 ：デフォルトの名無しさん：2010/01/15(金) 00:05:18

>>803
GPGPUの並列化とpthreadsの並列化は別次元の話だぞ

GPGPUを利用した数値計算ライブラリはAMDなんかは提供してる(nVidiaは
興味ないから知らん)ので、利用は比較的簡単に出来るぞ。

ただ、その使い方を含めた最適化は個々の能力によりけりだとは思うが。

805 ：デフォルトの名無しさん：2010/01/15(金) 02:16:30

そいつに実証させればいいじゃん

806 ：デフォルトの名無しさん：2010/01/15(金) 20:57:25

> そういうランタイム
ってのがよくわからないな。

807 ：デフォルトの名無しさん：2010/01/16(土) 12:14:46

>>803
何かすでに研究とかあるかもしれないけどとりあえず考えてみた。

CUDAあたりの感じで考えると、GPU上で動かすプログラムは、
その規模がでかくなればなるほどレジスタ数やら共有メモリ領域やらの
制限で、並列度が下がっていく。だから、スレッド関数としてでかい関数を
指定するとまるで効率が上がらない。

スレッドがしばらく動き続けるみたいなものには根本的に適していない。
異なる複数の関数を同時に動かすのも基本的に対応していない。
細切れにしてそれぞれ別ものとして起動してやる必要がある。

pthreadsのような感じで扱えるものをもし作るとすれば、
おそらくまずCPU側にVMのようなものを作って、スレッド関数を
まず時間があまりかからない単位で細切れにして、それぞれGPU関数として独立させる。
独立させた関数を、処理の順序にしたがってCPUからそれぞれ起動してやる。
コンテキスト情報は、GPU関数内でデバイスメモリに保存して一旦終了する。次回起動した関数で
コンテキスト情報を読み取ってから処理を進める。

そうなると、バイトコードVMのような感じなら、GPUでバイトコード処理関数を書いてやれば、
普通に想像できるものにはなる。
ある程度のバイトコードのくくりでJITでGPUネイティブまでコンパイルして動かせば、その部分に
関してはフルスピードが出せる。（複数スレッドについて同時のタイミングで起動できないとうまみがないが）

そんな感じになるのではないか？

808 ：デフォルトの名無しさん：2010/01/16(土) 13:05:36

pthreadとかはたかだか数スレッド並列で動かす程度の問題でしか使われていないから、
移植しても、GPUの恩恵は受けられないと思うよ。
むしろ、OpenMPのコードを自動的にGPUコードに変換してくれたらありがたい。

809 ：デフォルトの名無しさん：2010/01/17(日) 11:22:10

>そういうランタイム

LAPACKのライブラリがCUDA化されている
http://www.culatools.com/
こういったものを簡単に作れるか、しかも最適化も含めて、みたいなことを聞いているのかなあ

>漏れの周囲に出来ると主張する香具師がいるんだが、

このくだりは胡散臭さを感じるなw
本当はおまいが知りたいだけだろw

810 ：デフォルトの名無しさん：2010/01/17(日) 12:07:02

CUDA等のGPU実行環境に、pthreadを移植出来るのか？
って聞いているんじゃないの？
素直に受け取れば、そうなるだろう。
で、そんなの知らねーし、どーでもいいよカス、が答えだな。

811 ：デフォルトの名無しさん：2010/01/18(月) 23:57:38

GF100とFermiのWhitepaperが上がってるけどどんなもんかね？
http://www.nvidia.com/object/gf100.html

812 ：デフォルトの名無しさん：2010/01/19(火) 07:49:13

>>811
ゆめりあのスコア100万越える性能だってよ
絶対買った方がいいぞ

813 ：デフォルトの名無しさん：2010/01/19(火) 14:13:46

ゆめりあ（笑）

814 ：デフォルトの名無しさん：2010/01/19(火) 20:10:00

http://twitpic.com/yrug1
パソコン工房2FにHPC/GPUコンピューティングのカンファレンスルームができるとのこと

815 ：デフォルトの名無しさん：2010/01/29(金) 16:03:36

理研とNVIDIA、HPC用途でのGPUアクセラレートの討論会を開催
～NVIDIA CEOがGPUコンピューティングの可能性をアピール
http://pc.watch.impress.co.jp/docs/news/20100129_345703.html

816 ：デフォルトの名無しさん：2010/02/05(金) 19:52:25

Fermiが一月遅れるという噂

817 ：デフォルトの名無しさん：2010/02/05(金) 19:57:03

で？

818 ：デフォルトの名無しさん：2010/02/05(金) 21:30:02

情弱のおまえらにわざわざ教えてやったんだから
喜べよ

819 ：デフォルトの名無しさん：2010/02/06(土) 20:20:47

で？

820 ：デフォルトの名無しさん：2010/02/06(土) 21:28:34

fermiが遅れたところでAMDが選択肢に入るわけでもない

821 ：デフォルトの名無しさん：2010/02/06(土) 22:15:22

S3一筋と言うわけだな！

822 ：デフォルトの名無しさん：2010/02/06(土) 23:54:54

Fermiが出ても選択肢にならない人もいる

823 ：デフォルトの名無しさん：2010/02/07(日) 09:30:31

Fermiいつでるのかっこわらい

824 ：デフォルトの名無しさん：2010/02/20(土) 11:39:41

Fermiは良くてQ2
悪いとQ2の出荷が１万個弱で、一般人が手に入れられるのは
来年以降の可能性

825 ：デフォルトの名無しさん：2010/02/23(火) 19:58:32

http://www.sabrepc.com/p-174-xfx-geforce-gtx-480-2gb-gddr5-pci-express-x16-retail.aspx
http://www.sabrepc.com/p-175-xfx-geforce-gtx-470-1gb-gddr5-pci-express-x16-retail.aspx

結構安いな

826 ：デフォルトの名無しさん：2010/02/24(水) 01:42:38

ほれ、

http://www.velocitymicro.com/item.php?sr=0&iid=4302

結構高いな。

827 ：デフォルトの名無しさん：2010/02/26(金) 10:00:24

おもちゃ屋にサンドとザブングルのポップがあった

828 ：デフォルトの名無しさん：2010/03/03(水) 00:16:25

フィックスターズ、Yellow Dog Enterprise Linux for CUDAを提供
～初期状態でNVIDIA CUDAをサポート
http://pc.watch.impress.co.jp/docs/news/20100303_352216.html

829 ：デフォルトの名無しさん：2010/03/03(水) 01:19:04

今日からGeforce 260 > Radeon 5850になりました。
ここテストに出るよ

830 ：デフォルトの名無しさん：2010/03/08(月) 14:55:50

アスキーのGPGPUセミナーってどうかな？

ttp://ascii.jp/elem/000/000/493/493336/

フィックスターズがやっているプログラミングセミナーの
tiny版みたいな感じなんだろうか。
あっちは受けてみたいけれど、高いからなー
アスキーのは1万ちょっとで講師は同じみたいだから、
お試しにいいかと思ってるんだけど
申し込みした人いる？

831 ：デフォルトの名無しさん：2010/03/11(木) 06:35:09

そのGTX260は燃え尽きました。

832 ：デフォルトの名無しさん：2010/03/11(木) 07:38:41

Fermiは皆の絶望を抱えて
爆発しました。ありがとう

833 ：デフォルトの名無しさん：2010/03/20(土) 17:32:44

CUDA 3.0 Downloads
http://developer.nvidia.com/object/cuda_3_0_downloads.html

834 ：デフォルトの名無しさん：2010/03/24(水) 22:49:37

東工大、気象庁の次世代気象モデルのフルGPU化に成功
http://pc.watch.impress.co.jp/docs/news/20100324_356466.html

835 ：デフォルトの名無しさん：2010/03/28(日) 16:04:11

Fermiきたこれ

836 ：デフォルトの名無しさん：2010/03/29(月) 15:22:49

GTX480･･･爆熱でかなり電気喰うけどこの手の用途だと相当速そうだな。

837 ：デフォルトの名無しさん：2010/03/29(月) 18:34:55

この手の用途以外（グラフィックとか）だと無用のゴミだけどな

838 ：デフォルトの名無しさん：2010/03/29(月) 20:23:48

ttp://www.guru3d.com/article/geforce-gtx-470-480-review/29

うんそうだね
もうテクスチャ張っただけのノッペリとか見飽きた

839 ：デフォルトの名無しさん：2010/03/29(月) 20:52:18

>>838
なんか大した事無い映像だね。

840 ：デフォルトの名無しさん：2010/03/29(月) 21:44:10

dirt2やheavenよりはましだけどね

841 ：デフォルトの名無しさん：2010/03/29(月) 22:42:04

相変わらず嘘クセー絵だなあ

842 ：デフォルトの名無しさん：2010/03/29(月) 22:57:09

このスレ的にはグラフィック用途での性能なんてどうでも良いんじゃないの?

843 ：デフォルトの名無しさん：2010/03/29(月) 23:23:54

リアルな絵を出したいんならパストレーシングでも使わないと無理でしょ。
GTX480使ってもまだまだ辛いけど。

844 ：デフォルトの名無しさん：2010/03/29(月) 23:47:54

レイトレーシングって分岐多くてGPUにはあんまり向いてないんじゃなかったっけ？

845 ：デフォルトの名無しさん：2010/03/29(月) 23:54:36

レイトレは技術者のオナニーとしては出るかもしれんけど
リアルタイムグラには採用されないんじゃないの？
同じ演算リソースを使う限り、従来のシェーディングだったら
10倍ぐらい使えるんだろ？

846 ：デフォルトの名無しさん：2010/03/30(火) 00:10:59

ゆきちははヨーヨーとか似合いそうですよね

847 ：デフォルトの名無しさん：2010/03/30(火) 00:16:10

あ、ごめん誤爆

848 ：デフォルトの名無しさん：2010/03/30(火) 05:22:40

ほい、レイトレ
ttp://www.nvidia.com/object/cool_stuff.html#/demos/2116

849 ：デフォルトの名無しさん：2010/03/30(火) 20:26:25

>従来のシェーディングだったら

結局それって見た目変わんないんだろ

850 ：デフォルトの名無しさん：2010/03/30(火) 23:57:12

ここは、漢らしくラジオシティで行こうぜ！

851 ：デフォルトの名無しさん：2010/03/31(水) 02:11:42

男が脱いでいくベンチマークソフトあったでしょ
あれなんて言ったっけ？

852 ：デフォルトの名無しさん：2010/03/31(水) 09:44:27

abe.exe

853 ：デフォルトの名無しさん：2010/05/03(月) 10:24:28

GTX470 or 480の評価はどんなもんやねん

854 ：デフォルトの名無しさん：2010/05/03(月) 10:35:18

お前が買って試せばいいねん

855 ：デフォルトの名無しさん：2010/05/04(火) 21:58:22

数が少ないっちゅー噂やし
しゃあないかー

856 ：デフォルトの名無しさん：2010/05/05(水) 01:03:49

“Llano” を見据えたATi Stream SDK 2.1
ttp://northwood.blog60.fc2.com/blog-entry-3803.html

857 ：デフォルトの名無しさん：2010/05/05(水) 15:05:41

岡ちゃんの本ってどうなんですか？

858 ：デフォルトの名無しさん：2010/05/07(金) 07:56:39

青木本で十分

青木本が難しいと感じる人は買ってみたらいいと思うよ

859 ：デフォルトの名無しさん：2010/05/22(土) 18:40:05

http://en.inpai.com.cn/doc/enshowcont.asp?id=7670&pageid=7112
GPU OpenCL performance preview

860 ：デフォルトの名無しさん：2010/05/22(土) 21:21:19

ttp://en.inpai.com.cn/doc/enshowcont.asp?id=7670&pageid=7112

GTX480大勝利！！！…・というほどには圧倒的というわけでもない
アレだけリッチに倍精度積んでせいぜい5870の2倍って逆にしょぼくね？

　　　　　　,,,
(　ﾟдﾟ)つ┃

861 ：デフォルトの名無しさん：2010/05/22(土) 21:36:30

geforceは制限されてて5870の2倍も出るのか

862 ：デフォルトの名無しさん：2010/05/22(土) 21:38:23

1.5倍以下のトランジスタ数で2倍以上も出てりゃ優秀だろ

863 ：デフォルトの名無しさん：2010/05/22(土) 21:41:34

十分すぎるな。

864 ：デフォルトの名無しさん：2010/05/22(土) 21:50:38

てことはteslaは更に4倍近く速いのか・・

865 ：デフォルトの名無しさん：2010/05/23(日) 12:05:09

スレというか板違いな>>860のぬか喜びっぷりが寒いな

866 ：デフォルトの名無しさん：2010/05/28(金) 18:51:14

http://www.theinquirer.net/inquirer/news/1650867/hpc-vendors-ready-dump-nvidia
HPC vendors are ready to dump Nvidia
[Exclusive] Time to look at alternatives
By Lawrence Latif
Thu May 27 2010, 08:59

HPCの雄SGIがTesla以外のGPGPUを探す - 冷却費用がかかり過ぎ
| SGI's senior director of server product marketing,
| Bill Mannel told The INQUIRER that he believes that
| Nvidia's rival chip design outfit AMD is "catching up
| very quickly" with its ATI brand of graphics chips.
| ATI's high end GPGPU cards are only barely nosed out
| by Nvidia's Fermi based Tesla boards in some
| applications. Mannel said he expects there to be
| "even performance capability" between AMD/ATI and
| Nvidia within the next 18 months.
AMDは急速に追い付きつつあり、FermiベースのTeslaとは鼻の差だ。
18か月の内に性能でも追い付くだろう。

----
Teslaの熱処理には相当に手を焼いている模様。
エアコンよりも計算機に金をかけたいんだぜ、という主張が
感じられます。

867 ：デフォルトの名無しさん：2010/05/28(金) 21:42:42

で？

868 ：デフォルトの名無しさん：2010/05/28(金) 21:52:03

>>866
nVidiaは18ヶ月で２倍速のペースで動いているのに１８ヶ月で追いつく言われても・・・

869 ：デフォルトの名無しさん：2010/05/29(土) 01:41:45

2倍速で発熱増か流石だな

870 ：デフォルトの名無しさん：2010/05/29(土) 01:59:54

>>868
消費電力あたりの性能ではAMDの圧勝ですが

871 ：,,・´∀｀・,,）っ-○○○：2010/05/29(土) 03:05:15

メモリ帯域も頭打ちかけてるのに消費電力もダイサイズも増加させながらの倍々ゲームがいつまでも続くわけがないよ。

872 ：デフォルトの名無しさん：2010/05/29(土) 03:59:12

ここで帯域問題を解決すべく箱○的にeDRAMをキャッシュとしてオンパッケージ化してだな（問題外

873 ：デフォルトの名無しさん：2010/05/29(土) 04:05:18

アヤパン

874 ：デフォルトの名無しさん：2010/05/29(土) 11:19:57

http://www.4gamer.net/games/110/G011065/20100526093/
AMDは汎用化に向けてできることから徐々に改良
NVは一気にのぼりつめようとして徐々に衰退

875 ：デフォルトの名無しさん：2010/05/29(土) 20:13:46

衰退ねぇ
ttp://www.gsic.titech.ac.jp/node/313
東工大の次期スパコン構築 NEC・HP 連合が受注

約 2900 ソケットの最新の Intel Westmere EP + Intel Nehalem EX に内包された約 1 万7 千個の x64 CPU コアによる「スカラ演算」と、
約 4200 枚の最新型 Fermi コアを採用する NVIDIA Tesla GPGPU に内包された約 188 万個の演算コア(CUDA Core)による「ベクトル演算」が組み合わさった
「ベクトル・スカラ混合型アーキテクチャ」による世界トップクラスの 2.4 ペタフロップスの高演算性能、および毎秒 0.7 ペタバイトの高メモリバンド幅

876 ：デフォルトの名無しさん：2010/05/29(土) 21:06:45

暖房機4200台も納入とか、こりゃフアンは東工大に足を向けて寝られないな。

877 ：デフォルトの名無しさん：2010/05/29(土) 22:16:27

東工大も引くに引けないだろうな
NVIDIAのシャチョさんのメンツってものもあるし

878 ：デフォルトの名無しさん：2010/05/29(土) 22:19:00

GPUのコード書けない人は大変だな

879 ：デフォルトの名無しさん：2010/05/29(土) 22:20:53

GPU？なにそれうまいの？

880 ：デフォルトの名無しさん：2010/05/29(土) 22:26:29

Cよりちょっとハードルは高いけど、CUDAも書けないやつはプログラマーはやめたほうがいい。
並列アルゴリズムにはまだ未開拓の分野がある。

881 ：デフォルトの名無しさん：2010/05/29(土) 22:32:32

そうはいっても、スパコン使う人には素人プログラマー
みたいな人もいるわけで

882 ：デフォルトの名無しさん：2010/05/29(土) 22:39:46

インテラとかアムダはいつだすん？この手のアクセラレーター

883 ：デフォルトの名無しさん：2010/05/29(土) 22:55:42

2012以降

884 ：,,・´∀｀・,,）っ-○○○：2010/05/29(土) 23:06:00

CPUに内蔵されてるSIMDユニットを拡張していった方が

額面はともかく実効値はじきにCUDAハードウェアに追いつく

885 ：デフォルトの名無しさん：2010/05/29(土) 23:13:56

>>882
AMDはもう出してるじゃん

886 ：デフォルトの名無しさん：2010/05/29(土) 23:22:29

結局汎用性持たせるほど効率悪くなるだけだからな。
電力あたりの性能や、トランジスタあたりの性能でいうと
DGEMM用途なら、実はRadeon5870でも汎用性は過剰すぎ

疎行列用途ならGPGPUは意味が無い。
演算器なんぞ積まずに帯域だけ広げた方がいい。

887 ：,,・´∀｀・,,）っ-○○○：2010/05/29(土) 23:44:52

Radeon用のGRAPE-GPUのコードって既にあったっけ

888 ：デフォルトの名無しさん：2010/05/30(日) 00:20:59

GRAPEは知らないがGRAPE関係者の
会津大の先生がブルートフォースの
N-Bodyでほぼ理論値出してたような。
Oct-treeでも良い線行っている様な論文出てなかったっけ？

889 ：,,・´∀｀・,,）っ-○○○：2010/05/30(日) 01:09:55

内積命令もあるしそれなりに良い数字出そうだね

890 ：デフォルトの名無しさん：2010/05/30(日) 01:13:32

AMDの計算専用の奴って結構旧型じゃね？
メモリも少ないし。おまけにOpenCLのサポートがβだし。
もうちょい本気出して、nVidiaのTESLAボッタ（Quadraよりはマシか）商法を揺さぶって欲しい。

891 ：,,・´∀｀・,,）っ-○○○：2010/05/30(日) 02:31:26

FermiはECCサポートしてるのが地味に大きい

892 ：デフォルトの名無しさん：2010/05/31(月) 03:43:28

団子よララビーがお蔵入りになったら、今度はSIMD擁護でつか？
ほんと、懲りないやっちゃなー

893 ：,,・´∀｀・,,）っ-○○○：2010/05/31(月) 04:27:26

勝手にお蔵入りにするな

894 ：デフォルトの名無しさん：2010/05/31(月) 14:24:42

今度はも何もだいぶ前から団子はSIMD厨だったしLNI命令もSIMDじゃないのか…？

895 ：,,・´∀｀・,,）っ-○○○：2010/05/31(月) 15:30:58

GPGPUもSIMDだ

896 ：デフォルトの名無しさん：2010/05/31(月) 20:03:56

団子はAMD関連は徹底してるっぽ
SDK2.1は中身すら見ず無視
最新のRADEONとかも買わないようにしてる

897 ：,,・´∀｀・,,）っ-○○○：2010/05/31(月) 20:24:05

どのみちアーキテクチャも命令セットも変わるのに過渡期のもの使っても意味ねーじゃん

898 ：デフォルトの名無しさん：2010/05/31(月) 21:02:42

団子は今後も触れることはしないと思うな
だって団子はAMDのことをry

899 ：,,・´∀｀・,,）っ-○○○：2010/05/31(月) 21:28:51

Mach64からのATIユーザーですが何か？
プログラマブルデバイスとして好かんと言ってるだけだ

900 ：,,・´∀｀・,,）っ-○○○：2010/05/31(月) 21:45:24

ついでに言うとAMDのAVX互換化＆XOP/FMA4命令セットは結構買ってるんだけどな

仕様読みながらBulldozer向けのコードは既に書いてるよ

901 ：デフォルトの名無しさん：2010/05/31(月) 22:12:43

>>896
SDK2.1のopenclはmingw gccでコンパイルできないバグがあるし。
まあ、ヘッダファイルをちょこちょこイジれば治るけど。
HD4850はβ対応だと言え、グループに64スレッド以上入れたらバグるとか（文書に明示してあるが、opencl関数でクエリしたら256まで使えると返ってくるのに）、
ローカル(cudaで言うところのshared）メモリが使えないだとか、
ゲフォやCPUエミュなら問題なく動くものが謎のバグで誤動作するとか
まあ、とにかくマトモに作り直して出直してこいという感じ。

902 ：デフォルトの名無しさん：2010/05/31(月) 22:34:39

betaだもの
　　　　　　　　　AMD

903 ：デフォルトの名無しさん：2010/05/31(月) 22:36:20

バグだらけを使うのも、それはそれで楽しいもんだろ
仕事じゃなけりゃな

904 ：デフォルトの名無しさん：2010/05/31(月) 22:45:07

>>903
mingwのインストールミスってんじゃねーかとか、自分のclプログラムがバグってんじゃねーかとかくだらない時間を消費しまくったけどな。
自分の書いたもののバグ取りならともかく、提供物がバグってるのはマジ勘弁。

905 ：デフォルトの名無しさん：2010/05/31(月) 22:57:59

というか、mingwってそもそも現時点でSDKの公式
サポート対象のコンパイラじゃないだろう。
calもmingwで使うためには、自前でインポートライブラリ作って
ヘッダも書き換えなきゃ実行ファイル作れないのに。
mingwでやるなとはいわんが、人柱的な
気構えで行くべきじゃね。

906 ：デフォルトの名無しさん：2010/05/31(月) 23:11:30

>>905
Programming Gudeを見るべし。
cygwin, mingw gccを使えばgdbでカーネルのデバッグが出来ると書いてある。
できると言い切っているからには、当然試しているはずなのにコンパイルすら通らない。

907 ：デフォルトの名無しさん：2010/05/31(月) 23:43:12

cl_int4などのベクトル型の各要素にアクセスする例がprogramming guideなどにあるが、
a.x, a.yなどの構造体のx, y, z, w要素にアクセスする用になっている。
union {
cl_int s[4];
struct {cl_int x,y,z,w;};
};
などと定義されているのだが、visual C++を使うとアライメントの都合か、共用体中の構造体がコンパイルされないようになっていて、
a.s[0]などとしないとベクトル型の中身にアクセスできない（作例の通りではコンパイルが通らない）。
これでvisual C++が公式コンパイラと言われてもなぁ。

まあ、これはOpen CLのリファレンスにベクトル型の要素へのアクセス方法が記述されていないから規格の時点でアヤシイ部分だけど。

908 ：,,・´∀｀・,,）っ-○○○：2010/05/31(月) 23:50:57

β以前の問題だな。NVIDIAのOpenCL SDKは【一応】ある程度使い物になるぞ

909 ：デフォルトの名無しさん：2010/05/31(月) 23:57:47

>>906
いや、よく読んでみれば分かるが
debugにGDBを使えとは書いてあるが
gccを使えとは書いていない。

Visual Studioでコンパイルしたバイナリを
cygwinのgdbでデバッグすると
kernelコードだけデバッグできる。

ランタイムが裏でgccライクなコンパイラ(llvm?)を
呼び出してカーネルをCPUコードにしているから
その部分だけGDBから見えるというだけ。

実際デバッグの例で挙げられている
BitonicSortをそこで書いてある手順どおりに
デバッグしようとすると、BitonicSortというソースを
読もうとするから、そこだけln -s BitonicSort_Kernel.cl BitonicSort
とでもしておけば、デバッグできる。

910 ：デフォルトの名無しさん：2010/06/01(火) 00:14:10

max work group sizeが256と返ってくるのに64までしか使っちゃダメ（どこに書いてあるのかすら忘れたくらいわからないところに書いてある）とか、
ゲフォやCPUエミュで動くのにデバイスで動かないとかはvcでもgccでも御同様なわけだけどな。

911 ：デフォルトの名無しさん：2010/06/01(火) 04:42:06

alphaだもの

　　　　　　　　　　アムド

912 ：デフォルトの名無しさん：2010/06/01(火) 10:17:50

>>907
そんなコードは cl 関係なくずっと昔から使ってる。
無名 union のせいじゃないかと思うが、VC++ のバージョンを書くのと、
最小限の再現コードを codepad に貼ってみ。

913 ：デフォルトの名無しさん：2010/06/01(火) 10:55:30

>>912
なんや、おまえはAMDのOpenCl使ったことないのにエラソーこいてるのか。
cl_platform.hを見ればわかること。
そもそも提供されている型のアクセスの話なんだから、俺のコードじゃなくて、
提供コードの方の話だと常識的にわかるだろ。

914 ：デフォルトの名無しさん：2010/06/01(火) 16:17:57

>>913
912の要求が満たされたら試していいと思ってることは伝わらなかったんだな。
http://www.khronos.org/registry/cl/api/1.0/cl_platform.h
のことでいいのか？
じゃ、今度はお前がVCのバージョンを書け。
ついでに、問題の箇所を行番号で指摘してもいいぞ。

ブラウザで検索してみたところでは、ANSI 非互換を許せば大丈夫に見える。
俺に見落としがあるか、サンプルやお前のコードが悪いのではないかと疑う。

915 ：デフォルトの名無しさん：2010/06/01(火) 17:17:15

>>914
指摘もなにもwwww
なにが問題を起こしているのかわかっているからヘッダファイルをわざわざ指定したんじゃないかw
ヘッダファイルの中を掘り起こさないとコンパイルが通らない原因が分からないようなものを
使えます、みたいな顔をしてリリースすんなってことだよ。

バグがヘッダファイルだけなら良いけどな。
この状態じゃdllの中身もしれとるよ。

916 ：デフォルトの名無しさん：2010/06/01(火) 18:51:27

>>914じゃないけど、StreamSDKは昔は2005専用で2.x以降は現行のCUDAと同じく2008専用だけどそこは本当に間違えてないんだよな？

917 ：デフォルトの名無しさん：2010/06/01(火) 21:15:46

>>916
その程度の知識で何を語っているのやら・・・

918 ：デフォルトの名無しさん：2010/06/01(火) 21:18:24

RV7xx系(FireStream含む）に対してOpenCLがβ対応な時点でなにやってんだかって感じだが。
まずはFireStreamでキッチリ動かすのがアレを売った責任というものだろうに。

919 ：デフォルトの名無しさん：2010/06/01(火) 21:27:43

>>917
お前が情報出さなさすぎだから>>916みたいな初歩的なツッコミが来るんだろうがｗ

920 ：デフォルトの名無しさん：2010/06/01(火) 21:46:43

>>919
openclを明らかにわかっていない発言なんだが>>916は

921 ：デフォルトの名無しさん：2010/06/01(火) 21:57:49

お前がVC++コンパイラでの話をしてるんだからVC++のバージョンの話をしてる>>916は大いに関係あるだろ

922 ：デフォルトの名無しさん：2010/06/01(火) 22:01:07

くだらねぇことで盛り上がってるな。

923 ：デフォルトの名無しさん：2010/06/01(火) 22:13:27

>>921
cl_platform.hを見てもそんなこという程度なら入ってくるなよ。

924 ：デフォルトの名無しさん：2010/06/01(火) 22:57:14

OpenCLの策定時期と、GPU開発にかかる時間を考えると
AMDのGPUがOpneCLにまともに対応できるのは、
次の次くらいの世代のGPUでしょ

925 ：デフォルトの名無しさん：2010/06/01(火) 23:00:33

その頃には別の対応に追われる

926 ：デフォルトの名無しさん：2010/06/01(火) 23:01:55

へぇ、どういう対応なんでしょ

927 ：デフォルトの名無しさん：2010/06/01(火) 23:05:14

スレが盛り上がっているのでcl_platform.hを確認しました。

union {
cl_int s[4];
#if defined( __GNUC__) && ! defined( __STRICT_ANSI__ )
struct {cl_int x,y,z,w;};
#endif
};

上記のように書けば何がどうなっているのか一発で伝わるのに
>>907は重要なマクロ行を省略してスレを読むだけでは分からないようにし、
Visual C++ではANSI非互換オプションを指定すればすむ話なのに
作例の通りではコンパイルが通らないと嘘を書いています。

928 ：デフォルトの名無しさん：2010/06/01(火) 23:36:13

VC++でも__GNU_C__が定義されてるのか？

929 ：デフォルトの名無しさん：2010/06/01(火) 23:51:27

>>927
あほか。
ヘッダファイルを探らないといけない時点で終わってるって言ってるんだよ。

930 ：デフォルトの名無しさん：2010/06/01(火) 23:56:58

ヘッダを見なきゃいけない時点で～って理屈が
通るかどうかは微妙なところだなぁｗ
昔の人やUNIXでコンパイルからが普通の人には
受け入れられないだろうし

931 ：デフォルトの名無しさん：2010/06/01(火) 23:57:34

そもそも、RV7xx系でclGetDeviceInfoでmaxworkgroupsizeが256と返ってくるのに、
64以上は使わない方がいいとかこっそり書いているようなものはどうなんだ、ってことにはスルーしやがるしな。
しかも、このワークグループサイズはプログラムによって64以上で動いたり動かなかったりする非常にタチの悪い挙動を示すんだぜ。
使った事ないくせに何必死にAMD擁護してんだかわかんねーよ。

932 ：デフォルトの名無しさん：2010/06/01(火) 23:58:52

>>930
それはないわ。
ヘッダを見て非公開な内部構造を触るってことは将来の互換性を失うことになるからな。
あくまでリファレンスに公開されている情報以上を使わないのがいいに決まってるだろ。

933 ：デフォルトの名無しさん：2010/06/02(水) 01:00:16

>>931
そのバグ自体は次の版で直る予定だが、そもそもベータ版なのに何言ってるの？

934 ：デフォルトの名無しさん：2010/06/02(水) 01:09:21

擁護とかなんで信者バトルみたいなどうでも良い展開に持ち込もうとするんだ？
別に今時点でのATI Stream SDKのOpenCLの出来が悪い事自体は
否定はしていないだろう。誰もフォローが入らないのは、正しい事を言っているから。
激しく突っ込みが入っているのは、どちらかと言うと使用者側の勘違いとか
そういう可能性のある内容だからだろう。

突っ込み側の書き込みについても、詳細を聞くのは問題を特定して
適切な対策を示したいからで、問題解決して開発を進めたい人間にとっては
プラスになるような内容だろ。

935 ：914：2010/06/02(水) 12:30:24

不具合があるというなら追試してやろうという俺が何で噛み付かれてるのか分からん。
と思ったら、文句の対象は Khronos じゃなくて ATI で、しかも単に文書の不備だったのか。

正直確かにひどいｗ
defined(__GNUC__) が無い限り無名 struct の方にはアクセスできないしｗ

だがやはり、今見ても 907 の文章は混乱している。
907 だと Khronos が叱られているように見えるし、VC をあのコードで境界が狂うような
劣等コンパイラと思っているように見える。

936 ：デフォルトの名無しさん：2010/06/02(水) 22:18:23

正直、Khronosは酷いっす。
cl.hppはnamespaceの使い方がムチャクチャだし。

937 ：デフォルトの名無しさん：2010/07/06(火) 12:35:24

AMD CALについて語ってください

938 ：デフォルトの名無しさん：2010/07/13(火) 19:42:00

>>937
なにそれマイナー杉

939 ：デフォルトの名無しさん：2010/08/09(月) 23:57:19

win7, NVIDIAのグラボ（GeForce9500って書いてある）でVC9.0のプログラムからGPGPUなリソースを利用したいのですが、なんて調べたらいいんでしょうか？
「VisualC++ OpenCL」でぐぐったらAMDのATI STREAMによるOpenCLの実装が出てきましたが、AMDの製品を利用していないので関係ありませんよね。

940 ：デフォルトの名無しさん：2010/08/10(火) 00:01:48

バカかおまえ

941 ：デフォルトの名無しさん：2010/08/10(火) 00:10:22

自己解決。NVIDIAのOpenCL見つけました。どうもありがとう。

942 ：デフォルトの名無しさん：2010/08/10(火) 00:28:23

それで解決したならいいんじゃね？ｗ

943 ：デフォルトの名無しさん：2010/08/10(火) 00:29:11

すみません嘘付きました。

944 ：デフォルトの名無しさん：2010/08/12(木) 14:41:49

なんか来てた
ttp://developer.amd.com/gpu/ATIStreamSDK/Pages/default.aspx
ATI Stream Software Development Kit (SDK) v2.2
With OpenCL^(TM) 1.1 Support

945 ：デフォルトの名無しさん：2010/08/12(木) 14:48:11

nVもAMDもとりあえず1.1に対応したか

…S3用のOpenCLってどこ？

946 ：デフォルトの名無しさん：2010/08/12(木) 14:58:11

NDeveloperから登録完了メール来ないからOpenCL落とせないお（｡ﾟ´ω｀ﾟ｡）ﾋﾟｰ

947 ：デフォルトの名無しさん：2010/08/12(木) 15:04:18

>>946
OpenCLの普及を阻害する牛歩戦術か…

948 ：デフォルトの名無しさん：2010/08/12(木) 18:07:24

>…S3用のOpenCLってどこ？

アナウンスはしていても
実際に何のソフトもない出てないものに
躍起になると思うのか？

949 ：デフォルトの名無しさん：2010/08/13(金) 22:15:38

だれもS3でやろうとは思わないからな
現状NかAの二択

950 ：デフォルトの名無しさん：2010/08/14(土) 07:43:26

だがハード的に一番汎用に向いてるのはChromeなんだがね

951 ：デフォルトの名無しさん：2010/08/14(土) 13:11:27

nvidiaの目指す汎用性って
cのプログラムがなるべく変更無く動くかどうかで
もともとのGPGPUの目指していたはずの方向とは違うような。
NVの目指す未来の究極はマルチコアCPUでしかない。

952 ：デフォルトの名無しさん：2010/08/14(土) 13:27:28

向いててもさ
4コアCPUにピーク性能でもメモリ帯域でも劣ってるGPGPUとか一体どこに魅力を見出せばいいのかね？

953 ：デフォルトの名無しさん：2010/08/15(日) 01:56:52

GPGPUの載っているハード限定なんだからChromeはない。

954 ：デフォルトの名無しさん：2010/08/15(日) 07:54:31

CPUに劣るってのはAMD

逆にS3はあれでCPU並なのはすごい

955 ：デフォルトの名無しさん：2010/08/15(日) 09:13:39

製品はすごいらしい(信者曰く)
けど積極的に使おうとは思わないのが現実

956 ：デフォルトの名無しさん：2010/08/15(日) 12:11:36

一番カスなのはAMDで間違いないけどな

957 ：デフォルトの名無しさん：2010/08/15(日) 12:23:24

＞GPGPUの載っているハード

これってどういうこと？

958 ：デフォルトの名無しさん：2010/08/15(日) 12:53:49

>>954
演算能力
Phenom II X4 965
54.4GFlops
Chrome 540 GTX
35.2GFlops

メモリ帯域
Phenom II X4 965
21.3GB/s
Chrome 540 GTX
13.6GB/s

×　CPU並
○　CPU以下

※ i7持ってきたら差は更に開く

959 ：デフォルトの名無しさん：2010/08/15(日) 14:44:05

理論値持ってきてる時点で頭悪い

960 ：デフォルトの名無しさん：2010/08/15(日) 14:44:58

＞GPGPUの載っているハード

ねぇこれってどういうこと？

961 ：デフォルトの名無しさん：2010/08/15(日) 14:48:28

積極的に使いたいけどハードがうんこなので
一向に普及しないOpenCL

962 ：デフォルトの名無しさん：2010/08/15(日) 14:54:00

OpenCLはEPから実用になるみたい

963 ：デフォルトの名無しさん：2010/08/15(日) 16:49:49

>>959
GPUは理論性能と実効性能が剥離するのが通例
いかにChromeであろうと同じだしこれだけ理論性能で
CPUに差を付けられたら普通勝ち目は無い

まぁバカに言っても無駄だろうから死ぬまでChrome持ち上げてるといいよ

964 ：デフォルトの名無しさん：2010/08/15(日) 18:38:04

そうだね,そのchromeに負けちゃうradeonって
どうやって持ち上げればいいんだろうね

965 ：デフォルトの名無しさん：2010/08/15(日) 18:41:59

OpenCLが普及しないのはAMDのせい？appleのせい？

966 ：デフォルトの名無しさん：2010/08/15(日) 18:44:43

CPUにさえ勝てないChromeってGPGPUの価値の何たるかさえ実感できないよね

967 ：デフォルトの名無しさん：2010/08/15(日) 18:46:28

GPGPUの価値ってなに？
Havok clothでcpuより遅いって公言すること？

968 ：デフォルトの名無しさん：2010/08/15(日) 18:49:12

Open Physicsって、まだ実用化されないの？

969 ：デフォルトの名無しさん：2010/08/15(日) 18:52:56

AVXの登場によってGPGPUなんて何の価値もなくなるよ

970 ：デフォルトの名無しさん：2010/08/15(日) 18:53:35

PhysXGPUはx87+シングルスレッドじゃないとPhysXCPUと勝負にならないよ

とバラされる事じゃないかな

971 ：デフォルトの名無しさん：2010/08/15(日) 18:54:31

　演算能力
Radeon HD5870（単精度）
　2.72 TFLOPS
Radeon HD5870（倍精度）
　544 GFLOPS

GeForce GTX 480（単精度）
　1.68 TFLOPS
GeForce GTX 480（倍精度）
　672 GFLOPS

　メモリ帯域
Radeon HD5870
　153.6 GB/sec
GeForce GTX 480
　177.4 GB/sec

972 ：デフォルトの名無しさん：2010/08/15(日) 19:27:45

で、実パフォーマンスでGeforceに負けてるRadeonって・・

973 ：デフォルトの名無しさん：2010/08/15(日) 19:47:48

GeforceってGPGPUではRadeonを無双できるんじゃなかったっけ？
http://www.computemark.com/

できてないっぽいけどどうしちゃったの？

974 ：デフォルトの名無しさん：2010/08/15(日) 20:00:04

ComputeMark(笑)

975 ：デフォルトの名無しさん：2010/08/15(日) 20:05:37

結局ベンチ回すしか使い道がないんだな

976 ：デフォルトの名無しさん：2010/08/15(日) 20:15:47

勝てないアプリ見つけたら語尾に（笑）を付けるだけの簡単なバイトです

977 ：デフォルトの名無しさん：2010/08/15(日) 20:18:50

そうだね、そのベンチが信頼できるなら
東工大もradeon使ったろうね

978 ：デフォルトの名無しさん：2010/08/15(日) 20:20:53

今日はこのスレにしては珍しく、キチガイが暴れてるね。

979 ：デフォルトの名無しさん：2010/08/15(日) 20:22:03

そういえばLinpackも実効率低かったなぁ
Nebulaeのおかげで天河笑えなくなっちゃったね
結局GPUなんてHPC用途で期待されてるのはメモリ帯域だけだったわけだ

980 ：デフォルトの名無しさん：2010/08/15(日) 20:28:00

東工大はずっとTeslaでやってきたから蓄積を重視しただけ
逆に多体のように向いてる用途ならRadeon使ってるところもある
ただそれだけの話

981 ：デフォルトの名無しさん：2010/08/15(日) 20:28:56

そのメモリ帯域もすでに頭打ちだからな

982 ：デフォルトの名無しさん：2010/08/15(日) 20:31:51

まぁ、ECC無の時点でお笑いなんですが

983 ：デフォルトの名無しさん：2010/08/15(日) 20:33:58

何でもいいからRadeon用のGPGPU商用実用ソフトってないの？

984 ：デフォルトの名無しさん：2010/08/15(日) 20:34:37

自作板では「Geforce ゲーム糞遅せえ。使えねえ」と煽っておいて
こっちじゃありがたくGeforceを使う。

これがこの板の流儀だが、なにやら勘違いしたお子様が混じっているようだ。

985 ：デフォルトの名無しさん：2010/08/15(日) 20:35:18

所謂GPGPU向けのアプリケーションなら
今のラデのアーキテクチャ位が
一番トランジスタ効率・電力ともに優れている。

汎用向けに振るのは、なるべく効率を落とさないで
汎用性を上げる努力だけど、究極の目標となる
汎用性が現状のCPUなら、バランス的に
現状のCPUを超えるのは不可能なんだよ。

だから汎用といいつつ、ターゲットを絞って
特定分野向けのコードならこれに置き換えれば
これだけ速くなりますと言う風に進むのが正しい形

986 ：デフォルトの名無しさん：2010/08/15(日) 20:37:58

なら、がんばってソフト出してよ

987 ：デフォルトの名無しさん：2010/08/15(日) 20:46:02

GPUなんておとなしくテクスチャ張に専念してればいいんだよ
しゃれたShaderなんて使おうとしてもどうせ遅いんだから

988 ：デフォルトの名無しさん：2010/08/15(日) 20:46:36

Chrome厨君に4コアCPUに勝てないよねと現実を叩き込んであげただけなのに

気分を害したなら謝るけど途中から話を逸らしまくって
Geforceの話し出したのは俺じゃないし非難される謂れは無いよ

989 ：デフォルトの名無しさん：2010/08/15(日) 21:02:34

>4コアCPUに勝てないよね

radeonのhavok clothのことね

990 ：デフォルトの名無しさん：2010/08/15(日) 21:05:32

chromeの場合4coreに勝てなくても問題無いだろ
どうせ組み合わせはnanoとチップセットのVN1000(Chrome520)しかないんだから

そもそもOpenCLがもっと広まらなきゃ
対応する意味も無いわけだがね

991 ：デフォルトの名無しさん：2010/08/15(日) 21:18:30

>>989
PhysX87: Software Deficiency
http://www.realworldtech.com/page.cfm?ArticleID=RWT070510142143

下手すりゃCPUでやらせた方が速そうなのにGPUにさせる意義ってあるの？
GPU上で物理演算を実行してもらわないと困る人？

NVIDIAの中の人ならそら困るのかもね

992 ：デフォルトの名無しさん：2010/08/15(日) 21:32:03

つーか、そもそもCPUでやってもリアルタイムで
どうにかなる程度の軽い演算を、わざわざCPUから遠い
GPUでやるのは意味が無い。

実用するにはCPUの10倍程度の速度アップが
必要なくらい重い演算を持ってくると意味が出てくる。

993 ：デフォルトの名無しさん：2010/08/15(日) 21:41:51

なまじCPUもGPUも持ってると、どちらでやった方がいいか突き詰めてからでないと商売できないのはつらいね

994 ：デフォルトの名無しさん：2010/08/15(日) 21:42:32

だからテクスチャだけ張ってろよ

995 ：デフォルトの名無しさん：2010/08/15(日) 21:46:33

もともとのPPUの中の人も
GPUに物理処理は向かないって言ってたもんね

996 ：デフォルトの名無しさん：2010/08/15(日) 21:49:41

次スレ立ててきたぞ
落ちてからでも良かったかもしれないが

GPGPU#5
http://hibari.2ch.net/test/read.cgi/tech/1281876470/l50

997 ：デフォルトの名無しさん：2010/08/15(日) 21:50:29

＞下手すりゃCPUでやらせた方が速そうなのにGPUにさせる意義ってあるの？

radeonでデモする意味あったの？