トップページ⇒tech
1001コメント282KB

GPGPU#4

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん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/
0002デフォルトの名無しさん2009/10/11(日) 19:17:59
ダンゴのために立ててやったぞ
謝罪しろ
0003デフォルトの名無しさん2009/10/11(日) 19:22:45
確かに、ダンゴの謝罪がないと始まらないな
さっさと謝罪しろよ
0004デフォルトの名無しさん2009/10/11(日) 19:58:32
ダンゴが何を書くかではなく、何を書かないかで判断するとGPGPUの経験がないだろｗ
0005デフォルトの名無しさん2009/10/11(日) 20:08:42
専門職に汎用的な仕事を教えてる間に
一般職が専門知識を身につけ始めたでござる
0006デフォルトの名無しさん2009/10/11(日) 20:20:28
結局、Fermi vs Larrabeeとかの前に、GPGPUをなんに役立てるかがわからないと
いうのが前スレからの流れだけど、だれかGPGPUはこれからものすごい必要になると
主張できる人はいないの？

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

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

でも今のGPGPUの流行が、そういうアプリの登場まで続いているという自身はないけど。
0007デフォルトの名無しさん2009/10/11(日) 20:26:46
「超並列処理」って計算量に関するアルゴリズム本の内容が
変わるくらいの変化ってこと？
0008デフォルトの名無しさん2009/10/11(日) 20:38:17
>>7
今以上のすっごい量の並列の処理っていうつもりでいったんだけどさ。
並列の構造がさらに入れ子状になっているようなイメージで。
0009デフォルトの名無しさん2009/10/11(日) 20:42:12
例えばホログラム
何もない空間に立体的に写し出すSF映画でよくみるアレ
0010デフォルトの名無しさん2009/10/11(日) 20:46:16
それは普通に本来の用途じゃね
0011デフォルトの名無しさん2009/10/11(日) 20:49:42
Cell REGZAやPS3次期ファームの新機能の一つに通常動画の立体化があるから
そういう方面をPCで実現するのにGPGPUは向いてる

今のGPGPUは開発環境が右往左往してるから
やりたい事があっても商品化にはあと数年掛かる
0012デフォルトの名無しさん2009/10/11(日) 20:58:12
こんな用途とか

CUDAでウイルス検索が高速化する
http://northwood.blog60.fc2.com/blog-entry-3190.html
0013デフォルトの名無しさん2009/10/11(日) 21:06:43
Nvidiaの方向性見るに、やっぱりGPGPUは本質ではないんじゃないか。
結局目指してるのはメニーコアでの並列処理であって、
グラフィックに特化したものを流用することをGPGPUと呼んでるだけで。
LarrabeeもFermiもスタート地点が違うだけで目指してるものは同じだし。
0014デフォルトの名無しさん2009/10/11(日) 21:13:16
>>9
AMDのGPU部門トップ，Rick Bergman氏が語る「1～10年後のグラフィックステクノロジー」
http://www.4gamer.net/games/045/G004578/20081001053/

だからこれなんだろ
0015デフォルトの名無しさん2009/10/11(日) 21:27:52
グラフィックスがもっとも近くて、ありえるターゲットだってのはそうだろう。
誰でもまあそうじゃんって感じだよね。ホログラム、レイトレ、3Dテレビとかへの
転用ね。結構、それだけでも儲かるかな?IntelとかNvidiaが今無駄に投資している
様に見えるGPGPU研究費用って、結構その方面で回収できるかな？一般に普及するなら
結構儲かるような気もする。そういう算段をつけてて、やつらは今投資しているんだろうか。
0016,,・´∀｀・,,）っ-○○○2009/10/11(日) 23:28:11
SSE4.2の文字列検索アクセラレーション、あと次のAESアクセラレーションは
対応すればほぼ全てのサーバアプリケーションが恩恵を受ける技術な。

http://www.nvidia.co.jp/object/io_1249982404004.html
ちなみに前スレの6万（笑）はここがソース
0017デフォルトの名無しさん2009/10/11(日) 23:29:57
文字が扱えるようになるなら
爆発的に価値がでるけど

SSE4.2を超える問題領域を扱えないなら
いらんな
0018デフォルトの名無しさん2009/10/11(日) 23:36:28
gnu grepが対応する見込みは？
0019デフォルトの名無しさん2009/10/11(日) 23:43:22
>>16-17
自作自演？
0020,,・´∀｀・,,）っ-○○○2009/10/11(日) 23:45:14
いいのかGREP程度で。


つーか、線形ファイル検索って基本的にストレージネックで拡張命令で云々やっても大して効果ないような。
ストリームに対して複数文字列パターンを同時探索するようなケースが有効。
ウィルス探索もそうだけど、データベースとかがそう
0021,,・´∀｀・,,）っ-○○○2009/10/11(日) 23:54:20
NVIDIAアーキじゃ小回りが利かなくて無駄が生じるようなことを
力任せで何とかなると思って本気で取り組んできたらそれはそれでヤバい構図だぞ
0022デフォルトの名無しさん2009/10/12(月) 01:31:23
文字は、ふつーに使えるだろう。
しかし、そんな大量の文字列を扱うアプリってある？
パターンマッチつっても、
そのために、メインメモリ - GPUメモリ間の転送が無駄すぎる。。
0023,,・´∀｀・,,）っ-○○○2009/10/12(月) 01:39:51
Perlのようなもの
0024デフォルトの名無しさん2009/10/12(月) 04:00:06
昔はメモリだって1GBも何に使うんだ？とか、CPUだって動画見ないから1.3GHzもいらないと思ってたし、同じノリでGPGPUも何かに使えるんじゃないの。
何に使えるかは分からんが。
0025デフォルトの名無しさん2009/10/12(月) 06:25:41
そういや、nvの開発環境って
何の成果がなくても、そのまま貸しといてもらえるもんなの？
0026,,・´∀｀・,,）っ-○○○2009/10/12(月) 10:45:23
返却しろよ
0027 ◆0uxK91AxII 2009/10/12(月) 12:27:09
物凄く重い暗号化/復号をGPUで行い、
何かのP2Pなモノでソレを使うとかすれば、
強引に需要を作り出せるかも。
0028デフォルトの名無しさん2009/10/12(月) 12:50:31
そんな需要があるのは割れ厨だけだろ
0029デフォルトの名無しさん2009/10/12(月) 12:52:27
文字列まともに解析できるなら
Winnyなんかのパケットをフィルタするソフトを
GPGPUで作れるから有望なんだけどなぁ

スイッチとかでハード対応するとすぐ1台50万とかになるけど
やっすいPCにGPU挿しておくだけでいいならすごい価値あるんだよなぁ
0030デフォルトの名無しさん2009/10/12(月) 13:55:26
今の環境ってもうかなり成熟してきているよね。メモリが1Gを超えるのが当たり前になってからメモリを必要とすることが少なくなってきたし、HDDも動画集めしない限り、1Tもいらないじゃない。CPUもATOMなんてモノが売れているし。
明かに次代は今までと違う方を向いている様だし、GPUのマーケットは縮小して行くよね？今のままだとIntelだけ残るのかな？
0031デフォルトの名無しさん2009/10/12(月) 14:47:30
>>29
現時点で、現実的に見ると、やはりサーバーへの利用がありえそうなんだね。
処理するデータ量が大きいからやっぱり向いているのか。

その場合って、PCI-EXPRESSがボトルネックにならないだろうか？大丈夫？
0032,,・´∀｀・,,）っ-○○○2009/10/12(月) 15:20:55
>>27
暗号化ってブロック間の依存関係があるからGPGPUは根本的に向かんよ
CPU（のショートSIMD）でやるのが正解。

ECBモード限定か、クラックならまた別だが。
0033デフォルトの名無しさん2009/10/12(月) 17:45:39
物理演算などは並列性が高い処理が多い
科学分野では相当重宝する技術だが一般向けの普及は難しい気がする

もっとも、アルゴリズムそのものを書き換えて、処理を分岐から並列にシフトできるというなら話は別だが
0034デフォルトの名無しさん2009/10/12(月) 17:51:30
えーと、皆さん。
もう少し分かり易く話していただけません？
0035デフォルトの名無しさん2009/10/12(月) 17:55:12
既存の言語にあわせてGPGPU言語を設計すべきなのか
GPGPUに合わせた言語を設計すべきなのか答えって出たんだっけ？
0036デフォルトの名無しさん2009/10/12(月) 17:58:38
>>35
段階を踏まないと厳しいかもしれないね
最初に既存の言語に最適化されたものを作ってから、次にGPGPUに最適化されたものを作っていくしかないと思う
0037デフォルトの名無しさん2009/10/12(月) 18:02:07
GPGPUでのHello Worldは何に該当するの？
0038デフォルトの名無しさん2009/10/12(月) 18:16:44
>>37
CUDA SDKだと一番簡単なのはscalarProdかな
0039デフォルトの名無しさん2009/10/12(月) 18:26:36
scalarProdも2重のループとreductionを使っているから読みにくいね。
SDKにすんなり読めるのはないな。じっくり解読しないといけない。
0040,,・´∀｀・,,）っ-○○○2009/10/12(月) 21:16:17
Fermiのメモリ帯域って256GB/sだろ。
GDDR5のメモリ帯域あたり消費電力って1GB/sあたり0.5Wだから
つまるところメモリ転送だけで最大128W食うわけで・・・

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

レンダリング方式が変わって既存のコードの性能が出なくなることを恐れてるんだろ。
だとすれば結局今までのコード資産に縛られてるのはGPUも同じというわけだ。
GPUの限界を感じた。
0041デフォルトの名無しさん2009/10/12(月) 21:34:38
Radeonじゃ再起関数作るためのレジスタ
機能作れないしGeforceが唯一絶対だろうな
0042,,・´∀｀・,,）っ-○○○2009/10/12(月) 21:37:45
どっちつかずのGeForceだけが唯一絶対死亡な気がする。
どのみちTDPの半分をメモリ帯域で使っちゃうようなマヌケ設計に未来はない。
0043デフォルトの名無しさん2009/10/12(月) 21:51:50
♪CUDAは5年後過ぎにMUDAへと変わるだろう
0044デフォルトの名無しさん2009/10/12(月) 22:14:27
みんなDX11CSに最適化してる最中だな
0045デフォルトの名無しさん2009/10/13(火) 11:38:40
ttp://www.brightsideofnews.com/news/2009/10/12/an-inconvenient-truth-intel-larrabee-story-revealed.aspx?pageid=4
0046,,・´∀｀・,,）っ-○○○2009/10/14(水) 00:26:30
なかなか面白い考察だと思う
ただ、データ帯域を比較するのに全コアL1の帯域を単純合計して云々とかいう
計算法は俺的に好かん。

FLOPSあたりの帯域で見た方が割と面白い事実が見えてくると思う。
たとえば、
Fermiって実はSPあたりのロード・ストア帯域がGT200の半分になってるじゃん糞杉
とかさ
0047デフォルトの名無しさん2009/10/14(水) 00:41:40
はじめてこのスレきたんだが、団子って何者なの？
0048,,・´∀｀・,,）っ-○○○2009/10/14(水) 00:44:38
けだ者だよ
0049デフォルトの名無しさん2009/10/14(水) 00:49:26
他にも、うつけ者とかバカ者とか色々だよね
0050デフォルトの名無しさん2009/10/14(水) 01:00:12
>>48
あんたレス早いよｗ
･･･人のこと言えないか。
0051デフォルトの名無しさん2009/10/14(水) 04:33:07
Industry's first OpenCL GPU and CPU SDK out NOW
ttp://developer.amd.com/GP...
0052デフォルトの名無しさん2009/10/14(水) 04:34:16
ttp://developer.amd.com/GPU/ATISTREAMSDKBETAPROGRAM/Pages/default.aspx
0053デフォルトの名無しさん2009/10/14(水) 04:55:08
まだ諦めてなかったのか
0054デフォルトの名無しさん2009/10/14(水) 06:58:48
Fermiのロード・ストアユニットの詳細ってでてたっけ？
あれってtexture unitじゃないのか？
0055デフォルトの名無しさん2009/10/14(水) 07:35:04
AMDのOpenCL使ってみたけど
やっぱり雪豹より8万分の1の性能しかでない

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

眠い寝るぉ
0056デフォルトの名無しさん2009/10/14(水) 07:55:41
>>55
どんなソース書いたのか見せて。
0057デフォルトの名無しさん2009/10/14(水) 09:52:17
なんで同世代のカードを複数買ったんだ？馬鹿なのか？
0058デフォルトの名無しさん2009/10/14(水) 11:19:00
友達に協力して貰ったのかもしれないじゃないか
買ったと断定するのは早い
0059デフォルトの名無しさん2009/10/14(水) 11:19:09
NVIDIAはハードウェアのペーパーローンチ、
AMDはソフトウェアのペーパーローンチか。
0060デフォルトの名無しさん2009/10/14(水) 11:23:50
なんで3870～5870の速さが全部同じの8万分の1になってるんだ？阿呆なのか？
0061デフォルトの名無しさん2009/10/14(水) 12:22:09
そもそもGPUで処理してないから
0062デフォルトの名無しさん2009/10/14(水) 15:47:03
8万の時点で、性能の差じゃないことぐらいわかるだろ
0063デフォルトの名無しさん2009/10/14(水) 16:22:24
性能の差っていうか
作り手がただへぼいだけに
0064デフォルトの名無しさん2009/10/14(水) 17:09:27
>>59
ペーパーロンチ以前にβ版がもう2年続いてますから
0065デフォルトの名無しさん2009/10/14(水) 18:09:43
そもそも3870は対象外じゃないの？
0066デフォルトの名無しさん2009/10/14(水) 18:35:41
>>65
3870も4870も5870もR600ベースのアーキテクチャだから、
処理速度には大きな違いがあるけど命令の互換性には問題無い
3870コアのFireStream9170がGPU初のFP64対応だし
0067デフォルトの名無しさん2009/10/14(水) 18:44:56
>>66
いや、SDKの動作環境見てみれ
0068デフォルトの名無しさん2009/10/14(水) 19:08:50
AMDのOpenCLが遅いのはATi Streamを使わせようって魂胆だろう。
でもそれならみんなNvidiaにいく。
0069デフォルトの名無しさん2009/10/14(水) 21:16:52
Radeon4850買ってきました。
今からubuntu9.04でOpenCLしてみます
0070デフォルトの名無しさん2009/10/14(水) 21:22:59
>>66
670と770には互換性ないぞ。
TｰUnitで実行できる命令が一部削除されてる。
0071デフォルトの名無しさん2009/10/14(水) 22:39:33
v2.0-beta4じゃまだ
OpenCLだとGPU無効になるなぁ
やっぱり2011年度まで待たないと無理だね
0072デフォルトの名無しさん2009/10/14(水) 23:04:35
>>71
ん、SDKのページにあるOpenCL専用ドライバ入れた？
普通のCatalystじゃ動かないよ？
0073デフォルトの名無しさん2009/10/14(水) 23:22:34
>>69
LinuxでRadeon(fglrx)なんてXの起動すらできるか怪しいんだが…
0074デフォルトの名無しさん2009/10/14(水) 23:23:57
>>72
入れてみましたがどこで確認すればいいのですか？
sampleのx86のNBody実行してもCPUしか使わないですよ
0075デフォルトの名無しさん2009/10/14(水) 23:51:51
>>73
何年前の話をしてるんだ？
0076デフォルトの名無しさん2009/10/14(水) 23:56:59
>>75
実際Windows以外じゃ動かないよ
0077デフォルトの名無しさん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も使えるようにしておきたく。

どなたかご存知でしたら教えてください
0078,,・´∀｀・,,）っ-○○○2009/10/15(木) 00:28:05
なんでわざわざ対応してるかどうかもわからない8200MG搭載機をピンポイントで選びたがるんだ
0079デフォルトの名無しさん2009/10/15(木) 00:28:50
>>76
なにが動かないの？
0080デフォルトの名無しさん2009/10/15(木) 00:43:38
ドライバ入れて
AMD Testing use onlyって表示されるようになったけど
N体ちっとも早くないぞ

8万とかにしたらすぐマシン落ちる
0081デフォルトの名無しさん2009/10/15(木) 01:03:39
XP用ドライバのzip壊れてるな・・・
0082デフォルトの名無しさん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
0083,,・´∀｀・,,）っ-○○○2009/10/15(木) 02:41:07
>>54
http://www.4gamer.net/games/099/G009929/20090930012/

0084デフォルトの名無しさん2009/10/15(木) 07:06:43
>>75
phoronix見てこい
いまだに動かないだのOpenGLの動作がおかしいて阿鼻叫喚の図が見られる
0085デフォルトの名無しさん2009/10/15(木) 07:31:46
結論AMDのOpenCL実装はCPUよりも遅い
0086デフォルトの名無しさん2009/10/15(木) 14:08:12
>>84
forumは久々に見たがドライバそのもののトラブルは随分と減ってるじゃないか。
どこが阿鼻叫喚なんだよ。
0087デフォルトの名無しさん2009/10/15(木) 22:57:06
GT300はスクラッチパッドメモリが切り札になりそう
0088,,・´∀｀・,,）っ-○○○2009/10/15(木) 22:59:28
ならねーよ。

SP個数当たりに直してみろ、GT200のそれと何も変わってない。
ロードストアユニットが等速32Wayじゃないから実質スクラッチパッドの性能は退化。
0089デフォルトの名無しさん2009/10/16(金) 00:15:46
GT300の開発者向けサンプル
来月末に送付確定したね
0090,,・´∀｀・,,）っ-○○○2009/10/16(金) 00:35:27
遅っ
0091デフォルトの名無しさん2009/10/16(金) 00:52:07
だんごよララビー信者のお前にそれを言える資格はないと思うがw
0092デフォルトの名無しさん2009/10/16(金) 00:53:06
>>84
ubuntuとかFedoraだけど、現行モデルは動かんよ。
大昔のやつは動くけど、現行の一番古くてショボい(安い)
HD4350刺したら、アナログ接続では使えたが今時の
解像度のモニタに繋ぐと画質の劣化が激しくて、デジタル
(DVI, HDMI)接続だと真っ暗で映らなかった。

とっくに絶版の、まだHDが付かなかった頃のでないとマトモ
に使えない。ATi死ね。
0093デフォルトの名無しさん2009/10/16(金) 00:54:06
ララ兵衛って、www
痛ニウムの二の舞だろ。
0094デフォルトの名無しさん2009/10/16(金) 00:55:50
>>91
LRBより遅いんだがｗｗｗ
0095,,・´∀｀・,,）っ-○○○2009/10/16(金) 01:00:19
いまんとこLarrabeeのスペックは去年公開された通りだしな
どっかのFermiはスループット下方修正しまくりんぐ

0096,,・´∀｀・,,）っ-○○○2009/10/16(金) 01:03:03
>>91
Radeonうめぇｗｗｗｗ


ぶっちゃけGPUとしてはATIで十分だと思うよ。
割り切りが出来ないNVIDIAはただただシェアを失うのみですな
0097デフォルトの名無しさん2009/10/16(金) 01:12:53
AMDのOpenCL実装CPUより遅いのだが
これ意味あるのか？
0098,,・´∀｀・,,）っ-○○○2009/10/16(金) 01:15:32
ないよ。

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

NVIDIAにぴったりな格言があるよ
二兎を追う者は一兎をも得ず
0099デフォルトの名無しさん2009/10/16(金) 01:31:02
しかし2羽の鳥を石ころ一つで落とすことはできるんだなこれが
0100デフォルトの名無しさん2009/10/16(金) 01:34:26
速いだろ。nbodyでn増やせばそれなりに。
それでも会津大のcalで書いた奴よりは大分遅いけど。
0101,,・´∀｀・,,）っ-○○○2009/10/16(金) 01:40:18
ATIの2倍のダイサイズ使って中途半端なもの作るくらいなら
GPUとCPU作ったらどうですか
0102デフォルトの名無しさん2009/10/16(金) 09:05:48
マジキチ
0103デフォルトの名無しさん2009/10/16(金) 09:45:36
>>99
ClarksdaleのGMCH統合でコストダウンとパワードメイン集中管理による電力制御合理化、
さらにはNVIDIA排除ですねわかります
0104デフォルトの名無しさん2009/10/16(金) 09:58:28
将来の統合CPUでのLRBniサポートは既定路線だから
どのみちx86ベースのCPU必要なんだけどね

それともTegraでx86市場破壊の夢でも見るか？
0105デフォルトの名無しさん2009/10/16(金) 15:04:29
ttp://pc.watch.impress.co.jp/docs/news/20091016_322120.html
> 開発コードネーム“Larrabee”(ララビー)で開発を進めているディスクリートGPUについて触れ
> 日本時間の17日に、Larrabeeの性能データを初めて公開することを明らかにした。

CUDA終了のお知らせ？
0106デフォルトの名無しさん2009/10/16(金) 17:40:33
Larrabeeってx86つうところが何とも・・
せめてIA64ベースならまだ許せるんだけど
まぁただの実験でしょ、商売にはならんわな
0107デフォルトの名無しさん2009/10/16(金) 17:56:50
いや、IA64ベースだったら総スカンだろ。
0108デフォルトの名無しさん2009/10/16(金) 18:19:22
IA64とかIntelですら見捨ててるのにｗ
0109デフォルトの名無しさん2009/10/16(金) 18:50:14
さっさとリリースしないと会社が傾く様な状況でもないのに、なんで今なのかね。
Fermiが出てきてからだと霞んでしまうので、
今のうちに旧世代のフラッグシップ(シングルだが)をタコ殴りにして印象付けたかったとか？
0110デフォルトの名無しさん2009/10/16(金) 19:00:05
>>109
B0ステップが出来上がったんでこけら落としだろ。
FermiのスペックはGTX280の2倍にも届いてないのは明らかなんだから
暗黙にFermiに対するプレッシャーになるぞ
0111デフォルトの名無しさん2009/10/16(金) 19:17:52
>>108
x86のおかげでどれだけ生産性が阻害されているのか理解できないの？
旧資産ばかりにたよってちゃだんごみたいな馬鹿になるだけだよ
IA64はコンシューマで流行らなかっただけでなかなかよくできたアーキテクチャだろ
0112デフォルトの名無しさん2009/10/16(金) 19:22:15
理解できてないんだろうから説明してやれば？
0113デフォルトの名無しさん2009/10/16(金) 19:23:13
x86のオーバーヘッドなんて
トランジスタ数の少ない昔と違って
誤差にしかならないだろ。

今時のCPUのトランジスタなんて
マルチコアでも殆どキャッシュが占めている。
0114デフォルトの名無しさん2009/10/16(金) 19:38:03
x86のオーバーヘッドなんて未だに言ってるバカいるんだな
ハイパフォーマンス用途だとアドレッシングモードによる演算密度の高さなど
メリットのほうが大きいんだが。
0115デフォルトの名無しさん2009/10/16(金) 20:02:21
Itanium（笑）

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

そんなのがなんで出てくるのか理解できない。
0116デフォルトの名無しさん2009/10/16(金) 20:16:23
16バイトも固定で使ってRISC相当命令最大3つなのと、
最大11バイト程度使ってAGU, LSU, VPERM, VPUに
一気にオペレーションを供給できるのと、
どっちが命令セットの効率で優れてるかは明らかでしょう
0117デフォルトの名無しさん2009/10/16(金) 22:27:01
>>116
うまく供給できればな。

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

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

ああAVXとか言ってないでなんちゃらモードとか作って
x86の命令フォーマットを作り直してくれないかなあ。
どうせロングモードでIA-32バイナリは動かないんだから
Intelも抜本的に変えるつもりだったんだろうけどなあ。
0118デフォルトの名無しさん2009/10/16(金) 22:44:33
>>111
その勢いでIntel説得してくれｗ
Poulson早く出せってなｗｗｗｗ
0119デフォルトの名無しさん2009/10/16(金) 22:48:50
>>117
普通に1サイクルでスルーする。

ちなみにお前の理想の命令セットは何よ？
過去のしがらみがない新規の命令セットとか言って鳴り物入りで
登場したCell（笑）とか言いだすなよ
0120デフォルトの名無しさん2009/10/16(金) 22:50:24
> どうせロングモードでIA-32バイナリは動かないんだから

は？
Long modeは64bitネイティブモードとCompatibility(32bit互換)モードの総称だが？
勉強して出直してこい
0121,,・´∀｀・,,）っ-○○○2009/10/17(土) 00:42:17
Intelが出してるPentiumマイクロアーキテクチャの資料見てて素晴らしいと思ったのは俺だけじゃないはず
0122デフォルトの名無しさん2009/10/17(土) 00:51:25
Larrabeeは2010年のQ4に１00TFlopsの性能だろ
一人勝ちだよな
0123,,・´∀｀・,,）っ-○○○2009/10/17(土) 00:55:48
x86のパフォーマンス上の障害ってのは浮動小数がスタックベースなのと
レジスタが少ないのと、あと演算が2オペランドだろ

SIMDレジスタ32本＋マスク8本で4レジスタオペランドに拡張したLarrabeeに文句つけるとか
どんだけ贅沢なんだよ
0124デフォルトの名無しさん2009/10/17(土) 01:11:48
貧弱なx86コアに貧弱なSIMD。憤死ｗ
0125,,・´∀｀・,,）っ-○○○2009/10/17(土) 01:15:39
ぷっ
Larrabeeの多段SIMDを貧弱なんていったら
たった1ワープサイクル2オペレーションしか発行できないFermiは蠅以下ですか？
0126デフォルトの名無しさん2009/10/17(土) 01:19:36
はいはいfermiの１／２程度ですね。
0127,,・´∀｀・,,）っ-○○○2009/10/17(土) 01:21:56
1SPあたりで見たらLSUやSFUの性能がGT200の1/2程度に落ちてるのがFermiです
0128デフォルトの名無しさん2009/10/17(土) 01:28:37
N厨ｱﾜﾚｗｗｗｗｗｗｗ
0129デフォルトの名無しさん2009/10/17(土) 01:38:46
は？SFUの数は変わってないし。他のロジックとの共有をやめたので効率は上がってるが？
0130,,・´∀｀・,,）っ-○○○2009/10/17(土) 01:39:21
Fermiってさ
あの巨大なダイの半分以上がテクスチャだのROPだの固定機能ユニットなんだろ
純粋にGPGPUとして使ったときに、役に立たないゴミでしかないんだが
なんでそんなものに拘り続けるの？

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

Fermiが1サイクルに2オペレーション捌くところをLarrabeeはピークで
5～6オペレーション相当捌けるから、効率には相当差ができる
0131デフォルトの名無しさん2009/10/17(土) 01:41:51
ららび512レジスタに対してfermi32768レジスタｗ
0132,,・´∀｀・,,）っ-○○○2009/10/17(土) 01:46:28
馬鹿だなｗｗｗ
しかもレジスタ本数の計算間違えてるし

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

そしてHPCでは何の役にも立たない
0133デフォルトの名無しさん2009/10/17(土) 01:50:12
まあ君みたいに前時代的アルゴリズムと使用用途に固着して時代に取り残されている人にとってはそうでしょうなあ。
0134,,・´∀｀・,,）っ-○○○2009/10/17(土) 01:53:36
レジスタはメモリみたいにアドレッシングできないし、容量が大きくなると
結局レイテンシが大きくなってしまうので、キャッシュのほうが使い勝手がいいってこともある。
シングルサイクルで読み出せてソースオペランドの一つに使えるLarrabeeの特権だけど。
0135,,・´∀｀・,,）っ-○○○2009/10/17(土) 01:54:33
>>133←レジスタ大量に載せれば速いなんて前世紀の発想の持ち主の電波をお楽しみください
0136,,・´∀｀・,,）っ-○○○2009/10/17(土) 02:03:44
スレッド数を大量に動かすことを要求する、すなわち結局1スレッドあたりの性能は悪いって事なんだぜ。
わかるかい？ぼうや。
0137デフォルトの名無しさん2009/10/17(土) 02:04:23
133は間違いなくプログラム書いたことないな。
0138デフォルトの名無しさん2009/10/17(土) 02:12:57
Larrabeeって光プロセッサなんだよね？
0139デフォルトの名無しさん2009/10/17(土) 02:24:05
>>137
レンダリングファーム用プログラム組んでますがなにか？
0140デフォルトの名無しさん2009/10/17(土) 02:26:25
僕はいまファイヤーウォールようのフィルタをCUDAで実装してますが何か？
0141,,・´∀｀・,,）っ-○○○2009/10/17(土) 02:27:21
Intelからシミュレータも提供して貰えないような自称レンダラ屋が聞いて呆れる
0142,,・´∀｀・,,）っ-○○○2009/10/17(土) 02:31:56
>>140
ご苦労なこって
ちなみにTeslaが他のHPC用プロセッサに比べて極端に安いのはひとえにメモリにECCが無いからだぞ
ファイアーウォールって結局は信頼性確保のためだろ
本末転倒じゃね？

ちなみにFermiはGT200ベースより倍精度の性能が上がってECC対応になるので
お値段はそれなりに上がる
0143デフォルトの名無しさん2009/10/17(土) 02:34:27
OpenCLで文字列を扱いたいのですが
無理ですかね？
0144デフォルトの名無しさん2009/10/17(土) 02:38:01
>>134
Radeonは少なくともR500の頃から間接アドレッシング出来るぞ。
0145,,・´∀｀・,,）っ-○○○2009/10/17(土) 02:39:37
文字列処理って可変長でそれほどコンスタントに処理対象データ沸いてくるわけじゃないから
1万とか2万とか処理を並列で動かさないと元が取れないぞ。

GPUのSIMDユニットでで扱うには1バイトのchar型でも4バイト整数に変換して処理するしかない。
その時点でCPUに対する優位性がない。
0146,,・´∀｀・,,）っ-○○○2009/10/17(土) 02:43:30
>>144
少なくともFusionまでにアーキ変わるのわかってたからRadeonのネイティブはノーマークだっ
0147デフォルトの名無しさん2009/10/17(土) 02:47:17
団子が自分の非を素直に認めるとは
珍しい物を見た
0148デフォルトの名無しさん2009/10/17(土) 02:51:08
非というか、予想以上にAMDがｇｄｇｄったせいで団子の読みが外れたんだろう。
そのFusionが待てど暮らせど出ない上に開発環境が長いこと微妙だったからなぁ。
R600の資料は早めに出てたんだから、始めからILかISAで書くつもりで弄ってればそれなりに遊べたんじゃない？
0149,,・´∀｀・,,）っ-○○○2009/10/17(土) 02:58:31
LarrabeeってSIMD演算は1クロックに1命令しかデコード・発行できないんだよね。
Store命令はスカラ側のデコーダからでもデコードできるけど
SIMDレジスタよりもL1キャッシュ上のデータを操作したほうが演算密度稼げるという
有る意味で変な仕様。

レジスタ間オペレーションだけなら2オペレーションできるぶんFermiにも勝機は有る。
もっとも、有効な組み合わせがあるかどうかだが
NVCCってレジスタ10何本までとかの制限未だにあるんだろ？
少なくともGT200までのコードはそのまま動かしたらLSUネックで性能出ない構図だよな
0150デフォルトの名無しさん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
0151デフォルトの名無しさん2009/10/17(土) 08:04:40
>>119
いやAVXでもだいぶマシだよ。
エミュとか作ろうとすれば分かるが、それまでの命令は隣の命令との分離が難し過ぎる。

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

>>120
ばーか。
その理論がならCell（笑）にCompatibilityモード付けてもいい事に気づかないか？つーかIA64…
結局今までのバイナリがそのまま動かない、逆を言うとモード切り替えで
互換性保てるようにするなら何やったっていいんだよ。
0152,,・´∀｀・,,）っ-○○○2009/10/17(土) 10:13:32
デコーダそのものも有る程度後方互換性を持つようにしてるだろ
てか、体系が変わっちまったら互換そのものが足枷になるだろ。
Intel自身が言うように8086の32ビット拡張、64ビット拡張はOpcodeテーブルを
極力再利用する形で行われている。

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

Opcodeテーブルを増やすことの負担考えて
別の体系のものを用意しろと言ってるんなら、正気じゃねーわ。
余計にデコーダが肥大化する。
0153デフォルトの名無しさん2009/10/17(土) 10:39:44
命令長変わっても命令の実行速度は一定なんだっけ？
0154デフォルトの名無しさん2009/10/17(土) 11:31:37
ララビ速すぎクソワラタ！団子先生大勝利Fermiガチ死亡ってことでファ！！
0155デフォルトの名無しさん2009/10/17(土) 11:44:20
ララビこれ6TFLOPSぐらいでてるじゃん
化け物すぎだろｗ
0156,,・´∀｀・,,）っ-○○○2009/10/17(土) 11:54:47
>>150の内容まとめ。

>>1よ。お前みたいな奴をみると、あの日のことを思い出すよ。
２００９年１０月１６日。GPGPUの性能が本格的に頭打ちになりかけた日だよ。
転送量が多すぎて、CPU-GPU間の転送帯域がボトルネックになってるって発表されて、
あのときのIntelのTera-Scale Researchチーム、カッコよかったんだぜ。
「総力を結集」ってのはまさにああいう状態だよ。
転送量を１／３に削減しないと律速、ってもんだから、新しいプログラム組んでさ、
そしたらほんの何ヶ月かで完成したんだよ。それが聞いてくれよ、CPUの11倍で
バス帯域律速だったのが、29倍まで高速化しやがったんだよ。
職人技なんてもんじゃねえよ、神技だよ。
でもよ、そうやって頑張る人がいた一方で、「Fermi大勝利」とか駄レスつけてたバカも
いたわけだよ。ちょうど、今のお前みたいにな。
だからよ、俺たちは総力を結集して、お前のバカ度を１／３に圧縮しようと思うよ。
ま、それこそ神技をもってしても無理だろうけどな
0157,,・´∀｀・,,）っ-○○○2009/10/17(土) 12:17:48
ごめん19倍だ
0158デフォルトの名無しさん2009/10/17(土) 13:16:59
Harpertown1コア12GFlopsだとしてその16コアで10倍って言ったら120GFlopsしか出てないやん。
Larabee得手の処理でこの程度なのか。
0159デフォルトの名無しさん2009/10/17(土) 13:21:06
GPUはそれ以下なんだよね
悲しいね
0160デフォルトの名無しさん2009/10/17(土) 13:28:42
Intelの作ったアプリだから他の所にやらせればまた違う結果が出る。
またもっともパフォーマンス的に優位なケースを選んだろうから他のケースではわからない。
0161デフォルトの名無しさん2009/10/17(土) 13:53:31
心の拠り所は其処だけだなｗｗｗ
0162,,・´∀｀・,,）っ-○○○2009/10/17(土) 15:15:51
>>158
しかしよ～
CPU（シングルコア・しかもSIMDなし）の５～６倍出てマンセーやってるのがGPGPUだろ。
CUDAは不利とは思えんが？むしろCUDAが自称得意と言ってたバイオ・メディカル系
処理分野での「いつも通りの」性能だろ。
効率に振ったらどうなるかの解説としては優秀だろ

まあ可逆圧縮データの展開なんてGPUじゃ無理だろうから、上限はそこまでだろうよ。
そもそもCPU-GPU間のバス律速の境地にすら達してなかったわけで
所詮GPUの効率ってのはそんなもの
0163デフォルトの名無しさん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の場合、特定の処理ではボトルネックになる可能性はあるね。
0164,,・´∀｀・,,）っ-○○○2009/10/17(土) 15:38:23
ところがどっこい
PCIeの帯域はどのカード刺そうがみんな同じなんです～

HPC向けにはOpteronでHT-Xでダイレクトに繋げる実装も用意するんだっけ？
それ言ったらIntelもQPIが使えるわけで。
0165,,・´∀｀・,,）っ-○○○2009/10/17(土) 15:40:45
そもそも問題を選り好みするのは「汎用」とは言えないのでは？
それでよくCPUは不要になるとか言えたものだ。
0166デフォルトの名無しさん2009/10/17(土) 15:45:09
>>164
は？だからfermiで律速に達しちゃうこともあるだろうね。と書いたんだが。
君は馬鹿なのかアホなのかわからない。

>>165
どんな処理でもGPUに勝ってから言えよ。
0167,,・´∀｀・,,）っ-○○○2009/10/17(土) 15:48:36
オールラウンドで勝たないと駄目なの？
特定の処理にフォーカスするのは特化であり汎化ではない。
可逆圧縮データのデコンプレスが出来るだけでも今までのGPUと比べても十分汎用性があるのでは？
0168,,・´∀｀・,,）っ-○○○2009/10/17(土) 15:56:31
まあFermiだとVRAM帯域がGT200の1.5倍程度だったりメモリオペレーションが相対的に弱いから
GT200の2倍を確実に下回るでしょ。
そうするとPCIeの帯域飽和しない可能性のほうが大きいと思うよ

倍精度などの強化された処理を除けばGTX295以下だと思っている。
0169デフォルトの名無しさん2009/10/17(土) 16:00:04
とりあえずTeslaはLarrabeeによって死亡確定って事でｗ
GeforceもRadeonに殺されそうだがこのスレ的にはどうでもいいな
CUDAに手を出した奴涙目ｗｗｗｗｗ
0170デフォルトの名無しさん2009/10/17(土) 16:15:15
>>167
その辺はfermi出てみないとわからん。
まあ将来的にデータ圧縮必須になれば30%も演算パワー食われるよりはハードウェアで積めばいい。

>>168
メモリ帯域はGTX295の２倍を上回るだろうしSLIのオーバーヘッドや効率化による性能向上分を考えれば
GTX295の性能を下回ることはまずあり得ない。
0171デフォルトの名無しさん2009/10/17(土) 16:17:58
"GTX295の性能"は"GT200の2倍"ではない（笑）
0172デフォルトの名無しさん2009/10/17(土) 16:18:02
＞メモリ帯域はGTX295の２倍を上回る
ミス
GDDR5 1200MHzならメモリ帯域はGTX295のを上回る
0173デフォルトの名無しさん2009/10/17(土) 16:25:23
>>171
うむだからGTX285の２倍行くかは怪しい。たぶん処理によって順位入れ替わるだろう。
GTX295を下回ることはない。
0174,,・´∀｀・,,）っ-○○○2009/10/17(土) 16:26:09
＞まあ将来的にデータ圧縮必須になれば30%も演算パワー食われるよりはハードウェアで積めばいい。
キターｗｗｗｗｗ

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

PCIeの帯域を上回るスループットで圧縮データを展開しないといけないんだぜ。
はっきり言ってIntelのコーデック実装は充分効率いいと言えるのでは？
0175デフォルトの名無しさん2009/10/17(土) 16:29:10
>>174
俺の願望はfermiで圧縮余裕でした。だよ。
0176デフォルトの名無しさん2009/10/17(土) 16:32:09
カスタムリヌクスが動くんだから出来るとおもうんだが
パフォーマンスが不明ゆえ何とも言えん。
0177デフォルトの名無しさん2009/10/17(土) 16:35:40
SLIのオーバーヘッドとか何言ってるんだか。
CUDAからは別々のGPUとしてしか触れないよ。
0178,,・´∀｀・,,）っ-○○○2009/10/17(土) 16:36:14
そもそもゲームで使うシェーダなんて非プログラマブルハードウェアで定型処理やったほうが
電力効率遙かにいいんだぜ。

でも柔軟性は必要だろ？
0179デフォルトの名無しさん2009/10/17(土) 16:39:36
>>177
そういう話がしたいならGTX295以下とか以上とかの話し出してこないよな。
何を動かしたときかはだいたい想定して書いたんだと思うんだが
0180デフォルトの名無しさん2009/10/17(土) 19:30:26
>>152
うん、だからx86も糞だって言ったの。
それに対して頓珍漢なレスをした>>120が間違いなのであって
世の中理想だけではいかないと言っている団子は間違っていない。

でも度々出すようだけどやっぱSSEのrcpは酷いと思う。
トランジスタを端折る為だけに11bitにするなと言いたい。12bit用意しろ。
今でこそdivが速いからいいが、SSE出た当初は制度を要求する場面で使い物にならなかった。
01811802009/10/17(土) 19:35:24
同様に、ロングモードやAVXをもっと理想に近づける未来もあったかもしれない。

一つはAMD64の命令フォーマットが糞だった事。
もう一つは省力志向で毎度汎用性の低い方法で継ぎ足し拡張を行うIntel。
色々重なって今があるんだと思う。
0182,,・´∀｀・,,）っ-○○○2009/10/17(土) 20:42:16
愚者は木を見て森を見ず、ってか

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

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

ま、文句があるならx86より性能が出せる俺的最強命令セットを提示してみなさい。
0183,,・´∀｀・,,）っ-○○○2009/10/17(土) 20:44:09
あと、x86のアドレッシングモードの優位性は散々説明してるので敢えて書かない。
0184 ◆0uxK91AxII 2009/10/17(土) 22:44:04
GPGPUが使い物にならないのは、スレの流れから確定的に明らか。
0185デフォルトの名無しさん2009/10/17(土) 22:46:39
>>184
NASAが今注目している分野ですけどね
0186,,・´∀｀・,,）っ-○○○2009/10/17(土) 22:59:02
NASAのニーズは世界市場のニーズとかけ離れてることで有名だが。
8インチのフロッピードライブをネットオークションで買いあさったり。

0187デフォルトの名無しさん2009/10/17(土) 23:30:50
注目しているのはNASAにとって価値がある可能性があるというだけで、
途中で捨てられる可能性も、NASAにしか価値がない可能性もある。
0188デフォルトの名無しさん2009/10/18(日) 01:07:54
成功すればNASAに引き抜かれるかもよ？
0189,,・´∀｀・,,）っ-○○○2009/10/18(日) 01:18:31
先見性のNASAだけは最強
0190デフォルトの名無しさん2009/10/18(日) 01:20:59
誰が上手いことを言えと
0191デフォルトの名無しさん2009/10/18(日) 01:39:52
Larrabeeなんてどうせ注目もされずに消えるんだから
nVidiaとAMDの話しようぜ
0192,,・´∀｀・,,）っ-○○○2009/10/18(日) 03:13:46
現実逃避はCUDAスレでどうぞ
0193デフォルトの名無しさん2009/10/18(日) 08:05:20
アンチインテルを増やしているだけの疫病神
0194・´∀｀・2009/10/18(日) 08:23:40
>>181みたいな断片的な知識でしかものを語れない頭の悪いニワカですねわかります

どうぞどうぞとしかｗｗｗ
0195デフォルトの名無しさん2009/10/18(日) 10:24:06
>>182
誰も長くなる事が悪いなんて一言も書いてないんだけどな。
でもプリフィックスが増え続けるのは愚の骨頂だよね。AVXなんて無くて良かったとでも?

ていうかSSEに関しては最初の命令が酷いんだが。
0196｀・∀・´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の歴史の繰り返しなんだよね。
0197,,・´∀｀・,,）っ-○○○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バイトのミスは許容される
0198デフォルトの名無しさん2009/10/18(日) 21:27:00
アセンブラで書けるような単純な部分はたいていCUDAで爆速になるからな。
無駄な努力ですな。
0199デフォルトの名無しさん2009/10/18(日) 21:58:40
CUDAで速くなる部分って、CPUのコードでアセンブラで
最適化すべき部分のうちのほんの一部のクラスに過ぎないだろ。
圧縮・展開みたいな入出力が可変サイズで、順序が重要なものの扱いは厳しい。
0200デフォルトの名無しさん2009/10/18(日) 22:01:25
それは今あるアルゴリズムの問題だろう
CUDA用の新しいアルゴリズム開発すればいい
0201デフォルトの名無しさん2009/10/18(日) 22:02:21
プログラム書いたことない人登場ｗ
0202デフォルトの名無しさん2009/10/18(日) 22:06:30
不可逆でいい用途なら固定長圧縮は得意だろうが。
S3TCみたいなみたい奴ね。
0203デフォルトの名無しさん2009/10/18(日) 22:09:57
>>199
最適化すべき部分のうちのほんの一部のクラスの実行時間が全体に占める割合次第。
その部分がクリティカルな用途なら効果的なわけで
一般論を語っても無益。
0204デフォルトの名無しさん2009/10/18(日) 22:12:49
要するにN厨はアホ
0205デフォルトの名無しさん2009/10/18(日) 22:12:59
>>200がツボに入ったww
0206,,・´∀｀・,,）っ-○○○2009/10/18(日) 22:16:14
Fermiってアセンブラ使わないとレジスタ足りなくてすぐにL/Sネックになりそうなんだが
0207デフォルトの名無しさん2009/10/18(日) 22:30:22
>>203
いや、一般論じゃなく用途によると言っているだけだよ。

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

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

0208,,・´∀｀・,,）っ-○○○2009/10/18(日) 22:32:24
というか、製品出してから「実は～に向いてる」なんて言ってる時点で
明確なターゲットなんて無いんだろ。

その時点で効率を追求したストリームプロセッサには負ける。
0209,,・´∀｀・,,）っ-○○○2009/10/18(日) 22:34:06
> 高いコストを払って絶対的な汎用性を実現するCPUと、
> 汎用性を制限する代わりにより高速に演算するGPGPU

GPGPUなんて結局遅いんだからCPUのSIMD命令で全部書かせろ
ってのはあり？
0210デフォルトの名無しさん2009/10/18(日) 22:35:15
2倍遅いというだけで捨てられたアルゴリズムはたくさんあるからな。
そういうのがCUDAで逆転するのはよくある話で。
いろいろやる価値はあるよ。
0211デフォルトの名無しさん2009/10/18(日) 22:36:51
なんでどっちかしか使わないという頭でっかちしかいないの？
汎用的な処理でGPGPUがCPUに勝てるわけないんだから、それぞれ有用な用途に使えばいい
0212 ◆0uxK91AxII 2009/10/18(日) 22:37:48
どこぞのゲームの動画を撮影するprogramを書いてみた時、
GPUでのXRGB to YUY2は使い物になるって感じだった。

VRAMから取り出す量が半分になるのが、オイシイ。
0213,,・´∀｀・,,）っ-○○○2009/10/18(日) 22:40:30
並列はCUDAの特権でもないんだけど
むしろベクトル内の横方向の演算が無いのが致命的。
たとえばSSE2のPSHUFDみたいなオペレーション無いだろ。

メモリにストアしてロードでしか要素の入れ替えできないんじゃスループット稼げるはずもなく。
（特にFermiはロード・ストアがネックだし）
そのへんがSIMDとしての活用の幅を狭めてる。
0214デフォルトの名無しさん2009/10/18(日) 22:41:59
gpuが得意とする演算は、基本的に一次変換とビット演算でしょ？
さらにフーリエ変換のライブラリが使えるんだから
そういう方向でアプリケーションを考えたらいい。
衝突演算のボードを追加したら、応用範囲は相当広い。
ビジネスアプリケーションに向くとは思わないが。
0215デフォルトの名無しさん2009/10/18(日) 22:46:55
同一warp内のスレッド内でレジスタ間の直接シャッフル参照が
2サイクルとかで出来れば美味しいのに。
シャッフルのパターンも完全自由でなくて数パターンでもいい。

あと、ワープ内の分岐状態でtakenの数を数える命令と、
ワープ内のスレッドのうち自分より前にあるtakenのスレッド数を数える命令
があれば、ループが終了したスレッドのみに新たなデータを充填して
ループに戻るみたいな処理も簡単に出来るのに。
0216デフォルトの名無しさん2009/10/18(日) 22:51:11
OEDとかいうエンジンを
高速化できんかね？
0217デフォルトの名無しさん2009/10/18(日) 22:55:12
>>216
君が言ってるのは、CUDAは汎用的ではありませんという
当たり前のことだけじゃないか
0218デフォルトの名無しさん2009/10/18(日) 22:56:15
>>217は>>213への間違い
0219,,・´∀｀・,,）っ-○○○2009/10/18(日) 22:59:48
汎用（General Purpose）を捨てたらただのGPUなんだが。
まあIntelがある限りこっち方面は芽はないと思うよ
Radeonにシェア奪われるんじゃNVIDIAのためにもならん。
0220,,・´∀｀・,,）っ-○○○2009/10/18(日) 23:04:36
そもそもOpenCLとかCUDA Cの構文ルール自体がベクトルの横方向の演算を表現できない
制約がある気がするんだが
0221デフォルトの名無しさん2009/10/18(日) 23:04:55
どこまで汎用性を持たせるかで、
汎用性のために全体の構成を弄り過ぎるのは
GPUの構造上のメリットを薄める恐れがある。
小手先の対応でどこまで汎用化できるか
追求した方がいい結果を生むかもしれない。
AMDの路線はそんな感じだ。
RV730で一度粒度を小さくしたのに又戻したのは
実は余り意味がないと判断したんじゃね。
まあ、これが正解かと言われると微妙だが。
0222,,・´∀｀・,,）っ-○○○2009/10/18(日) 23:05:49
730はただの下位モデルだろ
0223デフォルトの名無しさん2009/10/18(日) 23:06:11
>>196
> コンシューマPPCのクロック向上を停滞させた主犯がAltiVecと言われてるくらいだし

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

>>213
そこがまさに今までSSEが糞だった理由じゃねーか。
自分の愛するIntel様が完璧なシャッフル実装したら今度は他を叩くのかよ。
0224デフォルトの名無しさん2009/10/18(日) 23:08:14
よしじゃあここでOpenDango言語を作って
高速化GPGPU言語仕様決めようぜ

言語仕様に不備があったら、コンパイラスレの奴拉致すればいいだろうし
0225,,・´∀｀・,,）っ-○○○2009/10/18(日) 23:14:46
＞今のIntelとゲーム機はどうなるんだ

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

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

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

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

pshufbで1ベクトル内の入れ替え系は全部表現できるがそれで全部置き換えたいとは
思わんな。1レジスタ消費するし。
0226デフォルトの名無しさん2009/10/18(日) 23:24:16
>>220
そこら辺、実は関数っぽい形式の拡張でやろうと思えば
幾らでも対応できそうな気が。
AMDのレーンごとの共有レジスタみたいなのも
実質ハードウェアコスト0だから美味しいんだけど。
内部処理の特性でレーンのodd,even毎に
長いALU命令列が丸ごとatomicになっているから
reduce演算で使いであるよ。

まあ、OpenCLに組み込むのは難しいかな。
0227,,・´∀｀・,,）っ-○○○2009/10/18(日) 23:29:26
Pentium IIにSSE付けてほぼ同じパイプライン構造でリリースしたPentium IIIは
クロックは1GHzオーバーまで伸びたよね

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

CPUのSIMD拡張はあくまでスカラの補助なわけで、スカラ演算の性能を縛っちゃ本末転倒だよ。
0228,,・´∀｀・,,）っ-○○○2009/10/19(月) 00:10:36
>>236
OpenCLはベクトルの各要素の中で動かす処理を記述する形式だから
他の要素とのリレーションを記述するのに向かないでしょ

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

コード量半分以下でC+組み込み関数での性能の80%近い性能を実現できるんだからだいぶ楽だと思うよ。
それでもオレは余すことなく使うためにアセンブるわけだが。
0229,,・´∀｀・,,）っ-○○○2009/10/19(月) 01:44:42
226だた
0230デフォルトの名無しさん2009/10/19(月) 02:53:32
>>228
別スレッドあるの前提でlocalメモリ使っているんだから余り変わらないだろ。
localメモリ使ったshuffleコードを最適化でshuffle機能に落とすのでもいいけど
素直に拡張関数みたいな形式の方がコンパイラもコード書くほうも楽。
0231,,・´∀｀・,,）っ-○○○2009/10/19(月) 03:19:01
どう表現するのか次第だがな。
kernel関数って原則要素毎に実行だろ。

ベクトル全体で1つのシャッフル操作とか、向かないだろ
0232デフォルトの名無しさん2009/10/19(月) 05:44:03
>>225
> まさかCellのPPEとか？
ほれ、日本で大失敗してるもう一個の方の奴。
0233デフォルトの名無しさん2009/10/19(月) 07:05:55
>RV730で一度粒度を小さくしたのに

演算粒度自体は変わらず、演算サイクルが倍に増えたという
0234デフォルトの名無しさん2009/10/19(月) 08:36:32
>>225
GPGPUを見下すために面白かったで逃げるのかよ。
お前の用途ではいらないかもしれないけど実際使うんだよ。

>>227
だから旧モトローラの力がなかった理由をお前の勝手な想像で話を進めるな。
その前で話題にしていたCellだってXboxだってPPC G5だってVMX持ってるだろうが。
Intelにはごり押しする力があるが、モトローラにはなかったという事実があるだけだ。
0235´・∀・｀）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ヲタのオッサンすらあれの設計のひどさは擁護できないとな。
0236｀・∀・´）2009/10/19(月) 09:53:07
ついでにIntelの資金力とは言うが、当時の元ローラよりよっぽど金持ってないAMDが
Athlonを投入し、性能競争においてIntel相手にタメはれてたわけで、
POWERアーキが性能競争力がなくなったんでなければ、
よっぽど企業努力が足りないんだろうな。IBM含め。
0237デフォルトの名無しさん2009/10/19(月) 10:08:00
>>236
技術の時流にもはや合わなくなったriscにしがみついた
ストラテジーの失敗だろうな。
0238デフォルトの名無しさん2009/10/19(月) 10:33:11
同じISA、同じ市場で勝負したAMDと、POWER他を比較するのがそもそも変だろ
0239デフォルトの名無しさん2009/10/19(月) 10:41:59
>>238
お前GPGPU否定したな。
ISAが同じじゃないとCore i7やXeonと性能比較しちゃいけないらしいぜ。
0240デフォルトの名無しさん2009/10/19(月) 11:48:55
特定のPhotoshopプラグインとか一部の処理において
PPC G4 500MHzがPentium III 800MHzの性能を上回るとか
みっともないプレゼンやってたけどな。
昔どっかのジョブズさんが。、
0241デフォルトの名無しさん2009/10/19(月) 13:18:46
でもさ、Intelは資金力、技術力ももはや独走状態でしょ。こういうのは良くないね。
素晴らしいアーキテクチャがあったとしても、結局はx86の資産がものいうから、Intelの土俵で戦わないといけないので、Intel有利はいつまでも続くのだろう。
どんな条件でも100倍速いというものでないかぎりは。
0242デフォルトの名無しさん2009/10/19(月) 13:49:05
同じ土俵って？
別にLinuxの同一オープンソースアプリでベンチやってもいいんだぜ。

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

ARMみればわかるように可変長命令には新たに採用してもいい
くらいの合理性はある。
Thumb-2ではモードレスで2バイト命令と4バイト命令の混成が可能になり
高いコード密度と性能をシームレスで両立できるようになった。
この際だから8バイト命令を追加して、2つ以上のオペレーションを
1命令にパックとかやれば、x86に迫るハイパフォーマンス設計が
可能かもしれない。
0243デフォルトの名無しさん2009/10/19(月) 13:54:45
まあIntelの資金力を引き合いに出して没落RISCに同情するのは
貧乏AMDが作ったOpteronの性能に勝ってからにしろと。
0244デフォルトの名無しさん2009/10/19(月) 15:38:34
まあ日本の大学には未だに老害が大量にいるからな

http://ist.ksc.kwansei.ac.jp/~ishiura/2003arc/note/arctrend.pdf
学生がかわいそうだよな
Pentium 4が内部RISCだからこれからはRISCの時代だと思っちゃったんだろけど
ごらんのありさまだよ。
x86マイクロアーキテクチャのパフォーマンス戦略はCISCというか
シンプルなLIW路線へと回帰している。
0245デフォルトの名無しさん2009/10/19(月) 15:43:54
まあ日本の大学には未だに老害が大量にいるからな

http://ist.ksc.kwansei.ac.jp/~ishiura/2003arc/note/arctrend.pdf
いや学生がかわいそうだよな
Pentium 4が内部RISCだからこれからはRISCの時代だと思っちゃったんだろけど
ごらんのありさまだよ。
x86マイクロアーキテクチャのパフォーマンス戦略はCISCというか
シンプルなLIW路線へと回帰している。
0246デフォルトの名無しさん2009/10/19(月) 18:38:56
RISCの命令を、内部で可変長のマイクロコードに変換して実行すれば良いんじゃね
命令L1にはマイクロコード置いとく、と…あれ？これ（ｒｙ
0247デフォルトの名無しさん2009/10/19(月) 18:46:28
字面どおりのRISCのメリットはスーパースカラの時点で終わっているだろ。
0248デフォルトの名無しさん2009/10/19(月) 19:07:04
逆NetBurstか
まあ、そこで可変長である意味はないんだが。

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

ちなみにRISCの内部コード結合はPOWERでもやろうとはしてるみたいだが
あまり効果を発揮してないようで・・・。
アセンブラからCのソースへの逆コンパイルが難しいように、
単純命令から高級命令への変換はあまり効果を発揮していない。
0249デフォルトの名無しさん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寄りじゃないからな。
0250デフォルトの名無しさん2009/10/19(月) 19:52:25
> > 単純にパイプラインの1ステージに演算を詰め込みすぎたんでクロックが上がらなかった。
>
> Pentium4の事ですね、分かります。

これ逆だと思うけど。
クロック上げたけどパイプライン段数が増えすぎて実効効率が落ちた。
0251デフォルトの名無しさん2009/10/19(月) 19:53:48
現段階ではAMDはx86事業止めたら黒字化すると思うけどな
0252デフォルトの名無しさん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
0253デフォルトの名無しさん2009/10/19(月) 20:00:50
極低温OCだとP4はぶっちぎりに高クロックまで回ってた記憶があるが
0254デフォルトの名無しさん2009/10/19(月) 20:07:14
ぼくのかんがえたさいきょうのめいれいせっとマダー？
0255デフォルトの名無しさん2009/10/19(月) 20:17:11
pen4はリーク電流とかの絡みで思ったよりクロックが上がらんかったような
0256デフォルトの名無しさん2009/10/19(月) 20:22:08
「x86を貶す俺ｶｺｲｲ」な彼は言ってることが頓珍漢だし
どうすればいいんでしょうかね
0257デフォルトの名無しさん2009/10/19(月) 20:38:12
>>255
Dellから4.2GHz動作のPentium Dマシンが出てたが
たぶん有名メーカー製PCとしては歴代最高クロックじゃないかな。
0258デフォルトの名無しさん2009/10/19(月) 20:45:14
>>257
当初はもっと行く予定じゃなかったっけ
0259デフォルトの名無しさん2009/10/19(月) 21:09:50
それがどうした？
内部処理を固定長RISCに置き換えたら結局使えない糞になるって
証明じゃないか。

都度デコードしてでもアドレッシングモード付きの命令を
μOPs Fusionして捌いたほうが性能が出るってことで
x86の従来フォーマットの優位性が示されたわけだが。
0260デフォルトの名無しさん2009/10/19(月) 21:35:52
>>259
コテつけ忘れているよｗ
0261デフォルトの名無しさん2009/10/19(月) 21:53:17
Core i7はそれほど大きくないループに対しては
デコードに対してキャッシュが利くので十分だな。
SIMD使ったとしてもアンロール要求されることもないし。

0262デフォルトの名無しさん2009/10/19(月) 21:58:06
http://www.donanimhaber.com/AMDden_Nvidia_Fermi_atagi_iste_detaylar-16160.htm

AMDからも馬鹿にされてるなFermi
0263デフォルトの名無しさん2009/10/19(月) 22:07:12
AMD必死だなｗ
0264デフォルトの名無しさん2009/10/19(月) 22:35:43
AppleのOpenCLが加速してまうで、どうすんのよNV・・・
0265デフォルトの名無しさん2009/10/19(月) 22:42:54
"Paper Dragon"
まあ事実だからしょうがない

　　　　　　,,,
(　ﾟдﾟ)つ┃
　　　（・´ω`・）
0266デフォルトの名無しさん2009/10/19(月) 22:53:12
はげども、答えろ。はげっが。
0267デフォルトの名無しさん2009/10/20(火) 00:25:27
>>264
OpenCLはCUDAベースだから涙目なのはAMDだよ
OpenCL SDKのサンプルを動かしてみると歴然としすぎ
OpenGLと違ってコード共通の意味が無いｗ
0268,,・´∀｀・,,）っ-○○○2009/10/20(火) 01:56:04
紙竜！
紙竜！
0269デフォルトの名無しさん2009/10/20(火) 07:59:37
実物が存在するというのは強みだな
あとはハンダ不良率が高くないのも
0270,,・´∀｀・,,）っ-○○○2009/10/20(火) 08:42:24
電源ピンが途中で切れてるが故にTDPが0W


　　　　　　,,,
(　ﾟдﾟ)つ┃
　　　（・´ω|
0271デフォルトの名無しさん2009/10/20(火) 18:05:38
OpenCL版がbrook+より遅い理由がAMDのフォーラムに書いてあるが
大きな理由としてOpenCLのデフォルトのポインタがrestrictじゃない事が上げられている。
こんな糞仕様だったのかと。
0272デフォルトの名無しさん2009/10/20(火) 18:46:49
ガツガツ解析して最適化するようなことはしてないのね。
ヌビはやってるのに。
0273デフォルトの名無しさん2009/10/20(火) 20:16:55
amdだもの
0274デフォルトの名無しさん2009/10/20(火) 20:34:48
はっきり言ってポインタなんかある方がおかしくね？
大体CUDAでC言語云々言い始めた頃から、違和感を感じてた。
HLSL程度の仕様で十分じゃん。
0275,,・´∀｀・,,）っ-○○○2009/10/20(火) 21:29:42
AVX版AESの方が1バイト短いよね
だからなんだって言うレベルだが
0276,,・´∀｀・,,）っ-○○○2009/10/20(火) 21:30:29
589
0277デフォルトの名無しさん2009/10/22(木) 15:14:02
FermiのLoad/Storeユニットの相対的なスループットは一般のプロセッサに対し低くなっている。
GPUの処理はレジスタ上の同じ値に対して同じ値との積和算を繰り返すだけでほぼ完結するからだ。
だがそれが汎用ストリームプロセッサとしてどうかというのは別問題。
倍精度まで大幅強化してLSUネックじゃ、使える用途は大幅に限られる。
確かにPaper Dragonかもしれん。

違う方向のものを追いかけてブレてるNVIDIA。合掌。
0278デフォルトの名無しさん2009/10/22(木) 18:23:03
globalメモリへのアクセスだったらどうせ実帯域狭いから
L/Sユニットのスループットは余り性能に響かないんじゃない？
localメモリへのアクセスが遅いのは厳しそう。
0279,,・´∀｀・,,）っ-○○○2009/10/22(木) 22:15:06
TSUBAMEも2.x世代になるとOpteron + FermiとXeon + Larrabeeの競演になるんだろうな
ある意味楽しみで仕方がない

0280デフォルトの名無しさん2009/10/23(金) 02:27:57
fermiのLSUは単純に考えてGT200の1.75倍の性能だね。
0281,,・´∀｀・,,）っ-○○○2009/10/23(金) 07:44:05
単純に考えてLarrabee 2コア分（32SP相当）の1/4の性能だけどね。
0282デフォルトの名無しさん2009/10/23(金) 19:36:33
　　　　　　　　　　　∬
　　　　　 　 　 　 　 |:|
　　　 　 　 _＿＿＿|:|＿＿＿
　　　 　,ｲ´　 　ノ´　　　　ヽ. ｀ヽ.　新しいバイトも入って
　　 　 {　　 ●　　（__人__） 　●.}　　Win7どころじゃ
　 　 　 ﾞ'ゝ、 　　　｀ ⌒´ 　 _ .,ノ　　ないんだよね
　　　 　/　 ￣￣￣￣￣￣ｨヽ
　 　 　/ 　　　　　　　　　　　　|
　　 　 |.　⌒＼　　　 ,.────.､　ｷﾞｰｺ　ｷﾞｰｺ
　　 　 ｌ　＼/￣＼（(| i'￣￣￣｀i | ).））　　
　　 　 ｌ　 　uUUU二| |..||￣,','￣| |￣￣￣￣￣.「＿＿＿＿＿　
￣￣￣￣￣￣￣￣|_|~|| 　~~~~|_|.　 Fermi　　.|
　　　　　　　　　　　 　　||＿＿＿＿_　　　　 　__|]
　　　　　　　　　　　　　　　　　　　 ┌!!_______!!.!
　 　 　 　 　　　　　　　　　　　　　　
0283デフォルトの名無しさん2009/10/23(金) 19:56:51
目がキモイ
0284,,・´∀｀・,,）っ-○○○2009/10/23(金) 23:23:08
　http://www.fixstars.com/company/event/gpu_seminar.html

せこい商売だ
0285デフォルトの名無しさん2009/10/24(土) 00:44:24
>>284
これ人集まらなくて
困ってるらしいから行ってやれよ
0286,,・´∀｀・,,）っ-○○○2009/10/24(土) 01:15:17
たとえばだよ、、Larrabee用のコンパイラで普通のC++/OpenMPのコードをビルドするだけで
CUDAの半分でも性能でたら、馬鹿馬鹿しくてGPGPU専用言語なんて勉強しませんって。
何のための言語なの？何のための機械なの？

ニーズなんて殆ど無いのは最初から解ってる。
頭の悪い零細企業騙すだけの悪徳セミナーだよ。
0287デフォルトの名無しさん2009/10/24(土) 01:23:21
larabeeだってIntel独自のLN何とかという糞命令覚えないとならないんだろ？
0288デフォルトの名無しさん2009/10/24(土) 01:33:45
ていのうおつ
0289デフォルトの名無しさん2009/10/24(土) 01:36:08
ララビーってコンシューマレベルの価格帯に降りてくるの？
それなら団子の言っていることは正論だが、たぶんそれはない
所詮ララビーはインテルのメニーコア路線においての実験プログラムにしか過ぎないじゃん
0290デフォルトの名無しさん2009/10/24(土) 01:44:59
>>289
CPUへの統合まで仄めかしているのに永遠にコンシューマ帯に
降りてこないと決めつける根拠を述べてみろよ。
0291デフォルトの名無しさん2009/10/24(土) 01:45:46
>>285

1日目はいらんな。

団子さんがLarrabeeのセミナー開いたら？
土日だけでも結構集まると思うぞ。
0292デフォルトの名無しさん2009/10/24(土) 01:46:31
仄めかしてるって言うか、IDFで公式に認めたよな。時期が秘密ってだけで。
0293,,・´∀｀・,,）っ-○○○2009/10/24(土) 01:54:35
>>289
TeslaならともかくGeForce（笑）みたいなコンシューマレベルが買うようなハードで動く
泡沫ソフトで元が取れる技術だとでも思ってるのか？

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

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

Fixstarsもまだ名前が売れてるうちに技術売りつけようと必死必死。
0294デフォルトの名無しさん2009/10/24(土) 02:30:14
Tesla C1060が10万切ってたから衝動買いしてしまったｗ
ま、自分でCUDAでゴリゴリ書くの断念してもCUBLASで使えればそれでいいや。
0295,,・´∀｀・,,）っ-○○○2009/10/24(土) 02:46:44
なんにせよ言語取得のためのセミナーとしては異常に高すぎるだろ。
Ruby On Railsのセミナーの参加料なんて全国各地でやってるがたかだか数千円レベルだぞ。
まあ、席が埋まればたった二日で100万以上売り上げるわけだからな。
OpenCLという虚構に満ちた技術で最も稼ぐ手段とは、
よくわかってない開発者向けのFixstars自身によるぼったくりセミナーという罠。
やってることがネズミ講レベル。

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

求められてるとすれば「スループットが欲しい」のであって、ハードと言語の縛りから選択の余地がないだけ。
その点FermiなんざLarrabee程には望まれてない。
0296デフォルトの名無しさん2009/10/24(土) 03:01:34
>>295
言いたいことはわかったから、団子さんLarrabeeのセミナーを開いてよ。

だめなら、このスレでいいからセミナーライクなことをしてよ。
期待しているよ。
0297デフォルトの名無しさん2009/10/24(土) 03:11:39
>>295
今日は語るねぇ。

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

ニッチ向けだから商売になる（大学とか研究所とかに深く入り込むと、そこで使う
技術がニッチになればなる程、自分とこ以外受託できなくなる）ってこともあるので、
純粋にそういう所の人たちが聴きに来ることもあるだろうし、まぁ、そもそも
そんな怒るような内容でもあるまい。
0298デフォルトの名無しさん2009/10/24(土) 09:26:14
Appleが全力でOpenCLに・・・
どうすんのよNV・・・
0299デフォルトの名無しさん2009/10/24(土) 09:29:04
AMDもIntelもGPU統合のCPU出た時点で
Geforceは動作しないからなぁ
0300デフォルトの名無しさん2009/10/24(土) 10:12:49
一般向けのGPGPUがCSとOpenCLに収斂していくのは既定路線だからどうでもいい
CPUとGPU統合が非常にまずい、廃業レベルにまずい
0301,,・´∀｀・,,）っ-○○○2009/10/24(土) 11:39:02
GPGPUという市場自体HPCのごく一部じゃないの
「GPGPUで置き換えよう」という発想そのものを潰すのが目的だろう


あとはエンプラ方面ではクラウド（笑）かね
0302デフォルトの名無しさん2009/10/24(土) 12:58:01
超究武神覇斬コンピューティング
0303デフォルトの名無しさん2009/10/24(土) 13:36:41
エアリス使う奴は心が醜い
0304デフォルトの名無しさん2009/10/25(日) 00:21:43
PGIがCUDA対応のFORTRAN2003出すよう棚
0305デフォルトの名無しさん2009/10/25(日) 00:30:57
PGIはAMD見捨てたからなぁ
どうなるか解らんなぁ
0306デフォルトの名無しさん2009/10/25(日) 14:01:09
S3の新しいGPUはOpenCL対応らしいな。
0307デフォルトの名無しさん2009/10/25(日) 15:54:32
死にそうで死なないなS3
0308デフォルトの名無しさん2009/10/25(日) 22:05:04
>>297
基本的にわかってない奴らからぼったくるのがFixs○tarsの方針に思える。
商売としては正しいと思うが.....
全体的に値段が高すぎる。それほどの価値はない。
0309デフォルトの名無しさん2009/10/25(日) 22:19:21
>>307
取りあえずVIAのチップセット用ので最低限会社回せるだけは稼いでるのかもな。
0310デフォルトの名無しさん2009/10/25(日) 22:43:14
>>308
まあ、CUDAの環境セットアップやら、文法やらデバッグの基礎辺りを
自習できない程度の人間じゃぁ何にもならないから、こういうの
金払って聴きに行ってるようではしょうがないと言えるかもね。

並列アルゴリズムの徹底的な講義なら自分も聴いてみたいが、
そういうのはどっかの大学院で情報系のマスターの講義でよさげなのを
聴講させてもらうとか何かするほうがまだ余程役に立つだろうな。
0311デフォルトの名無しさん2009/10/25(日) 22:45:46
ＧＰＧＰＵでErlangが動作するＶＭってないですか？
0312デフォルトの名無しさん2009/10/26(月) 10:28:03
>>310
高卒のくせに上等ぶるなよ。
0313デフォルトの名無しさん2009/10/26(月) 14:02:34
>>312
僻みみっともないｗ
0314デフォルトの名無しさん2009/11/01(日) 10:30:19
いきおいないぞ
0315デフォルトの名無しさん2009/11/01(日) 20:32:22
ASCII.technologiesがGPGPU特集。買ってないけど。
あと来月CUDA、1月にOpenCLの和書だって。
0316デフォルトの名無しさん2009/11/01(日) 23:27:41
BulletのOpenCL対応計画は確かに動いているらしい。
ttp://bullet.googlecode.com/svn/branches/OpenCL
GPU Computing SDKとStream SDKがあればサンプルの幾つかはビルド可能だけれど、
どれもまだドラフト段階だね。
0317デフォルトの名無しさん2009/11/03(火) 21:54:40
Fermiまた延期になりそう
騎神館の精神はもつのか
すべてがうまくいって２月に出る見込み
0318,,・´∀｀・,,）っ-○○○2009/11/03(火) 22:13:08
Havok党のための「鬼神館ブログ」でも立ち上げようか
0319デフォルトの名無しさん2009/11/04(水) 02:07:00
騎神館って何だろうと思ったら、前に検索でたまたま見た英語まともに訳せてないblogのことか。
0320,,・´∀｀・,,）っ-○○○2009/11/04(水) 02:14:32
Excite翻訳そのまんまなブログ
知識的にも残念な人なんだろうな
0321デフォルトの名無しさん2009/11/04(水) 02:21:09
そういう罵倒の仕方をするおたくも相当残念な人だな。
0322デフォルトの名無しさん2009/11/04(水) 07:47:18
事実なんだから仕方ないだろ
0323デフォルトの名無しさん2009/11/04(水) 19:27:20
騎神館が残念なのは中の人がラデスレ荒らすのに忙しいからですよ
0324デフォルトの名無しさん2009/11/05(木) 16:55:44
事実だとしても、罵倒せずには居られない時点でダメさ。
0325デフォルトの名無しさん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にグッバイしちゃったりするんじゃないのかな？?
0326デフォルトの名無しさん2009/11/05(木) 21:59:07
スレ違い
0327,,・´∀｀・,,）っ-○○○2009/11/05(木) 23:00:46
いつぞ騎神館（笑）はLucidがIntelだと思い込んでアホな記事書いてたなぁ
恥ずかしい恥ずかしい
0328デフォルトの名無しさん2009/11/05(木) 23:05:15
Intelが出資してるベンチャー企業だけどな
0329,,・´∀｀・,,）っ-○○○2009/11/05(木) 23:18:55
製造元がIntelそのものなら今回みたいな沙汰になってないだろう
もっと恐ろしいことになる
0330デフォルトの名無しさん2009/11/05(木) 23:21:30
>製造元がIntelそのものなら
ラグナロクが始まるお・・・
0331デフォルトの名無しさん2009/11/06(金) 12:55:03
亀ですまん。
>>214
＞さらにフーリエ変換のライブラリが使えるんだから
cufftのことなら、あれは遅いよ。
0332デフォルトの名無しさん2009/11/06(金) 13:48:43
インテルからいろいろいわれてNVかわいそうとか思ってたけど
NVも弱者にはえげつないんだな
0333デフォルトの名無しさん2009/11/06(金) 14:02:36
チャーリーが書いてたパートナーに恨まれてるというのはガチ臭いな
Geforce専業だったEVGAがLarrabeeカード売るって時点でNV離れ始まってたのか
0334デフォルトの名無しさん2009/11/06(金) 14:20:10
結局、GPUが得意な演算ってなんなの？
密行列とかの一部の演算以外はCPUにぼろ負けしてるよね
ビット演算だってSSE命令使えばCPUも高速化するし
0335デフォルトの名無しさん2009/11/06(金) 19:22:51
なんでわかんないの？
0336デフォルトの名無しさん2009/11/06(金) 19:59:32
なんでこんなアホがこのスレにいるんだよ
初心者スレ池
0337,,・´∀｀・,,）っ-○○○2009/11/06(金) 22:47:54
大量のスレッドに食われるから物理レジスタ本数の割にはロード・ストア回数をセーブできないのが弱点
03383542009/11/07(土) 02:20:52
なんだ、わからない人間しかいないのか
0339デフォルトの名無しさん2009/11/07(土) 10:39:57
おまえの名前がわからないよ
GPGPUの話なんてその辺に転がってるんだから調べろ
0340デフォルトの名無しさん2009/11/07(土) 19:03:03
>>354
その問題は現代科学じゃ無理だぜ…
0341,,・´∀｀・,,）っ-○○○2009/11/07(土) 19:08:26
>>354に期待
0342デフォルトの名無しさん2009/11/07(土) 19:44:42
>>354
後のノーベル物理学賞受賞者である
0343デフォルトの名無しさん2009/11/08(日) 02:07:19
ｰ-ニ _　 ＿ヾV, --､丶､ し-､
ﾆ-‐'' ／／　ヾｿ　､　!ヽ　 `ヽ ヽ
_／,.ｲ /　/ミ;j〃ﾞ〉 }￤ ｝ ハ ヽ､}
..ノ /ﾊ　 〔　　 ∠ノ乂 ｛ヽ　ヾ丶ヽ　 　 ヽ
　ノﾉ　.>､_＼　{ j∠=, }、 l ＼ヽヽ ',　　_ノ
ｰ-=ﾆ二ﾆ=一`'´__,.ｲ<::ヽリ　j　`､ ）　＼　　　>>354ッ！
{¨丶､＿ｎ_,. イ　|{.　 |::::ヽ（　{　〈　（　 　　〉
'|　　| 　 　 　　小,　|:::::::|:::l＼i　',　ｌ　　 く　　ユーの意見を聞こうッ！
_| 　｜　 　　`ヾ:ﾌ　|::::::::|:::|　 }　}　|　　　）
､|　　| 　　 ∠ﾆﾆ}　|:::::::::|/　/　/ /　　／-‐-､
トl、　ｌ 　　{⌒ヽr{　|:::::::::|,／／／　　　　　　　 ＼／⌒＼/⌒丶/´￣`
::＼丶、 　 ヾ二ｿ　|:::::::/∠-''´
/＼＼.丶、 ｀''''''′!:::::::ﾚ〈
　　 〉::￣::｀'ｧ--‐''ﾞ:::::::/::::ヽ
＼;/:::::::::::::/::／::::::::::::/／:::::〉
::`ヽ:::ｰ-〇'´::::::::::::::::/-ﾆ::::（
0344デフォルトの名無しさん2009/11/08(日) 03:33:31
結局OpneCLもちゃんと性能が出るNVIDIAに最適化されるわけか
http://www.4gamer.net/games/032/G003263/20091104040/
0345デフォルトの名無しさん2009/11/08(日) 10:01:25
えーと
0346デフォルトの名無しさん2009/11/08(日) 12:02:17
OpenCLは配列扱うのに単純にポインタで渡すなんて
物凄い並列化と相性悪い仕様だよね。
0347デフォルトの名無しさん2009/11/08(日) 12:47:50
エイリアスが無い事が保証されてれば問題ないんじゃねぇの
0348デフォルトの名無しさん2009/11/09(月) 02:12:32
OpenCLだとカーネル呼び出し時にエイリアスの有無判別できそうだけど
エイリアスありなしの2種類バイナリ用意して実行時に選択とかさせるのもアホ臭い。
それも2種類で済めば良いんだが。

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

いちいち配列サイズを引数で渡して
アクセスのたびにアドレス計算なんてするくらいなら
fortranみたいに書けた方が楽だし分かりやすい。
それに加えてhardに応じた最適化もかけ易い。
0349デフォルトの名無しさん2009/11/09(月) 23:13:01
OpenCLの本ってどれ？
いつ発売なの？
0350デフォルトの名無しさん2009/11/10(火) 19:28:44
工学社から1月予定だそうな。
0351デフォルトの名無しさん2009/11/11(水) 00:20:39
>>350
OpenCLだぞ
CUDAじゃねーぞ？
0352デフォルトの名無しさん2009/11/16(月) 00:13:46
いつになれば出てくるのかわからないFermi
すでに製品はあるがやる気がないAMD
NVを邪魔するためだけに生まれてこようとしているララビー、が未だ姿は見えず・・・
0353デフォルトの名無しさん2009/11/16(月) 00:56:13
Larrabeeはどっかのモックアップと違って実働デモまでしてるだろうが
0354デフォルトの名無しさん2009/11/16(月) 01:04:02
　 ,,・´∀｀・,,）っ-○○○

団子さんの目って「・」か「´（｀）」のどっちなんですか？？
0355,,・´∀｀・,,）っ-○○○2009/11/16(月) 01:54:39
>>354
失望した
0356デフォルトの名無しさん2009/11/16(月) 02:33:20
　 ,,・´∀｀・,,）っ-○○○
　↑　　　　↑
　　　これが目
0357デフォルトの名無しさん2009/11/16(月) 02:38:27
>>354
お前の目の付けどころにﾜﾛﾀｗ
0358デフォルトの名無しさん2009/11/16(月) 15:04:59
騎神館、もとい気振韓はねた切れ気味だな
0359デフォルトの名無しさん2009/11/16(月) 22:07:11
GPUって浮動小数点演算と固定小数点演算＋ビット演算なプログラムだとどっちが早いですか？
GPUの整数演算やビット演算ユニットはおまけみたいなもんですか？
0360デフォルトの名無しさん2009/11/16(月) 22:19:12
CUDAを勉強してて思ったんですけど、これ、CPU→GPU→CPUの転送がめちゃくちゃ足引っ張ってません？？
ほんとに大量の演算が必要か、ガッツリ最適化かけないとメリットが出ない･･･
リアルタイムの画像処理演算とかに使えるかな、と期待したんですが、そういうのには向いてないですよね？

もうCPUの隣にGPU付けれるようにしたらいいのに、とｵﾓﾀｗ
0361デフォルトの名無しさん2009/11/16(月) 23:33:20
GPU内蔵になるCore i5 6XXだと少しは転送早くなんのかね？
0362デフォルトの名無しさん2009/11/16(月) 23:36:15
Tesla20シリーズ出たね
0363デフォルトの名無しさん2009/11/16(月) 23:40:32
Tesla20は爆速だなぁ
これすげーわ
0364デフォルトの名無しさん2009/11/16(月) 23:42:26
来年Q2てなめてんなこの会社
0365デフォルトの名無しさん2009/11/16(月) 23:46:54
圧倒的過ぎるだろ…
CPUなんていらんかったんや
0366デフォルトの名無しさん2009/11/16(月) 23:48:39
倍精度が速くなったのは良いとして単精度はその2倍しかないってなめてんのか
0367,,・´∀｀・,,）っ-○○○2009/11/16(月) 23:56:40
理論スループットの額面なんて最初からわかってるだろ
0368,,・´∀｀・,,）っ-○○○2009/11/17(火) 00:00:49
案の定ペーパーローンチなわけだが
0369デフォルトの名無しさん2009/11/17(火) 00:02:01
しょぼ…
03703602009/11/17(火) 00:03:25
>>361
おお、そんなものが出るのですか。
楽しみですね。
0371デフォルトの名無しさん2009/11/17(火) 00:04:57
clarkdaleの事かな？
統合チップだと速度は上がるけどメモリの量、バスに多くは望めないよ
0372デフォルトの名無しさん2009/11/17(火) 00:15:38
単精度 1.26TFLOPS
倍精度 630GFLOPS

なにこれ・・・インパクトがなさ過ぎる
0373デフォルトの名無しさん2009/11/17(火) 00:19:56
225Wで630GFLOPSは素直に凄い
0374デフォルトの名無しさん2009/11/17(火) 00:26:07
>>373
HD5870は180Wで約550Gの性能だが。
03753602009/11/17(火) 00:26:23
>>371
しかし、現状のようにCPUとGPUが遥か遠く離れている状況よりはだいぶ効率が良くなりませんか？
少なくとも、リアルタイム系の処理での適用範囲がグっと広がるように感じます。
何か今はいくらカーネルの効率をがんばって上げても、CPU⇔GPU間転送が台無しにしてくれそうで･･･orz
今までDirect3Dでグラフィックスに使ってたときも、CPU⇔GPU転送をできるだけしないように
（ゲーム等では幸い少なくできますが）気を遣いましたし。
0376デフォルトの名無しさん2009/11/17(火) 00:26:46
よし、Fermi死亡確認っと。Larrabeeに期待！
0377デフォルトの名無しさん2009/11/17(火) 00:32:12
>>360
LIano｢呼んだ？｣
0378デフォルトの名無しさん2009/11/17(火) 00:35:25
>>370
ララビーじゃないインテルGPUで演算とか出来るわけないから期待するな。
AMDのLianoだけが当面の最強統合プロセッサだよ。
0379,,・´∀｀・,,）っ-○○○2009/11/17(火) 00:35:55
Larrabeeはその気になればWindowsが動かせそうだけど
03803602009/11/17(火) 00:42:36
>>377-378
ありがとうございます。
そういえばATIとAMDがくっついたのはCPUとGPUの統合を狙ってだったということを
すっ　　かり忘れてましたｗ

CPU⇔GPU転送のコストを思い知った今、この統合チップの構想には非常に期待できます。
そのほか、CellやLarrabeeなど、各プロセッサ同士の距離を感じないのは心地よいものですね。

nVidiaのGPUはポテンシャルはものすごいのに、ほんとうに惜しいです･･･

ああ、この先、並列コンピューティングの勢力図はどうなってしまうのでしょうか･･･
0381デフォルトの名無しさん2009/11/17(火) 00:46:02
この先の事を考えるならNVIDIAが言ってる事は無視していいです
03823602009/11/17(火) 00:52:45
やっぱりそうなりますよね･･･
nVidiaも生き残りを賭けて必死でしょうけど、あまりにもハンデが大きい･･･

団子さんのご意見も拝借したい。
0383,,・´∀｀・,,）っ-○○○2009/11/17(火) 01:08:06
ディスクリート版のLarrabeeにはあんまり期待していない。

統合CPU+GPUになってからが本領発揮。
Haswell 4GHzの4コア＋Larrabee 2GHz 16コアくらいで倍精度1TFLOPSな。
03843602009/11/17(火) 01:12:01
>>383
ありがとうございます。恐縮です。

OpenCL勉強しますｗ
今度出る本が楽しみだなぁ。
0385デフォルトの名無しさん2009/11/17(火) 01:50:32
第一世代LarrabeeはLRBniの勉強用やね。
0386デフォルトの名無しさん2009/11/17(火) 04:07:52
>>383
ダイサイズや消費電力はどの程度になるんだろうか。
0387デフォルトの名無しさん2009/11/17(火) 07:20:50
OpenCL本ってどれですか？
0388デフォルトの名無しさん2009/11/17(火) 08:09:30
>>387
>>315
0389デフォルトの名無しさん2009/11/17(火) 12:24:29
> Haswell 4GHzの4コア＋Larrabee 2GHz 16コアくらいで倍精度1TFLOPSな。
実効250GFLOPS弱か。
0390デフォルトの名無しさん2009/11/17(火) 13:27:45
GPUと一緒にするなよｗ

Intelは常に実効9割超える設計にする
0391デフォルトの名無しさん2009/11/17(火) 13:36:13
逆にtop500で実効9割超えてないのはGPGPUやGRAPE-DRみたいな
色物ばかり。
0392デフォルトの名無しさん2009/11/17(火) 15:05:29
それこそ、CPUとGPGPUを比較してもしょうがない。
0393デフォルトの名無しさん2009/11/17(火) 15:30:42
LarrabeeはCPUばりに実効性能重視設計だぜ。
それこそすべてのFPUが同時稼動することのほうが稀なGeForce/Teslaと
一緒にすべきじゃない。
0394デフォルトの名無しさん2009/11/17(火) 16:37:32
Sandy Bridgeは3.2GHzの6コア×2ソケットで
SP 600GFLOPS / DP 300GFLOPSに達する。

Fermiが実効性能5割切るようじゃ電力効率でもCPUに負ける。
もうLarrabeeが出るまでもなく使い物にならない。

GPGPU終了。
0395デフォルトの名無しさん2009/11/17(火) 17:10:51
225Wで630GFLOPSは素直に
凄い

・
・
・
・

低
効
率
0396デフォルトの名無しさん2009/11/17(火) 20:21:33
>>390
> Intelは常に実効9割超える設計にする
えー？Intelって性能誇示する時はかなり都合のよい架空の状態のみを想定するじゃん。
0397デフォルトの名無しさん2009/11/17(火) 20:27:59
77.48TFLOPS(max)/170TFLOPS(peak)
東工大「うわっ・・・Tesla性能悪すぎ・・・」
0398デフォルトの名無しさん2009/11/17(火) 20:35:32
おまえ馬鹿だろ。top500のスループット比率見てみろよ。
Xeonクラスタは軒並み実効性能90%オーバーばっかしだ。

GPUのピークFLOPS数って酷いぞ。
コンスタントにデータ供給しながら出せる数字じゃないから。
2命令同時発行なのにSP(MAD)とSFU(MUL)両方同時に動かしたら
ロード・ストアは走らせることができない。
「はまる条件」すらないのがGPU
単純に浮動小数ユニットの数を足し算掛け算やってるだけ。
全部同時に動くことは決してない。
0399デフォルトの名無しさん2009/11/17(火) 21:06:41
Fermiはピークは出ないけど実行効率上がるって記事見たけどどうなるんだろうか。
0400デフォルトの名無しさん2009/11/17(火) 21:49:43
>>399
Fermi: 16Way FMA×2に対し16Way LSU
Larrabee: 16Way FMA＋16Way Loadに対し16Way Store

ぜんぜん話にならん
0401デフォルトの名無しさん2009/11/17(火) 21:52:12
TOP500の1位はOpteronだけどな
Intelの設計思想は数値計算じゃ向いてないってこと
0402デフォルトの名無しさん2009/11/17(火) 22:00:27
米国のITゼネコン最大手のIBMが自社開発SOIプロセスの製品を使ってるだけの
話だけどな。

本当に向いてないならXeon搭載スパコンが８割とかありえない。
0403デフォルトの名無しさん2009/11/17(火) 22:00:41
実行効率の話をしてるのにTOP500の順位を持ち出すバカなAMDerは不要
0404デフォルトの名無しさん2009/11/17(火) 22:04:56
>>315
もうどこにも売ってなかった(´・ω・`)
0405デフォルトの名無しさん2009/11/17(火) 22:08:40
>>404
何か、数が少なかったね。
自分も大型の書店で何とか入手した。
まぁ、こんな特集でもない限り、滅多に買わないんだけどね。
0406,,・´∀｀・,,）っ-○○○2009/11/17(火) 23:02:46
吠える吠えるｗｗｗｗｗ
0407デフォルトの名無しさん2009/11/17(火) 23:06:02
わんわん
0408,,・´∀｀・,,）っ-○○○2009/11/17(火) 23:30:51
1ワープで処理するブロック単位を64×n行列とかそれ以上にすれば原理上ロード回数を抑えられるが
ワープあたりのレジスタ本数を多めに取る必要が生じる。

もっと言うとD3DMatrixとか使ってCPU側で処理してた4x4行列の操作も数命令でLarrabee側で処理出来る。
何がおいしいかって？
頂点にせよピクセルにせよ、CPUで処理した後はGPUに流さないといけないじゃん。
0409デフォルトの名無しさん2009/11/17(火) 23:43:30
団子は自分の領域外の話に首を突っ込むとすぐバグるなぁ
0410デフォルトの名無しさん2009/11/17(火) 23:57:45
デバッグ、デバッグ
0411,,・´∀｀・,,）っ-○○○2009/11/18(水) 00:00:09
君が理解出来ないだけでしょ。

http://msdn.microsoft.com/ja-jp/library/cc372315.aspx
に書かれてるような4x4行列の四則演算程度なら実装出来るよ。というかコード書いてる。
オンレジスタで処理出来るからね。

転置行列作る場合はいっぺんL1にストアしてからvgatherdやったほうがいいかも
0412デフォルトの名無しさん2009/11/18(水) 00:06:05
Borderlandsときいて飛んできたらこれだよ！
0413デフォルトの名無しさん2009/11/18(水) 00:09:39
なんの誤爆だよ
0414デフォルトの名無しさん2009/11/18(水) 01:11:23
これ本当に団子なのか？
0415,,・´∀｀・,,）っ-○○○2009/11/18(水) 01:48:58
swizzleが便利すぎて4x4行列程度は楽勝すぐる
0416デフォルトの名無しさん2009/11/18(水) 07:23:52
1月に出る本ってどれよ
ちょっと名前教えろよ

頼むね
0417デフォルトの名無しさん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にした方がよっぽど使えるわ
0418デフォルトの名無しさん2009/11/18(水) 10:52:57
何故このスレに来た
0419デフォルトの名無しさん2009/11/18(水) 10:56:47
>>417
画像処理なら16並列くらい使うが面倒なのは確かだな。
0420,,・´∀｀・,,）っ-○○○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
0421,,・´∀｀・,,）っ-○○○2009/11/18(水) 13:22:56
ちなみにCUDAはもっと不自由で
Load/StoreユニットはHalf Warp単位でデータを読み書きするが
同一キャッシュラインに収まる分しか1サイクルで取れないから
結局ロードネックで性能が出ない。
swizzleするのもいったんShared Memoryにストアして読み直し。
性能ウンコにもほどがある。

LarrabeeもAoS-SoA相互変換できるが、ロード・ストアユニットが
ネックになるのでやらないに越したことはない。
1サイクルにロードできるデータ構造のままダイレクトに処理したほうが
まず効率がいいしｗ

>>417の教養のなさに全米が脱糞だ
0422デフォルトの名無しさん2009/11/18(水) 13:43:17
並列処理が必要な処理をしたことないだけじゃないか？
SIMDの有用性なんて、特定の人が限られた条件下でしか
使わない機能なんてのは、MMXで十分わかっているわけで、
万人が使うものじゃないよ。
だから用途がない人は、無理して使わなくていい。
0423デフォルトの名無しさん2009/11/18(水) 13:56:09
>>420
それ行列 * ベクトルじゃね？
まあでも、それをそのまま拡張すれば16要素フルに使って
行列4x4 * 行列4x4出来そうだな。
つーかララビはノーペナルティでswizzleし放題なの？
だとしたら、まあちょっといいかも。
しかしSIMDがクソに変わりない、調子こくなカス。
0424デフォルトの名無しさん2009/11/18(水) 14:06:42
>>422
特定の人しか使われず、
PC使ってるあいだ殆ど動作せず、
C言語で自然に扱えない機能を
パーソナルコンピュータに入れるなっつー話しよ。
スパコンだけに入れとけや、代わりにFPUいっぱい積めや。
水増し計算で1TFlopsとか、あたかも1T回浮動小数点演算出来るとか
JAROに訴えますよ。
0425,,・´∀｀・,,）っ-○○○2009/11/18(水) 14:07:36
積和算がfused multiply-addならLarrabeeの演算ユニットは
fused (load-)swizzle-accumulateな。

だから最初から言ってるんだ。理論FLOPS数が同等なら
Larrabeeが圧倒すると。
0426デフォルトの名無しさん2009/11/18(水) 14:30:27
>>424
コンパイラが使ってくれますよ。
逆に寧ろ、FPUをたくさん積んでもその方が使いきれないと思うけど。
0427デフォルトの名無しさん2009/11/18(水) 14:53:14
>>424
書き捨てのプログラムを自分で書いて使うならSIMDなんて効率悪いだろうけど、
汎用的な処理なら誰かが苦労して最適化したライブラリ動かせば一般人にもメリットあるし。
エンコとか暗号化とかな。
0428デフォルトの名無しさん2009/11/18(水) 16:37:40
>>424
巣に帰れよ低脳
0429デフォルトの名無しさん2009/11/18(水) 17:24:37
>>416
工学社「はじめてのCUDAプログラミング」
なら出てるよ。東工大の先生の本。
ASCII.techも買った（分量は６０ページ）が、
両方とも初心者向けの本。
0430デフォルトの名無しさん2009/11/18(水) 18:28:14
実効性能1006GFLOPS(SGEMM)キタコレ
http://www.heise.de/newsticker/meldung/SC09-Intel-demonstriert-Larrabee-mit-ueber-1-Teraflops-862305.html
0431デフォルトの名無しさん2009/11/18(水) 18:55:30
>>429
あれで初心者向けなのか･･･！
すごい世界を覗いてしまった気がする（汗）
泣きそうｗ
0432デフォルトの名無しさん2009/11/18(水) 19:24:38
gemmが効率出しやすい演算だってのは知ってるけれどsgemmでスピード測っても仕方ないよなあ。
こういう分野ではgemmを沢山使う用途よりも大きな配列でgemmする用途の方が多いだろ。
でも配列が大きいとsgemmじゃ精度が足りないだろ。
何やってんだかって感じ。
0433デフォルトの名無しさん2009/11/18(水) 19:28:30
PCでもスパコンでもIntelはベンチマーク詐欺（笑）
0434デフォルトの名無しさん2009/11/18(水) 19:30:56
ベンチマークですら理論性能とかけ離れたGPU信者の負け犬の遠吠え
0435デフォルトの名無しさん2009/11/18(水) 19:32:38
2.7TFLOPS(自称)のEvergreen大勝利！！
0436デフォルトの名無しさん2009/11/18(水) 19:36:34
>>435
RadeonのSGEMMはACML-GPUでめいっぱい最適化して理論値の40%前後なので、
実はいい勝負だったりする。

DGEMMではLarrabeeはSGEMMの半分程度の値になると思われるが
Radeonは倍精度の理論値が1/5程度だから（以下略）
0437デフォルトの名無しさん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だったように思うが)
0438デフォルトの名無しさん2009/11/18(水) 19:56:58
Radeonはそもそも全部の演算ユニットを浮動小数に使いながら
データ操作もできるような構造じゃない。
ちょっと複雑なロード・ストアやシャッフルが絡むとユニットを
浮動小数演算にまわせなくなる。

GeForceはロード・ストアユニットとFPUが分かれてるが慢性的なロードネック。

Larrabeeの場合はFMAにLoad, Swizzleを組み合わせても浮動小数演算の
パフォーマンスが落ちないようなパイプライン構造になってるから
理論性能は冴えないが実際のアプリでの性能低下も少ない。
0439,,・´∀｀・,,）っ-○○○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
0440デフォルトの名無しさん2009/11/18(水) 22:46:27
>>439
4to16ってわかりづらいなー
4byte目から16byte目まで、計16byteをロードしろって意味？
リトルエンディアンじゃないの？
vmadd231psの231もわかんねーなー、なんだそりゃ

つーか、3オペランドで書けるなら、HLSL的な擬似Cコードで十分書けるよね
そっちにして欲しいよ
読みづらくてかなわん
0441,,・´∀｀・,,）っ-○○○2009/11/18(水) 22:52:27
4to16は4つのデータ（この場合128bit）を4回ブロードキャストしろって意味
つまり
abcd abcd abcd abcd

他に、1データを16要素にコピーする {1to16} とか、512ビットそのまんま使う{16to16}（あるいは省略）
てなswizzleモードがある
0442,,・´∀｀・,,）っ-○○○2009/11/18(水) 22:54:16
ちなみにこれ読めばいいと思うよ
http://techresearch.intel.com/articles/Tera-Scale/1514.htm
0443デフォルトの名無しさん2009/11/18(水) 22:59:02
貧乏で過去にも先にも、GPGPU環境なんて組めないから
資料なんか読まねーよウンコたれ野郎が
0444デフォルトの名無しさん2009/11/18(水) 23:04:56
団子さん、すげー･･･
マジ尊敬する。
0445デフォルトの名無しさん2009/11/18(水) 23:16:50
>>439
レジスタ無駄に使っている様に見えるのは
レイテンシからの制限か何かなの？
0446,,・´∀｀・,,）っ-○○○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各要素ごとのベクトルに再パックして
実行したほうがいいかは処理次第。
0447,,・´∀｀・,,）っ-○○○2009/11/19(木) 09:30:33
4要素はこうだな
　vaddps v0, v0, v0{cdab}
　vaddps v0, v0, v0{badc}
0448デフォルトの名無しさん2009/11/19(木) 21:58:52
LarrabeeってSPUみたいに特定命令の組み合わせのみ2並列で実行できるんだよね？
使い物になるの、これ？Cellみたいに大失敗するんじゃないの？
0449デフォルトの名無しさん2009/11/19(木) 22:38:33
第2のIA-64になりそうで怖い
でもアレは当時の需要が小さすぎたのが問題だったから
nVidiaとAMDがスパコン市場でGPGPU分野を作った今なら問題無いか
0450デフォルトの名無しさん2009/11/19(木) 22:57:34
AMDもNVも何もしてない
HPCに貢献したのはIntelとIBMだ
0451デフォルトの名無しさん2009/11/19(木) 23:02:08
>>450
Intelはいつになったら世界一のスパコンに返り咲くんですか
0452デフォルトの名無しさん2009/11/19(木) 23:03:56
お前らそんなこと言ってる間にFermiの実物大カード来たぞ

http://www.4gamer.net/games/099/G009929/20091119001/
0453デフォルトの名無しさん2009/11/19(木) 23:04:35
フレームワークでｇｄｇｄなAMDはGPGPU分野を作ったと言えるのだろうか？？
0454デフォルトの名無しさん2009/11/19(木) 23:09:26
>>453
それでも中国のスパコンに大量納入されて日本国内のスパコン抜いちゃったんだよね…
0455デフォルトの名無しさん2009/11/19(木) 23:17:10
ピーク値を見るとTOP3に入れそうなのに実行効率が悪すぎて5位(´；ω；｀)ﾌﾞﾜｯ

ってかこれでGPGPU分野を作ったって事になるの？
0456デフォルトの名無しさん2009/11/19(木) 23:27:39
これからどんどん増えそう
CPU+GPUシステム
0457デフォルトの名無しさん2009/11/19(木) 23:38:05
>>455
TOP1～4は全部PowerPCかOpteronなんだよね
開発時期的にGPUが前世代の4870X2になるのは仕方無いとして
何でXeonなんかを採用したんだろうｗ
0458デフォルトの名無しさん2009/11/19(木) 23:44:09
もうなりふり構わずAMDを誉めないと気が済まないんだろうな

性能が悪いのはXeonのせい！(ｷﾘｯ
0459,,・´∀｀・,,）っ-○○○2009/11/20(金) 00:22:29
>>457
逆になんでXeonが圧倒的シェアを占める中1～4位がIBM絡みなのか考えてみたら？

20年前くらいのNECの構図と大して変わらんよ。
そのときはまだIBMは攻める側にいたという違いがあるが。
0460デフォルトの名無しさん2009/11/20(金) 00:34:55
CrayっていつIBM陣営になったの…？
0461デフォルトの名無しさん2009/11/20(金) 00:35:36
Intel信者ウゼエよ
実製品が出てから来い
0462デフォルトの名無しさん2009/11/20(金) 00:36:00
Top500がアム厨唯一の希望だからな
0463,,・´∀｀・,,）っ-○○○2009/11/20(金) 00:49:26
ごめん、Crayは別だね


>>462
氷山の一角しか見てないけどな。
0464デフォルトの名無しさん2009/11/20(金) 00:57:50
Top500の結果だけで性能語るのもどうかと思うけど。
0465デフォルトの名無しさん2009/11/20(金) 01:00:33
AMDerに言ってやれ
0466,,・´∀｀・,,）っ-○○○2009/11/20(金) 01:03:13
なんにせよテーマが必要だよな。
「地球シミュレータ」は解りやすい目的があったが、「京速」にはそれがない。

Lucilleの中の人も言ってたけど、レイトレーシングなり一般の消費者にもっと身近な演算を
高速にこなすようなニーズさえあれば10PFLOPSにも意味は出てくる。
明確な用途も無いのにただ速ければなんかの役に立つでしょってのは何の役にも立たない。
0467デフォルトの名無しさん2009/11/20(金) 01:08:42
>>456
10年以上前からそうなってるが・・。
0468,,・´∀｀・,,）っ-○○○2009/11/20(金) 01:13:55
よろしい。ならば重力演算だ。

0469デフォルトの名無しさん2009/11/20(金) 01:17:57
>>466
京速は理研と提携組織のバイオ・物性研究に使う明確な用途があったが…？
0470デフォルトの名無しさん2009/11/20(金) 01:28:43
レンホウにはわかりません
0471デフォルトの名無しさん2009/11/20(金) 01:28:56
>>469
後付けだから。。それ。
0472デフォルトの名無しさん2009/11/20(金) 01:30:23
10年前は、高速な演算をアピールするために動画のエンコードとかがもてはやされたよね･･･
0473デフォルトの名無しさん2009/11/20(金) 01:35:32
>>469
理論値でだけ性能高くてソフトウェア的にガッタガタで使い物にならない未来が目に見えてます
0474,,・´∀｀・,,）っ-○○○2009/11/20(金) 01:42:54
>>469
神戸空港含めポートアイランド二期の経済効果は予想を下回ってるんだよね。
んで、用地が埋まらない神戸市が格安で理研に土地を提供したから京速の設置が
決まったようなもんでそれ以上でもそれ以下でもない。
羽田＋成田のハブ化で神空は関空もろともハブられ化。
現政府の意向と反してるんだよね。

用途も明確にすべきだし、強いて言えば、ポートアイランドである理由も必要。
神戸市が格安で土地提供するから安い？
その神戸市の予算はどこの市県民税・地方交付税で成り立ってるの？的な。

辛くも3期目の当選を果たした矢田立郎神戸市長は民主党推薦ではあるものの
型にはまった元高級官僚。


おっと、これはスパコンスレ向けの話題だな
0475,,・´∀｀・,,）っ-○○○2009/11/20(金) 01:46:21
ごめん、元助役だから高級官僚の犬、が正解。
0476デフォルトの名無しさん2009/11/20(金) 01:48:33
団子さんって何者･･･！？
0477,,・´∀｀・,,）っ-○○○2009/11/20(金) 01:58:39
「首都圏に大震災が来たらチャンス」だとか言っちゃう市長の事業を諸手をあげて支持するのは
どこの理研、というか利権関係者ですか
0478デフォルトの名無しさん2009/11/20(金) 07:37:47
団子25日　AMDいくよね？
0479デフォルトの名無しさん2009/11/20(金) 09:23:30
http://www.hardware-infos.com/news.php?news=3308
実効･･･性能･･･?
0480デフォルトの名無しさん2009/11/20(金) 16:16:38
要約すると
1GHzの24コア(8コア無効化)で実効スループットは417GFLOPS,
瞬間最大実効712GFで、理論最大768GFってこと考えればかなり効率がいい。
1.5GHz程度にクロックアップして1TF達成。

32コアフルに動くのは選別品になるんだろうな。
0481デフォルトの名無しさん2009/11/20(金) 17:02:04
オーバークロックしたときの理論スループットは？
0482デフォルトの名無しさん2009/11/20(金) 17:22:49
1152
0483デフォルトの名無しさん2009/11/20(金) 17:36:15
2wayインオーダーか
P54/54C/55Cの頃は手で並べ替えていたがもうメンドクサイ
0484デフォルトの名無しさん2009/11/20(金) 18:08:02
最適化コンパイラまかせでいいよね。
0485デフォルトの名無しさん2009/11/20(金) 19:32:03
>>474
非国民め！日本が世界一にするために無制限に金をつぎ込むべきだろうが！
お前みたいなサヨクが日本をダメにするんだよ！
0486デフォルトの名無しさん2009/11/20(金) 19:37:21
というか何で京速の開発目的の話をナチュラルに立地の裏事情に摩り替えてるんだ？
京速コンピュータは神戸に決まる数年前から始まっていたプロジェクトだが、
神戸市の誘致前提で始まったプロジェクトとでも思ってんのかね
0487デフォルトの名無しさん2009/11/20(金) 19:39:32
お前らGPUの話しろよ
0488デフォルトの名無しさん2009/11/20(金) 20:01:57
>>436
おっと、その主張はなおさら京速の存在意義を失わせることになるな。
神戸に作ることで医療産業都市構想（京阪神メディカルクラスター構想）
の一端を担うという一応の大義名分が得られる。

神戸空港で国際空港と連絡して世界中の研究者を呼び込める期待されてたんだよね
ふたを開けてみたらあの有様。二期工事の埋め立て地はまだガラガラ。

結論：第２の本状工区。
0489デフォルトの名無しさん2009/11/20(金) 20:12:02
Folding@homeと京速はどっちが速いの？
0490デフォルトの名無しさん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は必要ないと思います。
0491デフォルトの名無しさん2009/11/20(金) 21:22:56
主張するなら理由も書いて。根拠レスじゃ反論不能。
0492デフォルトの名無しさん2009/11/20(金) 22:31:33
>>491
それではGPGPUはCPUがメニーコア化するまでの徒花説について理由を書きます。

プログラマの立場からすると有効利用するのが容易なアーキテクチャが良いです。
言語仕様レベルでマルチコアに対応しているプログラミング言語が増えているので
あとは処理を無数のスレッドや軽量プロセスに分けるようにコーディングするだけで
CPUがシングルコアだろうとメニーコアだろうと有効利用できます。
しかしGPGPUの場合はCPUとGPU間の転送オーバーヘッドが大きいため、
アーキテクチャを意識して粒度を変えないと性能がでません。
どちらの方が有効利用しやすいかは明白です。

いままではCPUが素子の増加をシングルスレッド性能の向上につぎ込んだために
CPUとGPUの演算性能向上ペースに差があり、そのためGPGPUの意義がありました。
しかしCPUがメニーコア化に方針転換したことにより差は消滅すると考えられます。
GPGPUがCPUに対して圧倒的に優れた性能を出せなくなれば、
手間暇かけてGPGPUに対応する意義はなくなると考えます。
0493デフォルトの名無しさん2009/11/20(金) 22:40:37
>>CPUとGPU間の転送オーバーヘッドが大きい
というのは誰もが認識する現状のGPGPUの大きな問題点の一つだが、
誰もが認識しているだけあって、誰もがそこを埋めようとしている。
というかCPUとかGPGPUとか区別するより、両者が
アーキテクチャ的にも物理的な距離的にも
近づいて来ているというのが近いような。
0494デフォルトの名無しさん2009/11/20(金) 22:56:23
そこでSandy、Fusionの登場ってわけだ
0495デフォルトの名無しさん2009/11/20(金) 23:10:52
Fusionに期待！
0496デフォルトの名無しさん2009/11/21(土) 00:02:26
GMAを統合する意味ってあるのだろうか・・・・・・
0497デフォルトの名無しさん2009/11/21(土) 00:07:58
32nmプロセスだとダイ上に統合してもあんま意味無いだろ
22nmでも>>383みたいなのは難しい
Geneseo(PCI-E3.0)みたいなのが間に挟まる
04983542009/11/21(土) 00:19:56
SandyもFusionもGPGPUとしては２流品だぞ
SandyのGPUはオンチップをのせたやつだし、FusionもHD4xxx世代のもの
結構保守的なGPUを乗せてくるらしい
このペースだとGPGPUコアがCPUに統合されるのは１０年先だよ
0499デフォルトの名無しさん2009/11/21(土) 00:21:25
だったらいいな！
05004982009/11/21(土) 00:23:40
名前の354はどっかからの間違いです
0501デフォルトの名無しさん2009/11/21(土) 00:33:24
FusionはHD5xxxシリーズ
LlanoがHD46xxクラス
0502デフォルトの名無しさん2009/11/21(土) 00:33:47
>>498
AMDのFusion→LlanoはDX11対応のHD5ｘｘｘベースでDirectComputeとOpenCL共にReadyだぞ？
0503,,・´∀｀・,,）っ-○○○2009/11/21(土) 01:10:08
>>500
目はたぶん「・」なんじゃね？
0504デフォルトの名無しさん2009/11/21(土) 05:52:33
NVIDIA「このペースだとGPGPUコアがCPUに統合されるのは１０年先だよ」
0505,,・´∀｀・,,）っ-○○○2009/11/21(土) 11:41:35
Llanoは統合じゃなくて「くっつけただけ」だからな。
初期のPentium Dがダイが切り離されてないのと同じようなもの。
キャッシュを共有して協調動作とかすらしない。

その点でSandy Bridgeは面白い
0506デフォルトの名無しさん2009/11/21(土) 12:14:53
BIOSでGPU機能を切るやり方とか誰かが見つけてくれるはず
0507デフォルトの名無しさん2009/11/21(土) 14:37:29
ハードレベルに統合されてるのに外部から切る方法なんてあるのか？
0508デフォルトの名無しさん2009/11/21(土) 17:08:11
はあ？
0509,,・´∀｀・,,）っ-○○○2009/11/21(土) 17:24:59
何で切る必要あるの？
05104982009/11/21(土) 17:46:39
GPGPU向けコアが統合されるのは、もしかしたらDRAMがCPUに統合されるのよりも後かもね
ちなみに、メインメモリのレイテンシが大きいのもアクセス速度が遅いのもCPUとメインメモリが
物理的に離れているのが原因なんだってね
DRAMも内部では1GHzぐらいで動作しているらしいよ
0511デフォルトの名無しさん2009/11/21(土) 18:14:16
良い事考えた。コアごとにローカルメモリを用意してやればいいんじゃね？
0512デフォルトの名無しさん2009/11/21(土) 18:20:05
sandyのGPU部分は不要でしょー
非統合版あればそれを買う
0513デフォルトの名無しさん2009/11/21(土) 18:58:16
NVIDIA「メインメモリの帯域が狭いからCPUはもう伸びしろがない。CPU終焉の時代に向かっている(ｷﾘｯ」
0514デフォルトの名無しさん2009/11/21(土) 19:47:06
ClarkdaleではCPUとGPUではそれぞれ独立したベースクロックを供給されるらしい
BIOSから切ることは簡単だろう
0515,,・´∀｀・,,）っ-○○○2009/11/21(土) 22:11:49
切る必要ないじゃん。

CPUのSIMD性能2倍→相対的にGPGPUの価値半分
0516デフォルトの名無しさん2009/11/21(土) 22:25:49
GMA X3100以下のエクスペリエンスインデックスのclarkdaleに未来はあるのか？
過去の情報だから現状については不明だけど…
0517デフォルトの名無しさん2009/11/22(日) 00:02:06
イミフ
05184982009/11/22(日) 00:23:15
　　 　／￣￣￣＼
　　　　　／　─　 　 ─ ＼
　　　 ／　 <○> 　<○>　 ＼.
　　　 |　　　　（__人__）　　　　| 俺も店に着くなりワゴンに行けって言われたんだけど・・・
　　　 ＼　　　 ｀ ⌒´　　　　／
　　　 ／ 　 　GT 240 　 　 ＼
0519 ◆0uxK91AxII 2009/11/22(日) 04:06:54
GPUのメモリ操作は長く、予想も容易だから、インチキしやすい。
CPUだと難しい。
CPUに統合すると、GPUの性能が落ちそうな予感。

>>510
えっ。
0520デフォルトの名無しさん2009/11/22(日) 09:26:11
プロセッサアーキテクチャの違いなんて意識したくないな.

プログラマがスレッド作ったら, 適当に空いてるプロセッサに

割り当ててほしいんだけど.
0521デフォルトの名無しさん2009/11/22(日) 12:50:05
>>519
オバカ
インチキしたらいけないとあれほど言ったのに
0522デフォルトの名無しさん2009/11/22(日) 14:56:46
プログラマブルシェーダだけでも画期的だったのにさらに負担を増やせというのか
0523デフォルトの名無しさん2009/11/23(月) 00:09:16
AMDのGPGUだと3年後でもせいぜいCPUの3～4倍程度の
速度しかでないけど、Nvidiaなら3年後だと1200倍～3500倍ぐらい
高速になるみたいだけど
0524デフォルトの名無しさん2009/11/23(月) 00:14:51
IntelやAMDの場合は2年後までにCPUにGPUが統合されるから
「3年後のCPU」と比較してGPUはそんなに差が出ない
0525,,・´∀｀・,,）っ-○○○2009/11/23(月) 00:16:30
IBMは結局Cell 32コアは中止らしいな。
必然的に終息ですな。
0526,,・´∀｀・,,）っ-○○○2009/11/23(月) 00:17:11
>>523
笑うしかないわｗｗｗｗ
0527デフォルトの名無しさん2009/11/23(月) 03:02:54
Cellの終焉はGPGPUの未来の姿

Cellの方がはるかに注目を集めて、ゲーム産業でCUDAの数百倍の
プログラマーがプログラムを書いていたのに、まともに応用できなかった

Cellよりも最適化が難しいGPUは、大学の研究者みたいな暇人意外には手が出せないと思う
GPUチャレンジだって変態アルゴリズムを実装してたけど、Cellチャレンジの方は逆に
単純なアルゴリズムだったよね
超変態アーキテクチャ向けにアルゴリズムから設計しないといけないなんて現実的じゃない
0528,,・´∀｀・,,）っ-○○○2009/11/23(月) 03:09:16
GPGPUとか高性能FPGAで解く問題って単純だけど量の多い問題だ
そういう問題に限ってだけ汎用CPUで解くより遙かに効率がいいが
CPUの代わりにはなり得ない。
0529デフォルトの名無しさん2009/11/23(月) 06:56:02
larrabeeもな
0530デフォルトの名無しさん2009/11/23(月) 11:18:15
>>527
> 大学の研究者みたいな暇人
研究だけやってるやつは暇かもしれないが、
最近では研究だけじゃなく授業もできない奴は雇わない方針の大学がほとんどだよ。
そして授業やってると雑務が増えて研究できない。
0531,,・´∀｀・,,）っ-○○○2009/11/23(月) 12:27:59
>>529
GPGPUをLarrabeeと同格に扱いたいならせめてOSが動くレベルになってからにしろよ・・・
というか普通のC/C++が動くようにしろよ
0532デフォルトの名無しさん2009/11/23(月) 12:39:42
GPGPUをC/C++が動くような方向に持っていく事自体が間違い。
もっと高級なレベルでプログラミングさせないと、
最適化のチャンスが減るだけ。
ポインタ見せるのではなくて、配列やリンクリストみたいな
オブジェクトを見せてマップ関数とか呼ばせるようなプログラミングスタイルじゃないと

まあ、そういう意味でもCtのほうが進んでいるのが皮肉っぽいが
0533デフォルトの名無しさん2009/11/23(月) 14:47:40
ブロック図を繋ぐような感じで
0534デフォルトの名無しさん2009/11/23(月) 15:02:53
そこでGoですよ
0535デフォルトの名無しさん2009/11/23(月) 15:42:01
>>518
ﾜﾛﾀｗ
0536デフォルトの名無しさん2009/11/23(月) 17:38:36
matlabでいいじゃん。
0537デフォルトの名無しさん2009/11/23(月) 20:59:01
とりあえずどのくらい高速なのか試してみたいと思っているのですが、
静音性が高くてそこそこ高速なGPUって何がありますか？
0538デフォルトの名無しさん2009/11/23(月) 21:00:42
>>537
Radeon5890 CFがお勧めですね
0539デフォルトの名無しさん2009/11/24(火) 02:14:57
>>527
> プログラマーがプログラムを書いていたのに、まともに応用できなかった
それはもしかしてギャグで言っているのか？
0540,,・´∀｀・,,）っ-○○○2009/11/24(火) 03:34:59
>>532
C/C++が動く意味が解ってないようだが、たとえばCPU用のPOSIXアプリが
コンパイルして動く、と言うレベルでのソース再利用性すら売りになる。

Intelは直接触らせることでの最適化も期待してるからネイティブのSIMD命令を
露出させてるわけで。
まあCtによるハードの抽象化ももちろん期待してるだろうが。
0541デフォルトの名無しさん2009/11/24(火) 19:31:50
>>540
C++が動く意味はもちろん分かっているよ。
でも、GPU陣営がCPUと同じ汎用性を目指すなんて
Intelに真っ向から勝負挑んで勝てるわけ無いじゃない。

あくまで汎用性を制限した特定用途での性能で勝負しないと。
0542デフォルトの名無しさん2009/11/24(火) 19:58:38
例え動いたとしても容易に許可すべきじゃないよなぁ
間違いなくそいつがボトルネックになってそのクソ遅いモジュール
何とかしろよってことになる
0543,,・´∀｀・,,）っ-○○○2009/11/24(火) 22:42:51
そうでもないでしょ。

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

まあ書き直した方が性能出るだろうけどね。
0544デフォルトの名無しさん2009/11/27(金) 21:55:31
Femiが最強らしいね
GrapeDRは罵倒されてひどいらしいし
Radeonは選定対象にもならないそうだw

Radeonってほんとう捏造性能だけで全然だめだよなぁ
0545デフォルトの名無しさん2009/11/27(金) 23:15:05
えっと、GPGPU性能が良いと言いたいんですよね
まずはLarrabeeを圧倒しないとね、モックではなくね
0546デフォルトの名無しさん2009/11/27(金) 23:21:58
AMD君こうゆうのはいけないなぁ

http://developer.amd.com/documentation/articles/pages/OpenCL-and-the-ATI-Stream-v2.0-Beta.aspx
0547デフォルトの名無しさん2009/11/28(土) 00:29:39
わらびーが出てからが本番よね
0548デフォルトの名無しさん2009/12/02(水) 12:40:19
「Larrabeeは実効性能が出ないから糞。俺は最初からこんなもん失敗すると思ってたけどね。Cellの方がまだマシ。」
1～2年後には団子はこんな感じの事を言ってそう。
0549デフォルトの名無しさん2009/12/02(水) 13:35:45
それが団子のいいところ
0550デフォルトの名無しさん2009/12/02(水) 14:03:34
Intelの悪口は言わないと思う。
でもディスクリートには最初から期待していないとか後だしは案の定やってる。
0551,,・´∀｀・,,）っ-○○○2009/12/02(水) 20:03:45
>>548
それは能無しが言うことですね。
精鋭ががんばっても理論値の3割で御の字、そもそも実際のアプリで
理論値をたたき出すことが理論的にありえないどっかのGPUとは違って
積和算にいろんなロード操作をたたみこめるLarrabeeは
いくらでもチューニングのしようがある。

俺の用途だとスクラッチパッドメモリあるいはL1のロード・ストア帯域が
そこそこ必要になるんで、Cellは話にならんしFermiは残念にも程がある。
0552,,・´∀｀・,,）っ-○○○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よりも小回り利かない。
0553,,・´∀｀・,,）っ-○○○2009/12/02(水) 20:58:56
Fermiの場合だと、1ワープ(32スレッド)で2つの行列を処理みたいな
感じになるのかな。
FP積和4回に対してロード1回、ストア1回、あとアドレス算出のために
整数演算１～2回？

データのアラインメントさえしっかりしてればロードネックにならずに
意外とLarrabeeなみの数字出るかもね。
落とし穴さえなければ、の話だけど。
0554デフォルトの名無しさん2009/12/03(木) 01:19:20
1～2年後には「なんでL1に乗らなきゃ速度全く出ない設計にしたのか理解できない。Larrabeeは糞。」って言ってそう。
0555,,・´∀｀・,,）っ-○○○2009/12/03(木) 01:27:32
L2のバンド幅でも余裕でFermiのL1帯域以上出ますが。

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

0556デフォルトの名無しさん2009/12/03(木) 02:12:58
HPC向けなら今でもTeslaやFirestreamが10倍以上の性能出せる分野は結構多いけど、
PC向けでi7の倍～数十倍の性能が出せる用途というのはエンコや編集、圧縮解凍、ウイルスチェック位の認識でいいのかな。
比較対象はi7 920と最近発売もしくは来年予定の2万円程度のGPU。
(HD5770/GTX275/Larrabeeの16コア位)
0557デフォルトの名無しさん2009/12/03(木) 02:20:10
それと、RADEやGefoが苦手(同価格帯のCPUの倍以下、或いは下回る性能)で
Larrabeeが得意(数倍の性能)なジャンルがあれば教えてくれ。
0558,,・´∀｀・,,）っ-○○○2009/12/03(木) 02:31:27
IBMの中の人もLarrabeeは文字列検索なんかが相対的に有用だと言ってるな。
0559デフォルトの名無しさん2009/12/03(木) 02:38:46
なら、遺伝子みたいなパターン検索にも使えそうだな
0560デフォルトの名無しさん2009/12/03(木) 07:30:17
Larrabeeは最強だぜ
なんせIntel様が開発しているんだ
0561デフォルトの名無しさん2009/12/03(木) 08:42:34
Intel様の最強は実は結構少ないんだぜ？
ぶっちゃけ過去10年の成功作はPenM/Core2の2つだけなんだぜ。
IGPは語るだけ無駄
SSDは毎回ファームウェアがアレ
ネットバーストは黒歴史
Nehalemはハイエンドだけをi5とi7、1156と1366で取り合ってるし、
しかも来年互換しない1155/新1366?(DMI2)に変わる。
結局Core2の成功だけで後はパッとしない。
0562デフォルトの名無しさん2009/12/03(木) 08:55:30
勝てばよかろうなのだ
0563デフォルトの名無しさん2009/12/03(木) 09:38:32
妄想アム厨乙

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

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

> Nehalemはハイエンドだけをi5とi7、1156と1366で取り合ってるし、
> しかも来年互換しない1155/新1366?(DMI2)に変わる。
それが功績と何の関係が？
リプレースのコストがかかるのは懐がさびしい人にはきついだろうが
それでもAMDのCPUは売れてない現実
0564デフォルトの名無しさん2009/12/03(木) 09:43:51
Phenom IIはハイエンドの955ですら最弱のCore i5にも勝てない要らない子
0565デフォルトの名無しさん2009/12/03(木) 10:03:11
>寝言はGMAほどのシェアとってからほざけ
性能の事じゃねーの？
0566デフォルトの名無しさん2009/12/03(木) 10:06:15
大衆が買わせるだけの訴求力がない性能なんて無駄
0567デフォルトの名無しさん2009/12/03(木) 10:39:34
全部セロリンでいいな
0568デフォルトの名無しさん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は売れてない現実
圧力とリベート
0569デフォルトの名無しさん2009/12/03(木) 11:26:59
ピンク色の妄想にとりつかれてるな

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

（笑）
0570デフォルトの名無しさん2009/12/03(木) 11:29:42
> ミドル以下は相変わらずCore2まかせが1年続いていて、
> 世代交代やプラットフォームの更新がイマイチ。
> 半年くらいでi7/i5/i3でCore2を更新も出来ない開発力

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

こうですかわかりません＞＜
0571デフォルトの名無しさん2009/12/03(木) 11:32:57
AMDは圧力なんてかけなくても勝手に死んでるんですよ性能悪いから
ダンピングまがいの安売りも焼け石に水

Radeonが好調でも本体のAMDが足引っ張って赤字
ATIが報われなさ過ぎる
0572デフォルトの名無しさん2009/12/03(木) 11:47:38
> モバイルは相変わらずK8コア任せが4年以上続いていて

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

ノートという成長市場を後回しにし続けた結果がこのざま。
0573デフォルトの名無しさん2009/12/03(木) 11:49:12
赤字の主要因は工場じゃねえの？
0574デフォルトの名無しさん2009/12/03(木) 11:55:16
淫照は所詮犯罪行為と圧力で独占的地位にいてシェアを維持しているだけの糞企業だろ。
まともに競争したら、流石に逆転するとは言わないが、その差は7：3か6：4程度で、8：2も差は付かない。
そもそもAMD排斥でDellに60億$とかありえないだろw
6000億円もリベートしないとAMDに勝てないと言ってるようなもの。
勿論HPやNECとかにも規模に応じた多額の排斥リベートしている。
お前らの金が犯罪行為に使われてるんだぜ。
もしかしてIntelは無実で反トラスト法には違反してないとかほざくつもりですか？
0575デフォルトの名無しさん2009/12/03(木) 11:59:00
＞寝言はGMAほどのシェアとってからほざけ

GMAってあれだね金魚の糞みたいなものだし
windows使うと勝手についてくるIEとか見たいなもんだからね
Intel様も早くララビー出してGPUもすごいんだってところ見せて欲しいね
0576デフォルトの名無しさん2009/12/03(木) 12:04:51
CPUは普通物理原価より工場の減価償却費や人件費のほうが高くなる。
大したマーケットも無いのに、200mm²以上のダイを1万円台とか、
コストを考えればあり得ない。

実力拮抗してるメーカーが存在すれば普通はダンピングになるところだが、
Intelを揺るがすほど売れてない上にAMDが自分の首を締めてるだけだから
誰も訴えないだけ。たいした商慣行だよ。
0577デフォルトの名無しさん2009/12/03(木) 12:05:40
AMD厨が大量に釣れてますな
0578デフォルトの名無しさん2009/12/03(木) 12:22:56
一企業だけで6000億のリベートが大したことないですか
揺るがさないならリベートや圧力無しでお願いしますよ淫照さん
0579デフォルトの名無しさん2009/12/03(木) 12:23:12
製造コストと市場規模から考えればPhenom II X4の適正価格は4～5万程度。
今の状況はアブダビからもらった札を同梱して強引に売ってるようなもん。
連結子会社ではなく完全にGFをアブダビに売り払ってファブレス化する
くらいしか健全化の手立てはないだろう。
0580デフォルトの名無しさん2009/12/03(木) 12:25:21
完全に資本関係を絶つという噂もあるな。
絶った直後に大量受注で涙目とかになったりして
0581デフォルトの名無しさん2009/12/03(木) 17:46:55
ハードウェア板か自作板でやれゲハ脳ども
0582デフォルトの名無しさん2009/12/03(木) 17:48:29
圧力とリベート(ｷﾘｯ
0583デフォルトの名無しさん2009/12/03(木) 18:19:36
せっかくのIntelの投資を無駄にして欲しくないですねAMDさん
0584デフォルトの名無しさん2009/12/03(木) 19:49:16
Larrabeeなど我々の中では小物！
http://pc.watch.impress.co.jp/docs/news/20091203_333078.html
0585デフォルトの名無しさん2009/12/03(木) 20:08:21
>>583
和解金を使ってPhenom IIをダンピングする作業が続くお
0586デフォルトの名無しさん2009/12/03(木) 20:56:49
Intelの投資(ｷﾘ
盗人猛々しすぎw
0587デフォルトの名無しさん2009/12/03(木) 20:58:46
>>585
それ以上のダンピングをIntelがするから無意味だぜ
0588デフォルトの名無しさん2009/12/03(木) 21:15:20
アム厨必死だなあ
0589デフォルトの名無しさん2009/12/03(木) 21:51:47
AMDのダンピングは正当行為だ(ｷﾘｯ

って何のスレだっけここ
0590,,・´∀｀・,,）っ-○○○2009/12/03(木) 23:24:16
俺がCUDAをまくスレ
0591デフォルトの名無しさん2009/12/03(木) 23:57:08
CUDAらねー
0592デフォルトの名無しさん2009/12/04(金) 00:36:26
AMDってEUに不当廉売で排除されそうなんだけど
0593,,・´∀｀・,,）っ-○○○2009/12/04(金) 00:45:32
昨日の味方は今日の敵
0594デフォルトの名無しさん2009/12/04(金) 02:30:48
ダンピング：不当に安い価格で商品を販売すること。
赤字で潰れそうなAMDが出来るわけないだろJK
基本的に強者が弱者を排除するための行為だからな

そろそろ淫厨vsアム厨は下記スレででもやってくれ
http://pc11.2ch.net/test/read.cgi/jisaku/1257308022/
0595デフォルトの名無しさん2009/12/04(金) 02:34:29
アム厨まだ粘ってるのか
0596デフォルトの名無しさん2009/12/04(金) 04:15:20
>>594
残念、クアッドコアが1万円台などの破格の価格設定の結果として
大幅な赤字が出てるわけで、製造コストに見合った価格設定でないと
それはEUの定めるところの不当廉売の排除対象になりうることがある。

競争はIntelとだけやってると思ってるだろ？違うんだよな。
x86しか見てないからそう思うだけだ。
0597デフォルトの名無しさん2009/12/04(金) 05:55:12
>>596
60億$のリベートしちゃったIntelが真っ先に提訴されてるけどね。
ほとんどタダ同然の多額のリベートは明らかに不当廉売。
違うにしても、正常な競争の範囲じゃないことは明らか。
ちなみに市場の低価格は、相対的な性能やブランド、需要差にもよるから仕方ない部分もあるね。

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

そういうのがCPUに比べ少ないGPU/GPGPUの競争は、つまらん足の引っ張り合いはせずに、
製品とソリューションでの殴り合いのガチンコ競争でお願いしたいところ。
0598デフォルトの名無しさん2009/12/04(金) 08:34:06
赤字＝原価割れ　ではないと思うけど
0599デフォルトの名無しさん2009/12/04(金) 10:15:31
なんかデジャブ感があるな。
0600デフォルトの名無しさん2009/12/04(金) 10:33:11
人件費・減価償却費を回収できない価格設定にするのはおかしいだろう。
0601デフォルトの名無しさん2009/12/04(金) 10:37:19
アホ乙
0602デフォルトの名無しさん2009/12/04(金) 10:46:04
まあ価格上げたらますます売れないけど
0603デフォルトの名無しさん2009/12/04(金) 12:48:59
>>584
>同社ではSCCを第2世代のメニイコアプロセッサとして位置付けている(第1世代はLarrabee)。
>現在、IntelとHP、Yahoo!による「Open Cirrus」コラボレーションの研究者は、
>クラウドアプリケーションを、データ集約型のJAVAソフトウェアフレームワークである
>Hadoopを使い移植を進めている。

Intel自身もGPGPUは通過点に過ぎず、メニーコアが理想解だと考えているのですね。
Apache HadoopがSCCをサポートするなら、ソフトウェアをHadoopに対応させるだけで
メニーコアにもグリッドコンピューティングにも対応済みとなり、大変ありがたいです。
0604デフォルトの名無しさん2009/12/04(金) 12:53:04
LarrabeeはGMAの置き換え＆HPC用アクセラレータであって
アプリケーション用プロセッサではない。

>同社ではSCCを第2世代のメニイコアプロセッサとして位置付けている(第1世代はLarrabee)。
あとこれは嘘。第一世代は80コアのプロトタイプのPolaris。
いまだにPolarisとLarrabeeの区別のつかないアホ記者がいるのはうんざりする。
0605デフォルトの名無しさん2009/12/04(金) 13:18:51
SCCのダイ写真からすると1コアがかなり小さいから、
Larrabeeのようなベクタユニットもってないだろうしな。
0606デフォルトの名無しさん2009/12/05(土) 02:19:35
>>552
団子さんに聞きたいのだが、Ｌａｒｒａｂｅｅって2GHzくらいで動くんでしょ。
仮にCellが進歩していたとして、4.5GHz位だったとして、どっちの方が速くなるの？
今Cellは3.2GHzで、Larrabeeを2GHzと仮定したら、Cell1サイクルに対してLarrabeeは1.6サイクルになる。
命令数とトータルのサイクル数は違うように思えるんだけど、どうなんだろう？
0607デフォルトの名無しさん2009/12/05(土) 03:35:12
何をさせるかによるだろｗ
0608デフォルトの名無しさん2009/12/05(土) 04:19:02
GHz馬鹿ってまだ居たんだな
0609デフォルトの名無しさん2009/12/05(土) 09:29:15
>>606
Larrabeeは命令で消費サイクル大幅に変わるから何倍も遅くなる。
0610デフォルトの名無しさん2009/12/05(土) 12:19:00
> 消費サイクル大幅に変わるから何倍も遅くなる
逆にいえば何倍も早くなることもあるのね
0611,,・´∀｀・,,）っ-○○○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的にシャッフルユニットと積和で別々のユニットになってる方式よりもレイテンシの面で有利。

0612,,・´∀｀・,,）っ-○○○2009/12/05(土) 13:26:12
とか書いているうちにディスクリートGPU版のキャンセルが報じられたようです
0613デフォルトの名無しさん2009/12/05(土) 13:30:27
４G越えは無理だろう。Cellは。
0614,,・´∀｀・,,）っ-○○○2009/12/05(土) 13:34:08
HPC向け製品が棚上げになったCell
コンシューマ向けが棚上げになったLarrabee

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


俺はしばらくNVIDIAの顔色伺っておくか。
0615デフォルトの名無しさん2009/12/05(土) 13:47:11
http://www.geocities.jp/andosprocinfo/wadai09/20091205.htm
0616デフォルトの名無しさん2009/12/05(土) 13:53:55
>>614
NVidiaお終いだろ
Intelと同様にAMDに多額の金支払わないと
独禁法で排除されそうだぞ
0617デフォルトの名無しさん2009/12/05(土) 16:01:37
Phenomの廉売による損失補填費をNVIDIAが負担ですね。わかります。
0618デフォルトの名無しさん2009/12/05(土) 16:47:01
NVIDIAって訴えられるほど儲かってんの？
なんか定期的に赤字のニュースを見るような
0619デフォルトの名無しさん2009/12/05(土) 17:21:38
ありゃま。
安く遊ぶには当分CUDAと付き合わざるを得ないな。
0620,,・´∀｀・,,）っ-○○○2009/12/05(土) 17:25:40
CPU側の進化に任せるって手もあるけどね。
文字列探索みたいな1バイト単位のオペレーションならSSE*にまだまだ優位性がある。
0621デフォルトの名無しさん2009/12/06(日) 09:44:05
トリップ検索？
0622,,・´∀｀・,,）っ-○○○2009/12/06(日) 11:52:23
普通にBLASTとかその他テキスト全文検索
0623デフォルトの名無しさん2009/12/06(日) 12:23:25
団子てめぇトリつけろ
ATI Streamで解析してやんよ
0624,,・´∀｀・,,）っ-○○○ ◆/tise/KisQ 2009/12/06(日) 12:35:46
そういえばこんなネタ鳥あったな
0625,,・´∀｀・,,）っ-○○○ ◆xvt3t9gVzFz9 2009/12/06(日) 12:36:55
これ解析して
0626デフォルトの名無しさん2009/12/07(月) 20:41:21
Intel、Larrabeeグラフィックスチップの計画を破棄
http://www.itmedia.co.jp/news/articles/0912/07/news041.html

さようならLarrabee
こんにちはSCC
0627デフォルトの名無しさん2009/12/07(月) 22:22:58
ぼくちゃんの最強プロセッサを考えてみたはいいが、大風呂敷だったって事だよな。
ただ最終的にはLarrabeeのような方向にシフトしていくのは間違いないだろう。

だがそれにしても団子は痛い。
他の団子のレスは大体いいと思うが
>>89-90,95,98,101,156とかはブーメラン過ぎる。
出てもいないもので比べるなとあれほど(ry
0628デフォルトの名無しさん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の区別のつかないアホ記者がいるのはうんざりする。
見事なブーメランです。
0629デフォルトの名無しさん2009/12/07(月) 23:32:37
ええぇぇぇえええ
0630デフォルトの名無しさん2009/12/07(月) 23:39:38
Intelオフィシャルもみない情弱ワロタｗｗｗ
0631デフォルトの名無しさん2009/12/07(月) 23:40:20
しかも見事なブーメランとか勝ち誇ってるのが痛々しいｗｗｗｗｗｗ
0632,,・´∀｀・,,）っ-○○○2009/12/07(月) 23:45:49
SCC発表のPDF読めよ。
ああそうか英語読めないからバイトの中国人のこと真に受けるのか
0633・´ω｀・）・´ω｀・,,）*・´ω｀・）っ-○○○2009/12/08(火) 00:07:56
いずれにせよ当分NVIDIAに寝返るわ（・´ω｀・）
0634デフォルトの名無しさん2009/12/08(火) 01:03:06
　　　　　　ﾊ,,ﾊ
　　　　　（ ﾟωﾟ )　　お断りします
　　　　／　　 　＼
　 ((⊂ 　） 　 ﾉ＼つ))
　　　　　（＿⌒ヽ
　　　　　　ヽ　ﾍ　}
　ε≡Ξ　ﾉノ ｀J
0635・´ω｀・）・´ω｀・,,）*・´ω｀・）っ-○○○2009/12/08(火) 01:08:51
（・´ω｀・）
06366282009/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世代という表現は報道側から出てきたように見えます。
0637デフォルトの名無しさん2009/12/08(火) 03:26:55
うぜえ
0638デフォルトの名無しさん2009/12/08(火) 09:08:45
ブーメランｗｗｗ
0639デフォルトの名無しさん2009/12/09(水) 00:46:38
団子の自殺ﾏﾀﾞｰ？
0640デフォルトの名無しさん2009/12/09(水) 01:04:51
だれか、Larrabee発表からキャンセルまでの団子の奇跡をまとめてサイト
つくってくれないかな。
0641デフォルトの名無しさん2009/12/09(水) 03:01:04
信じられない話ってLの件ですか？

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

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

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


大原もLarrabeeが商品化なんてことは信じられなかったとか言ってるぞｗ
0642,,・´∀｀・,,）っ-○○○2009/12/09(水) 03:23:06
Ctのβ来たね
0643デフォルトの名無しさん2009/12/09(水) 03:34:47
Ctはロードマップどおりか
0644デフォルトの名無しさん2009/12/09(水) 07:38:49
なんつーか

これはひどい
0645デフォルトの名無しさん2009/12/09(水) 10:12:15
CELLのときみたいに
団子のIntel叩きがはじまるかな?
0646,,・´∀｀・,,）っ-○○○2009/12/09(水) 12:58:52
別の遊び道具を用意してくれたので別に叩く理由はない
0647デフォルトの名無しさん2009/12/09(水) 19:47:29
そして第2弾計画発表
http://www.pcgameshardware.com/aid,701071/Larrabee-2-is-still-possible/News/
0648デフォルトの名無しさん2009/12/09(水) 20:57:16
>>647
P5前提じゃあ周波数あげるか数を増やすかキャッシュメモリを増やすかしかないと思うけど、どうやるんだ？
0649デフォルトの名無しさん2009/12/09(水) 21:11:38
32nm
0650デフォルトの名無しさん2009/12/10(木) 15:08:33
狼少年
0651デフォルトの名無しさん2009/12/10(木) 23:45:34
2009/12/10 GPUコンピューティングの現状とスーパーコンピューティングの未来
http://www.slideshare.net/pfi/20091210-gpu
0652デフォルトの名無しさん2009/12/11(金) 03:50:37
こうやって宣伝して人を錯覚させていくんだなぁ。
0653デフォルトの名無しさん2009/12/11(金) 05:20:13
緑のGPUの写真はモックアップで遅れまくり、青いのは失敗でキャンセル。
今頃ショックで引き篭もってんじゃないかな。
0654デフォルトの名無しさん2009/12/11(金) 12:20:27
>>652
いろんな思惑がある人が宣伝するから、結果的に平均値に収まる。
0655デフォルトの名無しさん2009/12/11(金) 13:02:29
緑もキャンセルしたら笑えるな
0656デフォルトの名無しさん2009/12/11(金) 14:21:51
>>651
＞青のGPU

VIA?

なんかOpenCLにも対応するらしいしな。
ttp://pc.watch.impress.co.jp/docs/news/20091211_335237.html
0657デフォルトの名無しさん2009/12/11(金) 15:42:43
Larrabeだろ明らかに
0658デフォルトの名無しさん2009/12/11(金) 22:30:39
実はchrome400/500がcpu技術を用いられて開発された最初のgpuだったりする
0659デフォルトの名無しさん2009/12/11(金) 22:40:20
いらねーよ、お絵かきには
0660デフォルトの名無しさん2009/12/11(金) 23:09:05
>>658
あやまれ！renditionにあやまれ！（AAｒｙ
0661デフォルトの名無しさん2009/12/11(金) 23:12:21
最近でたGPGPUベンチの名前って何だっけ
0662デフォルトの名無しさん2009/12/12(土) 00:44:18
VIA始まった。
この調子でがんばって･･･なの。
0663デフォルトの名無しさん2009/12/12(土) 02:56:32
アジア諸国vs全世界
核使わないならアジアが圧倒的有利だな
0664デフォルトの名無しさん2009/12/12(土) 04:35:23
食糧難で終わるかもしれんぞ
0665デフォルトの名無しさん2009/12/12(土) 10:05:59
じゃあ戦略シミュレーションをGPGPUしてみろよ。
0666デフォルトの名無しさん2009/12/12(土) 16:54:39
IntelのNvidaの買収確定だな
0667,,・´∀｀・,,）っ-○○○2009/12/12(土) 16:55:19
ソウスだせ
0668デフォルトの名無しさん2009/12/12(土) 16:59:04
Nvidaってどこの会社ですか？
0669,,・´∀｀・,,）っ-○○○2009/12/12(土) 16:59:56
Nidaってど（ｒｙ
0670デフォルトの名無しさん2009/12/12(土) 17:17:33
ロバート・クリングリーが犯人のようだな
0671,,・´∀｀・,,）っ-○○○2009/12/12(土) 17:22:58
ああ、それは日本文化研究してる韓国大学教授なみには説得力あるな
0672デフォルトの名無しさん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
0673デフォルトの名無しさん2009/12/15(火) 21:53:00
Kaspersky enlists CUDA to kill viruses
ttp://www.fudzilla.com/content/view/16849/38/
0674デフォルトの名無しさん2009/12/15(火) 22:45:30
>>672
PhotoshopやFlashで嘘ついて恥をかいたのをまた繰り返すみたいだな
0675デフォルトの名無しさん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
0676デフォルトの名無しさん2009/12/17(木) 20:23:23
すごい商習慣だな
0677デフォルトの名無しさん2009/12/17(木) 20:25:20
アメリカではよくあること
0678デフォルトの名無しさん2009/12/17(木) 22:19:23
Intelは世界中で悪の組織扱い
MSですら非を認めて各ブラウザに配慮しているのに

しかしIntelの反論が小沢や亀井みたいに尊大で往生際が悪くて笑える。
ttp://enterprise.watch.impress.co.jp/docs/news/20091217_336454.html
0679デフォルトの名無しさん2009/12/17(木) 23:29:58
もうORNLスパコンにHD5xxxをぶち込めば
0680デフォルトの名無しさん2009/12/18(金) 00:23:02
FOXC最高～
0681デフォルトの名無しさん2009/12/18(金) 01:08:06
アメリカ自体がintelの味方だから・・。
0682デフォルトの名無しさん2009/12/18(金) 02:05:45
IntelもAMDもNVIDIAもBig Blueもアメリカ企業だから、潰し合いしたところで結局内部抗争なんだよね。
半導体産業を韓臺にもぎ取られてヒイヒイいってる日本とは次元が違う。
0683デフォルトの名無しさん2009/12/18(金) 02:44:29
AMDはもう油でしょ
0684デフォルトの名無しさん2009/12/18(金) 12:40:28
韓国は大嫌い
0685デフォルトの名無しさん2009/12/21(月) 00:18:46
お前ら板間違えてね？ｗｗｗ
0686デフォルトの名無しさん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
0687デフォルトの名無しさん2009/12/22(火) 06:13:36
ATI Stream対応C++言語コンパイラ登場(CUDAも)
ttp://pc.watch.impress.co.jp/docs/news/20091221_338330.html
0688デフォルトの名無しさん2009/12/22(火) 08:39:15
過疎ﾜﾛﾀ
↓燃料投下
ttp://www.kfcr.jp/goose.html
0689デフォルトの名無しさん2009/12/22(火) 13:04:21
そのコンパイラーだと、Atiのほうが早いのか。
HD4850のほうがGTX280より早いってのがね。

てか、これでOpenCLがいらなくなったんじゃね？
0690デフォルトの名無しさん2009/12/22(火) 13:38:00
対応ツールなんか１種類でいいから手放せないぐらい便利に
なるもの作りゃいいのに。
0691デフォルトの名無しさん2009/12/22(火) 17:23:10
汎用品は便利だけど速度は出ないんだろうな。
0692デフォルトの名無しさん2009/12/22(火) 20:14:37
>>688
GTX280　1.47
HD4850　3.44

GeForce遅い
GPGPUに特化したんじゃなかったのか
0693デフォルトの名無しさん2009/12/22(火) 21:23:40
http://www.amazon.co.jp/exec/obidos/ASIN/484432814X/masafumislabo-22/
0694デフォルトの名無しさん2009/12/22(火) 21:50:47
はいはいワロスワロスｗ

168 ：Socket774 [↓] ：2009/12/21(月) 22:13:41 ID:X38nbLUj
GTX280の倍精度は理論値でも77.82gflops
4850は200gflopsか
0695デフォルトの名無しさん2009/12/22(火) 22:02:57
転載するのは構わんが、アフィは外してやれよ
0696デフォルトの名無しさん2009/12/22(火) 23:02:27
>>692
CUDAの最適化が甘いんだろきっと。
単精度でそんな遅いはずがない。
0697デフォルトの名無しさん2009/12/22(火) 23:20:19
おまえわざとか
0698デフォルトの名無しさん2009/12/23(水) 00:08:07
いくらめんどくさいからってリンク先の内容を読んでからレスしてくださいよ
0699デフォルトの名無しさん2009/12/23(水) 00:50:58
単精度で動かしたデータ見てみたいな。
0700デフォルトの名無しさん2009/12/23(水) 01:27:29
明日はイブですよ。
皆さんの恋人はGPUですか？
0701,,・´∀｀・,,）っ-○○○2009/12/23(水) 02:05:11
ほんじつは

へいかの

たんじょうびです

みなさまの

へいわを

いのります
0702デフォルトの名無しさん2009/12/23(水) 08:52:08
ほ

へ

た

み

へ

い

おまえにはがっかりだよ
0703デフォルトの名無しさん2009/12/23(水) 21:04:57
>>702
俺も702を読む前に1～2分考えてがっかりした。
時間返せw
0704デフォルトの名無しさん2009/12/23(水) 21:52:17
>>703
ヒントよろ
0705デフォルトの名無しさん2009/12/24(木) 01:51:37
なんのことだかさっぱり・・・
0706デフォルトの名無しさん2009/12/24(木) 22:21:07
コンパイラでただけでこうも過疎るとは
0707,,・´∀｀・,,）っ-○○○2009/12/24(木) 23:11:34
ヒント：クリスマス
0708デフォルトの名無しさん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
0709デフォルトの名無しさん2009/12/25(金) 09:40:33
>>708
お前馬鹿だな
今更旧世代のHD48xxシリーズを検証した記事持ってきてどうするんだ
今論じるべきは今後主流になる最新のHD5xxxシリーズの性能だろ
0710デフォルトの名無しさん2009/12/25(金) 10:59:35
まあしかし既存のユーザーは問題にするだろ。
大量に使ってるところなんかは簡単に買い換えられないだろうしさ。
0711デフォルトの名無しさん2009/12/25(金) 13:13:35
DX11に対応した固定機能以外は、ただのHD4kのSP2倍、メモリ帯域1.2倍でしかないので
HD4kがダメなら当然5kもダメ
0712デフォルトの名無しさん2009/12/25(金) 13:59:18
そのほかに4倍増しの部分があったりする
0713デフォルトの名無しさん2009/12/25(金) 15:52:34
>>711
HD4xxxのLDSは実質使えないから、
ローカルがグローバル状態なのがまずいんじゃないの？
0714デフォルトの名無しさん2009/12/25(金) 19:19:22
DirectComputeのcs4.1なら使えるんだけどな。
OpenCLの仕様ではコード上のshared領域と
LDSのmappingが難しい。
0715デフォルトの名無しさん2009/12/26(土) 04:16:59
EvergreenのISAドキュメント出たけど、結構変わったんだな。
0716デフォルトの名無しさん2009/12/26(土) 04:35:59
ATI Stream SDK v2.0 Documentation
http://developer.amd.com/gpu/ATIStreamSDK/pages/Documentation.aspx
0717デフォルトの名無しさん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が完了する。
物凄い用途を絞った命令だ。
0718,,・´∀｀・,,）っ-○○○2009/12/26(土) 10:04:12
何を今更
SSEやCellに実装されてるSADも元々8ビット単位の絶対差の和だよ。
0719デフォルトの名無しさん2009/12/26(土) 10:11:42
いや、SIMD>VLIWの中にさらにSIMD命令を入れちゃったのが勘所
0720,,・´∀｀・,,）っ-○○○2009/12/26(土) 10:30:25
たしかに変態だな
0721デフォルトの名無しさん2009/12/26(土) 13:38:32
結局、Larrabeeなんて出ねーよと言っていた連中が正しかったか
団子も途中から悟ったのか、Larrabeeの時代がくるっていってのをやめて
nVidia批判に切り替えてたからな
0722デフォルトの名無しさん2009/12/26(土) 14:04:04
もう次のRADEONは演算単位を8bit整数にして実数はバイトシリアルで
処理すればいいんじゃないかｗ
0723,,・´∀｀・,,）っ-○○○2009/12/26(土) 14:08:26
>>721
ﾌﾟｯ


>>722
どのみちFusionでSSEユニットとの統合を実現するにはバイト単位のオペレーションは必須
0724デフォルトの名無しさん2009/12/26(土) 14:12:23
団子も赤っ恥掻いて言い返せなくなったみたいだなｗ
0725デフォルトの名無しさん2009/12/26(土) 14:15:00
大丈夫、団子なら何食わぬ顔でLarrabee2の時代が来るって言い始める。
0726デフォルトの名無しさん2009/12/26(土) 14:52:37
暇な奴らだな
0727,,・´∀｀・,,）っ-○○○2009/12/26(土) 14:54:47
ﾆﾔﾆﾔ
0728,,・´∀｀・,,）っ-○○○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に勝てないと結論付けています。
0729,,・´∀｀・,,）っ-○○○2009/12/26(土) 23:16:01
Intelが敢えてLarrabeeキャンセルした理由がようやくわかったね
0730デフォルトの名無しさん2009/12/26(土) 23:32:54
なんだ
S3の独壇場じゃないかGPUは
いつ追いつけるんだ、お前らは
0731デフォルトの名無しさん2009/12/26(土) 23:55:01
IntelがS3を買収・投資すればすぐにGPGPU(APU)時代が来るな
0732,,・´∀｀・,,）っ-○○○2009/12/26(土) 23:59:08
むしろNanoと統合して頑張ってくれ
0733デフォルトの名無しさん2009/12/27(日) 00:01:03
逆にいえば、300W枠をギリギリまで使いきっても許されるGeforceのハイエンドなら
512SPのまま出るんじゃないの
0734デフォルトの名無しさん2009/12/27(日) 00:06:38
歩留まりも悪かったのでは
0735デフォルトの名無しさん2009/12/27(日) 00:28:59
電力は言い訳で歩留りだろうな
1割切るって予測だったし
0736,,・´∀｀・,,）っ-○○○2009/12/27(日) 00:38:07
HPC向けにまで2シェーダ落ちを使わなければならないほどだから
GPUとしての競争力は（ｒｙ
0737デフォルトの名無しさん2009/12/27(日) 00:40:45
>>729
> Intelが敢えてLarrabeeキャンセルした理由がようやくわかったね
>
ララビーキャンセルはラデオンに3D性能で勝てないことと、ドライバが糞で、開発環境も整っていないからだが。
サンプルすら存在せず比較も出来ないFermiなんか、要因の一つでしかない。
0738デフォルトの名無しさん2009/12/27(日) 00:52:08
なんだかんだ言っても結局CUDA一択なんですけどね
0739,,・´∀｀・,,）っ-○○○2009/12/27(日) 01:08:15
Radeon向けのコードでも書くとするか
0740,,・´∀｀・,,）っ-○○○2009/12/27(日) 02:13:41
おまいらこれ応募した？
http://www.makebettercode.com/scc_software_research/form.php
0741デフォルトの名無しさん2009/12/27(日) 07:52:34
>>730-732
VIAの場合別に技術リーダーになるつもりはないので
CPUとの統合なんてのは、今後数年先にもやりはしない
逆に費やすトランジスタに対して、効果の大きい改良は施す

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

VIAが32nm使うまでにIntelが命令普及させてれば、そのときは統合するかもね
いやぁAVXなGPU作っちゃうかもしれないけど
0742,,・´∀｀・,,）っ-○○○2009/12/27(日) 21:14:33
VIA（というかCentaur）ってSSEの型変換の特許持ってるから比較的有利な条件でx86ライセンス使えるんだっけな
0743デフォルトの名無しさん2009/12/27(日) 21:27:47
少人数集団Centaurヤバス
0744デフォルトの名無しさん2009/12/27(日) 21:34:18
armフリー＆x86フリーの環境で生きたい。
むしろSPARC
0745デフォルトの名無しさん2009/12/28(月) 12:47:31
富士通社員乙
0746デフォルトの名無しさん2009/12/29(火) 00:01:29
兄貴退社でRadeonはGPGPUから脱落したぞ
0747デフォルトの名無しさん2009/12/29(火) 00:31:57
DQN風貌で、聞き取りづらい発音で淡々と喋るだけだったんでクビにして良かったと思う
AMDのイメージダウンだよあの男は
0748デフォルトの名無しさん2009/12/29(火) 01:04:15
アニキはCore i7ユーザーになったみたい
0749デフォルトの名無しさん2009/12/29(火) 01:17:49
開発者じゃないし。。
0750デフォルトの名無しさん2009/12/29(火) 07:59:15
兄貴はAMDの開発、宣伝の中心人物だったのか・・・
0751デフォルトの名無しさん2009/12/29(火) 15:02:00
辞めた途端土井のあんちゃん叩くとか最低だよな
0752,,・´∀｀・,,）っ-○○○2009/12/29(火) 15:17:28
そりゃ「Core i7のマシン組みます」なんて円満退社の人間が言うことじゃないし

0753デフォルトの名無しさん2009/12/29(火) 17:07:12
Pat Gelsingerは円満退社(笑)
0754デフォルトの名無しさん2009/12/29(火) 17:31:33
あれはワロタなｗ
何したんだ日本AMDｗｗｗｗ
0755,,・´∀｀・,,）っ-○○○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の親会社
0756デフォルトの名無しさん2009/12/29(火) 17:47:31
1/22のOpenCLの本
糞本っぽいなぁ
0757デフォルトの名無しさん2009/12/29(火) 18:08:09
>>755
UMCはファウンドリだろJK
しかも日付的にPatGelsinger関係ないし
0758,,・´∀｀・,,）っ-○○○2009/12/29(火) 18:09:36
ごめん寝ぼけてたEMC
0759デフォルトの名無しさん2009/12/29(火) 18:13:49
この前の「はじめてのCUDAプログラミング」も糞本を通り越して
よくこれで出版したなという出来だったし、競争の無い分野の
和書入門書はほんと酷いもんだ。
0760,,・´∀｀・,,）っ-○○○2009/12/29(火) 18:15:42
http://www.internetnews.com/infra/article.php/3846461/Intel+EMC+Team+on+More+Efficient+Cloud+Storage.htm
これでいいかな？

ゲルたんは良い椅子貰ったな
0761,,・´∀｀・,,）っ-○○○2009/12/29(火) 18:24:28
ゲルたんと同時期に退職したBruce Sewellも9月15日付けでApple法務顧問。
パートナー企業との根回しのために幹部移籍させるなんてよくあることじゃん。
なんでもかんでも懲戒処分にしちゃうのは浅はかなんじゃない？

土居ちゃんなんてまだ就職先決まってないんだし。
0762デフォルトの名無しさん2009/12/29(火) 18:31:20
円満退社じゃない＝懲戒
とは誰も言ってないけどね

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

まあEMCへの移籍はGelsingerにとってはキャリアアップには繋がるだろうけど
引き抜きって言われるのもその辺が所以だろう
0763,,・´∀｀・,,）っ-○○○2009/12/29(火) 18:39:36
まあ根回しの状況証拠もあるわけだし
Larrabeeは天野さんも言ってるが長期的な計画だし
0764デフォルトの名無しさん2009/12/29(火) 18:49:20
NVIDIA、「Fermi」の第1弾製品の開発を中止

NVIDIAは米国時間の2009年12月28日、「Fermi」の開発コード名で呼ばれていた、外付けグラフィックス製品の開発中止を明らかにした。
当初は2009年末から2010年にかけて出荷する予定だった。
プロジェクト自体は継続する。外付けグラフィックスチップに関する新たな計画は2010年に改めて公開する。
0765デフォルトの名無しさん2009/12/29(火) 19:28:36
>>762
IntelのCEO狙えるって言っても次の次のくらいの話でしかも本命馬じゃなかったからな
0766デフォルトの名無しさん2009/12/29(火) 19:37:42
土井氏ってIntelの人間でしょ
情報筒抜けになったのバレたから
この解雇劇でしょ
0767デフォルトの名無しさん2009/12/29(火) 19:43:57
なんでAMD厨って>>766みたいな電波ばっかしなの？

0768デフォルトの名無しさん2009/12/29(火) 19:49:03
>>759
ああ、あれはひどかったな。
0769デフォルトの名無しさん2009/12/29(火) 20:38:21
外資ではよくあること、らしいが･･･
0770デフォルトの名無しさん2009/12/29(火) 21:48:10
>>768
そうか？
入門書だぞ？
0771デフォルトの名無しさん2009/12/29(火) 22:46:21
入門者や初心者を容赦無く苛め抜くのが日本のプログラマーの特徴ですから
0772デフォルトの名無しさん2009/12/30(水) 00:26:04
>>770
本当に読んだ？あれ、初心者に紹介する気になる？
あのタイトルであの内容は絶対にあり得ん。
少なくとも英語圏では編集者があのまんま出版させることはしないよ。
書籍としての構成になって全くなっておらず、blogに書き散らしたのを
そのまま印刷したような作りだ、あれじゃ。
0773デフォルトの名無しさん2009/12/30(水) 04:50:32
同業者向けの入門でしょ。なのであれで十分だな。
英語圏ではってのが視野が狭いというか短絡的だけど、
ただお前が分からなかった、ってだけの事だな。
0774デフォルトの名無しさん2009/12/30(水) 09:21:37
世の中にはびっくりするぐらい技術レベルの低い人間が
びっくりするぐらい低コストで劣悪な入門書を書く事がある
そういうのは大概すぐ消えるが、よくわかっていない初心者が
間違えて買ってしまうだけでも元が取れたりする
>>759 もそういう類の本。まともな人間なら一笑に付す内容
同じ枚数の便所紙の方がまだ役に立つ
0775デフォルトの名無しさん2009/12/30(水) 10:41:31
やべ、買っちゃった
0776デフォルトの名無しさん2009/12/30(水) 12:48:01
>>774
どうせ
技術(プログラミング)は自信あるが、数学がわからないとかじゃないの？
後半の例がわからなかったんだろ
0777デフォルトの名無しさん2009/12/30(水) 13:20:27
>>776
後半の数式と説明に矛盾あるし
余計混乱させるだけの糞本じゃねーかw
0778デフォルトの名無しさん2009/12/30(水) 14:07:14
著者乙って言えばいいのかこれは
0779デフォルトの名無しさん2009/12/30(水) 15:36:08
別に悪い本とは思わないけど、若干まとまりがなかったのも事実だな
まあ簡単な初歩＋TSUBAMEでやってる計算の紹介と思えば悪くない
0780,,・´∀｀・,,）っ-○○○ 【だん吉】 2010/01/01(金) 13:27:05
　　　　　今年のGPGPU市場↑
0781デフォルトの名無しさん2010/01/01(金) 16:23:55
だんごのだん吉吹いた
0782 【小吉】 【699円】 2010/01/01(金) 17:09:28
test
0783デフォルトの名無しさん2010/01/02(土) 16:57:56
団子は的には興味ないの？
0784,,・´∀｀・,,）っ-○○○2010/01/03(日) 16:29:58
林檎飴とかおみくじとか売る商売のこと？
無いよ。
0785デフォルトの名無しさん2010/01/03(日) 21:37:55
団子てめぇ俺がマジレスするのを待ってやがるな
0786,,・´∀｀・,,）っ-○○○2010/01/06(水) 02:30:13
なんだ他に言いたいことがあるなら言って良いぜ？
0787デフォルトの名無しさん2010/01/06(水) 07:30:27
今年こそは童貞卒業したいです！
0788,,・´∀｀・,,）っ-○○○2010/01/06(水) 23:35:03
俺ですら腐女子だけど相方がいるのにおまいらときたら
0789デフォルトの名無しさん2010/01/07(木) 00:19:31
それって肉風船？それともメガネブス？
0790デフォルトの名無しさん2010/01/07(木) 00:21:44
自慢してるの？死ぬの？
0791デフォルトの名無しさん2010/01/08(金) 21:53:50
>788
gpgpuで腐女子人格を再現したの？
0792,,・´∀｀・,,）っ-○○○2010/01/10(日) 23:56:34
再現するもなにも俺は元々女の腐ったような精根だが？
0793デフォルトの名無しさん2010/01/11(月) 02:30:35
とーみーこー
0794デフォルトの名無しさん2010/01/11(月) 10:10:48
腐女子に失礼だろ！
0795デフォルトの名無しさん2010/01/11(月) 11:05:36
GPUボードの箱に描かれてる女のことを言ってるんだよ
0796 ◆0uxK91AxII 2010/01/11(月) 16:49:04
>>788 は、一人称が『俺』な腐女子らしい。
0797デフォルトの名無しさん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
0798,,・´∀｀・,,）っ-○○○2010/01/11(月) 17:16:57
>>795
ジャックフロストたん？
0799デフォルトの名無しさん2010/01/11(月) 21:46:19
クソッ、ダメだ。人生の勝ち組に何を言っても負け犬の遠吠えにしかならねぇ。
0800デフォルトの名無しさん2010/01/12(火) 11:54:14
>>793
おっさん、ワカメは好きか？
0801デフォルトの名無しさん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
0802デフォルトの名無しさん2010/01/14(木) 23:05:50
AGE
0803デフォルトの名無しさん2010/01/14(木) 23:16:25
チョー氏ロートなんだけど、linuxとかで一般的なpthreadsをGPGPUで
（しかもハードの最適な性能で）動かすっていうのは簡単にできる
もんなのでしょうか？
つまり、そういうランタイムを簡単に作れるかっていうことです。
漏れの周囲に出来ると主張する香具師がいるんだが、どうも
胡散臭くてそんなもん出来やしないというのを証明したいんです。
もし出来ないのであれば、出来ない理由も御教示くだされれば
すごく感謝します。
0804デフォルトの名無しさん2010/01/15(金) 00:05:18
>>803
GPGPUの並列化とpthreadsの並列化は別次元の話だぞ

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

ただ、その使い方を含めた最適化は個々の能力によりけりだとは思うが。
0805デフォルトの名無しさん2010/01/15(金) 02:16:30
そいつに実証させればいいじゃん
0806デフォルトの名無しさん2010/01/15(金) 20:57:25
> そういうランタイム
ってのがよくわからないな。
0807デフォルトの名無しさん2010/01/16(土) 12:14:46
>>803
何かすでに研究とかあるかもしれないけどとりあえず考えてみた。

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

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

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

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

そんな感じになるのではないか？
0808デフォルトの名無しさん2010/01/16(土) 13:05:36
pthreadとかはたかだか数スレッド並列で動かす程度の問題でしか使われていないから、
移植しても、GPUの恩恵は受けられないと思うよ。
むしろ、OpenMPのコードを自動的にGPUコードに変換してくれたらありがたい。
0809デフォルトの名無しさん2010/01/17(日) 11:22:10
>そういうランタイム

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


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

このくだりは胡散臭さを感じるなw
本当はおまいが知りたいだけだろw
0810デフォルトの名無しさん2010/01/17(日) 12:07:02
CUDA等のGPU実行環境に、pthreadを移植出来るのか？
って聞いているんじゃないの？
素直に受け取れば、そうなるだろう。
で、そんなの知らねーし、どーでもいいよカス、が答えだな。
0811デフォルトの名無しさん2010/01/18(月) 23:57:38
GF100とFermiのWhitepaperが上がってるけどどんなもんかね？
http://www.nvidia.com/object/gf100.html
0812デフォルトの名無しさん2010/01/19(火) 07:49:13
>>811
ゆめりあのスコア100万越える性能だってよ
絶対買った方がいいぞ
0813デフォルトの名無しさん2010/01/19(火) 14:13:46
ゆめりあ（笑）
0814デフォルトの名無しさん2010/01/19(火) 20:10:00
http://twitpic.com/yrug1
パソコン工房2FにHPC/GPUコンピューティングのカンファレンスルームができるとのこと
0815デフォルトの名無しさん2010/01/29(金) 16:03:36
理研とNVIDIA、HPC用途でのGPUアクセラレートの討論会を開催
～NVIDIA CEOがGPUコンピューティングの可能性をアピール
http://pc.watch.impress.co.jp/docs/news/20100129_345703.html
0816デフォルトの名無しさん2010/02/05(金) 19:52:25
Fermiが一月遅れるという噂
0817デフォルトの名無しさん2010/02/05(金) 19:57:03
で？
0818デフォルトの名無しさん2010/02/05(金) 21:30:02
情弱のおまえらにわざわざ教えてやったんだから
喜べよ
0819デフォルトの名無しさん2010/02/06(土) 20:20:47
で？
0820デフォルトの名無しさん2010/02/06(土) 21:28:34
fermiが遅れたところでAMDが選択肢に入るわけでもない
0821デフォルトの名無しさん2010/02/06(土) 22:15:22
S3一筋と言うわけだな！
0822デフォルトの名無しさん2010/02/06(土) 23:54:54
Fermiが出ても選択肢にならない人もいる
0823デフォルトの名無しさん2010/02/07(日) 09:30:31
Fermiいつでるのかっこわらい
0824デフォルトの名無しさん2010/02/20(土) 11:39:41
Fermiは良くてQ2
悪いとQ2の出荷が１万個弱で、一般人が手に入れられるのは
来年以降の可能性
0825デフォルトの名無しさん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

結構安いな
0826デフォルトの名無しさん2010/02/24(水) 01:42:38
ほれ、

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

結構高いな。
0827デフォルトの名無しさん2010/02/26(金) 10:00:24
おもちゃ屋にサンドとザブングルのポップがあった
0828デフォルトの名無しさん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
0829デフォルトの名無しさん2010/03/03(水) 01:19:04
今日からGeforce 260 > Radeon 5850になりました。
ここテストに出るよ
0830デフォルトの名無しさん2010/03/08(月) 14:55:50
アスキーのGPGPUセミナーってどうかな？

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

フィックスターズがやっているプログラミングセミナーの
tiny版みたいな感じなんだろうか。
あっちは受けてみたいけれど、高いからなー
アスキーのは1万ちょっとで講師は同じみたいだから、
お試しにいいかと思ってるんだけど
申し込みした人いる？
0831デフォルトの名無しさん2010/03/11(木) 06:35:09
そのGTX260は燃え尽きました。
0832デフォルトの名無しさん2010/03/11(木) 07:38:41
Fermiは皆の絶望を抱えて
爆発しました。ありがとう
0833デフォルトの名無しさん2010/03/20(土) 17:32:44
CUDA 3.0 Downloads
http://developer.nvidia.com/object/cuda_3_0_downloads.html
0834デフォルトの名無しさん2010/03/24(水) 22:49:37
東工大、気象庁の次世代気象モデルのフルGPU化に成功
http://pc.watch.impress.co.jp/docs/news/20100324_356466.html
0835デフォルトの名無しさん2010/03/28(日) 16:04:11
Fermiきたこれ
0836デフォルトの名無しさん2010/03/29(月) 15:22:49
GTX480･･･爆熱でかなり電気喰うけどこの手の用途だと相当速そうだな。
0837デフォルトの名無しさん2010/03/29(月) 18:34:55
この手の用途以外（グラフィックとか）だと無用のゴミだけどな
0838デフォルトの名無しさん2010/03/29(月) 20:23:48
ttp://www.guru3d.com/article/geforce-gtx-470-480-review/29

うんそうだね
もうテクスチャ張っただけのノッペリとか見飽きた
0839デフォルトの名無しさん2010/03/29(月) 20:52:18
>>838
なんか大した事無い映像だね。
0840デフォルトの名無しさん2010/03/29(月) 21:44:10
dirt2やheavenよりはましだけどね
0841デフォルトの名無しさん2010/03/29(月) 22:42:04
相変わらず嘘クセー絵だなあ
0842デフォルトの名無しさん2010/03/29(月) 22:57:09
このスレ的にはグラフィック用途での性能なんてどうでも良いんじゃないの?
0843デフォルトの名無しさん2010/03/29(月) 23:23:54
リアルな絵を出したいんならパストレーシングでも使わないと無理でしょ。
GTX480使ってもまだまだ辛いけど。
0844デフォルトの名無しさん2010/03/29(月) 23:47:54
レイトレーシングって分岐多くてGPUにはあんまり向いてないんじゃなかったっけ？
0845デフォルトの名無しさん2010/03/29(月) 23:54:36
レイトレは技術者のオナニーとしては出るかもしれんけど
リアルタイムグラには採用されないんじゃないの？
同じ演算リソースを使う限り、従来のシェーディングだったら
10倍ぐらい使えるんだろ？
0846デフォルトの名無しさん2010/03/30(火) 00:10:59
ゆきちははヨーヨーとか似合いそうですよね
0847デフォルトの名無しさん2010/03/30(火) 00:16:10
あ、ごめん誤爆
0848デフォルトの名無しさん2010/03/30(火) 05:22:40
ほい、レイトレ
ttp://www.nvidia.com/object/cool_stuff.html#/demos/2116
0849デフォルトの名無しさん2010/03/30(火) 20:26:25
>従来のシェーディングだったら

結局それって見た目変わんないんだろ
0850デフォルトの名無しさん2010/03/30(火) 23:57:12
ここは、漢らしくラジオシティで行こうぜ！
0851デフォルトの名無しさん2010/03/31(水) 02:11:42
男が脱いでいくベンチマークソフトあったでしょ
あれなんて言ったっけ？
0852デフォルトの名無しさん2010/03/31(水) 09:44:27
abe.exe
0853デフォルトの名無しさん2010/05/03(月) 10:24:28
GTX470 or 480の評価はどんなもんやねん
0854デフォルトの名無しさん2010/05/03(月) 10:35:18
お前が買って試せばいいねん
0855デフォルトの名無しさん2010/05/04(火) 21:58:22
数が少ないっちゅー噂やし
しゃあないかー
0856デフォルトの名無しさん2010/05/05(水) 01:03:49
“Llano” を見据えたATi Stream SDK 2.1
ttp://northwood.blog60.fc2.com/blog-entry-3803.html
0857デフォルトの名無しさん2010/05/05(水) 15:05:41
岡ちゃんの本ってどうなんですか？
0858デフォルトの名無しさん2010/05/07(金) 07:56:39
青木本で十分

青木本が難しいと感じる人は買ってみたらいいと思うよ
0859デフォルトの名無しさん2010/05/22(土) 18:40:05
http://en.inpai.com.cn/doc/enshowcont.asp?id=7670&pageid=7112
GPU OpenCL performance preview
0860デフォルトの名無しさん2010/05/22(土) 21:21:19
ttp://en.inpai.com.cn/doc/enshowcont.asp?id=7670&pageid=7112

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

　　　　　　,,,
(　ﾟдﾟ)つ┃
0861デフォルトの名無しさん2010/05/22(土) 21:36:30
geforceは制限されてて5870の2倍も出るのか
0862デフォルトの名無しさん2010/05/22(土) 21:38:23
1.5倍以下のトランジスタ数で2倍以上も出てりゃ優秀だろ
0863デフォルトの名無しさん2010/05/22(土) 21:41:34
十分すぎるな。
0864デフォルトの名無しさん2010/05/22(土) 21:50:38
てことはteslaは更に4倍近く速いのか・・
0865デフォルトの名無しさん2010/05/23(日) 12:05:09
スレというか板違いな>>860のぬか喜びっぷりが寒いな
0866デフォルトの名無しさん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の熱処理には相当に手を焼いている模様。
エアコンよりも計算機に金をかけたいんだぜ、という主張が
感じられます。
0867デフォルトの名無しさん2010/05/28(金) 21:42:42
で？
0868デフォルトの名無しさん2010/05/28(金) 21:52:03
>>866
nVidiaは18ヶ月で２倍速のペースで動いているのに１８ヶ月で追いつく言われても・・・
0869デフォルトの名無しさん2010/05/29(土) 01:41:45
2倍速で発熱増か流石だな
0870デフォルトの名無しさん2010/05/29(土) 01:59:54
>>868
消費電力あたりの性能ではAMDの圧勝ですが
0871,,・´∀｀・,,）っ-○○○2010/05/29(土) 03:05:15
メモリ帯域も頭打ちかけてるのに消費電力もダイサイズも増加させながらの倍々ゲームがいつまでも続くわけがないよ。
0872デフォルトの名無しさん2010/05/29(土) 03:59:12
ここで帯域問題を解決すべく箱○的にeDRAMをキャッシュとしてオンパッケージ化してだな（問題外
0873デフォルトの名無しさん2010/05/29(土) 04:05:18
アヤパン
0874デフォルトの名無しさん2010/05/29(土) 11:19:57
http://www.4gamer.net/games/110/G011065/20100526093/
AMDは汎用化に向けてできることから徐々に改良
NVは一気にのぼりつめようとして徐々に衰退
0875デフォルトの名無しさん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 ペタバイトの高メモリバンド幅
0876デフォルトの名無しさん2010/05/29(土) 21:06:45
暖房機4200台も納入とか、こりゃフアンは東工大に足を向けて寝られないな。
0877デフォルトの名無しさん2010/05/29(土) 22:16:27
東工大も引くに引けないだろうな
NVIDIAのシャチョさんのメンツってものもあるし
0878デフォルトの名無しさん2010/05/29(土) 22:19:00
GPUのコード書けない人は大変だな
0879デフォルトの名無しさん2010/05/29(土) 22:20:53
GPU？なにそれうまいの？
0880デフォルトの名無しさん2010/05/29(土) 22:26:29
Cよりちょっとハードルは高いけど、CUDAも書けないやつはプログラマーはやめたほうがいい。
並列アルゴリズムにはまだ未開拓の分野がある。
0881デフォルトの名無しさん2010/05/29(土) 22:32:32
そうはいっても、スパコン使う人には素人プログラマー
みたいな人もいるわけで
0882デフォルトの名無しさん2010/05/29(土) 22:39:46
インテラとかアムダはいつだすん？この手のアクセラレーター
0883デフォルトの名無しさん2010/05/29(土) 22:55:42
2012以降
0884,,・´∀｀・,,）っ-○○○2010/05/29(土) 23:06:00
CPUに内蔵されてるSIMDユニットを拡張していった方が

額面はともかく実効値はじきにCUDAハードウェアに追いつく
0885デフォルトの名無しさん2010/05/29(土) 23:13:56
>>882
AMDはもう出してるじゃん
0886デフォルトの名無しさん2010/05/29(土) 23:22:29
結局汎用性持たせるほど効率悪くなるだけだからな。
電力あたりの性能や、トランジスタあたりの性能でいうと
DGEMM用途なら、実はRadeon5870でも汎用性は過剰すぎ

疎行列用途ならGPGPUは意味が無い。
演算器なんぞ積まずに帯域だけ広げた方がいい。
0887,,・´∀｀・,,）っ-○○○2010/05/29(土) 23:44:52
Radeon用のGRAPE-GPUのコードって既にあったっけ
0888デフォルトの名無しさん2010/05/30(日) 00:20:59
GRAPEは知らないがGRAPE関係者の
会津大の先生がブルートフォースの
N-Bodyでほぼ理論値出してたような。
Oct-treeでも良い線行っている様な論文出てなかったっけ？
0889,,・´∀｀・,,）っ-○○○2010/05/30(日) 01:09:55
内積命令もあるしそれなりに良い数字出そうだね
0890デフォルトの名無しさん2010/05/30(日) 01:13:32
AMDの計算専用の奴って結構旧型じゃね？
メモリも少ないし。おまけにOpenCLのサポートがβだし。
もうちょい本気出して、nVidiaのTESLAボッタ（Quadraよりはマシか）商法を揺さぶって欲しい。
0891,,・´∀｀・,,）っ-○○○2010/05/30(日) 02:31:26
FermiはECCサポートしてるのが地味に大きい
0892デフォルトの名無しさん2010/05/31(月) 03:43:28
団子よララビーがお蔵入りになったら、今度はSIMD擁護でつか？
ほんと、懲りないやっちゃなー
0893,,・´∀｀・,,）っ-○○○2010/05/31(月) 04:27:26
勝手にお蔵入りにするな
0894デフォルトの名無しさん2010/05/31(月) 14:24:42
今度はも何もだいぶ前から団子はSIMD厨だったしLNI命令もSIMDじゃないのか…？
0895,,・´∀｀・,,）っ-○○○2010/05/31(月) 15:30:58
GPGPUもSIMDだ
0896デフォルトの名無しさん2010/05/31(月) 20:03:56
団子はAMD関連は徹底してるっぽ
SDK2.1は中身すら見ず無視
最新のRADEONとかも買わないようにしてる
0897,,・´∀｀・,,）っ-○○○2010/05/31(月) 20:24:05
どのみちアーキテクチャも命令セットも変わるのに過渡期のもの使っても意味ねーじゃん
0898デフォルトの名無しさん2010/05/31(月) 21:02:42
団子は今後も触れることはしないと思うな
だって団子はAMDのことをry
0899,,・´∀｀・,,）っ-○○○2010/05/31(月) 21:28:51
Mach64からのATIユーザーですが何か？
プログラマブルデバイスとして好かんと言ってるだけだ
0900,,・´∀｀・,,）っ-○○○2010/05/31(月) 21:45:24
ついでに言うとAMDのAVX互換化＆XOP/FMA4命令セットは結構買ってるんだけどな

仕様読みながらBulldozer向けのコードは既に書いてるよ
0901デフォルトの名無しさん2010/05/31(月) 22:12:43
>>896
SDK2.1のopenclはmingw gccでコンパイルできないバグがあるし。
まあ、ヘッダファイルをちょこちょこイジれば治るけど。
HD4850はβ対応だと言え、グループに64スレッド以上入れたらバグるとか（文書に明示してあるが、opencl関数でクエリしたら256まで使えると返ってくるのに）、
ローカル(cudaで言うところのshared）メモリが使えないだとか、
ゲフォやCPUエミュなら問題なく動くものが謎のバグで誤動作するとか
まあ、とにかくマトモに作り直して出直してこいという感じ。
0902デフォルトの名無しさん2010/05/31(月) 22:34:39
betaだもの
　　　　　　　　　AMD
0903デフォルトの名無しさん2010/05/31(月) 22:36:20
バグだらけを使うのも、それはそれで楽しいもんだろ
仕事じゃなけりゃな
0904デフォルトの名無しさん2010/05/31(月) 22:45:07
>>903
mingwのインストールミスってんじゃねーかとか、自分のclプログラムがバグってんじゃねーかとかくだらない時間を消費しまくったけどな。
自分の書いたもののバグ取りならともかく、提供物がバグってるのはマジ勘弁。
0905デフォルトの名無しさん2010/05/31(月) 22:57:59
というか、mingwってそもそも現時点でSDKの公式
サポート対象のコンパイラじゃないだろう。
calもmingwで使うためには、自前でインポートライブラリ作って
ヘッダも書き換えなきゃ実行ファイル作れないのに。
mingwでやるなとはいわんが、人柱的な
気構えで行くべきじゃね。
0906デフォルトの名無しさん2010/05/31(月) 23:11:30
>>905
Programming Gudeを見るべし。
cygwin, mingw gccを使えばgdbでカーネルのデバッグが出来ると書いてある。
できると言い切っているからには、当然試しているはずなのにコンパイルすら通らない。
0907デフォルトの名無しさん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のリファレンスにベクトル型の要素へのアクセス方法が記述されていないから規格の時点でアヤシイ部分だけど。
0908,,・´∀｀・,,）っ-○○○2010/05/31(月) 23:50:57
β以前の問題だな。NVIDIAのOpenCL SDKは【一応】ある程度使い物になるぞ
0909デフォルトの名無しさん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
とでもしておけば、デバッグできる。
0910デフォルトの名無しさん2010/06/01(火) 00:14:10
max work group sizeが256と返ってくるのに64までしか使っちゃダメ（どこに書いてあるのかすら忘れたくらいわからないところに書いてある）とか、
ゲフォやCPUエミュで動くのにデバイスで動かないとかはvcでもgccでも御同様なわけだけどな。
0911デフォルトの名無しさん2010/06/01(火) 04:42:06
alphaだもの

　　　　　　　　　　アムド
0912デフォルトの名無しさん2010/06/01(火) 10:17:50
>>907
そんなコードは cl 関係なくずっと昔から使ってる。
無名 union のせいじゃないかと思うが、VC++ のバージョンを書くのと、
最小限の再現コードを codepad に貼ってみ。
0913デフォルトの名無しさん2010/06/01(火) 10:55:30
>>912
なんや、おまえはAMDのOpenCl使ったことないのにエラソーこいてるのか。
cl_platform.hを見ればわかること。
そもそも提供されている型のアクセスの話なんだから、俺のコードじゃなくて、
提供コードの方の話だと常識的にわかるだろ。
0914デフォルトの名無しさん2010/06/01(火) 16:17:57
>>913
912の要求が満たされたら試していいと思ってることは伝わらなかったんだな。
http://www.khronos.org/registry/cl/api/1.0/cl_platform.h
のことでいいのか？
じゃ、今度はお前がVCのバージョンを書け。
ついでに、問題の箇所を行番号で指摘してもいいぞ。

ブラウザで検索してみたところでは、ANSI 非互換を許せば大丈夫に見える。
俺に見落としがあるか、サンプルやお前のコードが悪いのではないかと疑う。
0915デフォルトの名無しさん2010/06/01(火) 17:17:15
>>914
指摘もなにもwwww
なにが問題を起こしているのかわかっているからヘッダファイルをわざわざ指定したんじゃないかw
ヘッダファイルの中を掘り起こさないとコンパイルが通らない原因が分からないようなものを
使えます、みたいな顔をしてリリースすんなってことだよ。

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

0916デフォルトの名無しさん2010/06/01(火) 18:51:27
>>914じゃないけど、StreamSDKは昔は2005専用で2.x以降は現行のCUDAと同じく2008専用だけどそこは本当に間違えてないんだよな？
0917デフォルトの名無しさん2010/06/01(火) 21:15:46
>>916
その程度の知識で何を語っているのやら・・・
0918デフォルトの名無しさん2010/06/01(火) 21:18:24
RV7xx系(FireStream含む）に対してOpenCLがβ対応な時点でなにやってんだかって感じだが。
まずはFireStreamでキッチリ動かすのがアレを売った責任というものだろうに。
0919デフォルトの名無しさん2010/06/01(火) 21:27:43
>>917
お前が情報出さなさすぎだから>>916みたいな初歩的なツッコミが来るんだろうがｗ
0920デフォルトの名無しさん2010/06/01(火) 21:46:43
>>919
openclを明らかにわかっていない発言なんだが>>916は
0921デフォルトの名無しさん2010/06/01(火) 21:57:49
お前がVC++コンパイラでの話をしてるんだからVC++のバージョンの話をしてる>>916は大いに関係あるだろ
0922デフォルトの名無しさん2010/06/01(火) 22:01:07
くだらねぇことで盛り上がってるな。
0923デフォルトの名無しさん2010/06/01(火) 22:13:27
>>921
cl_platform.hを見てもそんなこという程度なら入ってくるなよ。
0924デフォルトの名無しさん2010/06/01(火) 22:57:14
OpenCLの策定時期と、GPU開発にかかる時間を考えると
AMDのGPUがOpneCLにまともに対応できるのは、
次の次くらいの世代のGPUでしょ
0925デフォルトの名無しさん2010/06/01(火) 23:00:33
その頃には別の対応に追われる
0926デフォルトの名無しさん2010/06/01(火) 23:01:55
へぇ、どういう対応なんでしょ
0927デフォルトの名無しさん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非互換オプションを指定すればすむ話なのに
作例の通りではコンパイルが通らないと嘘を書いています。
0928デフォルトの名無しさん2010/06/01(火) 23:36:13
VC++でも__GNU_C__が定義されてるのか？
0929デフォルトの名無しさん2010/06/01(火) 23:51:27
>>927
あほか。
ヘッダファイルを探らないといけない時点で終わってるって言ってるんだよ。
0930デフォルトの名無しさん2010/06/01(火) 23:56:58
ヘッダを見なきゃいけない時点で～って理屈が
通るかどうかは微妙なところだなぁｗ
昔の人やUNIXでコンパイルからが普通の人には
受け入れられないだろうし
0931デフォルトの名無しさん2010/06/01(火) 23:57:34
そもそも、RV7xx系でclGetDeviceInfoでmaxworkgroupsizeが256と返ってくるのに、
64以上は使わない方がいいとかこっそり書いているようなものはどうなんだ、ってことにはスルーしやがるしな。
しかも、このワークグループサイズはプログラムによって64以上で動いたり動かなかったりする非常にタチの悪い挙動を示すんだぜ。
使った事ないくせに何必死にAMD擁護してんだかわかんねーよ。
0932デフォルトの名無しさん2010/06/01(火) 23:58:52
>>930
それはないわ。
ヘッダを見て非公開な内部構造を触るってことは将来の互換性を失うことになるからな。
あくまでリファレンスに公開されている情報以上を使わないのがいいに決まってるだろ。
0933デフォルトの名無しさん2010/06/02(水) 01:00:16
>>931
そのバグ自体は次の版で直る予定だが、そもそもベータ版なのに何言ってるの？
0934デフォルトの名無しさん2010/06/02(水) 01:09:21
擁護とかなんで信者バトルみたいなどうでも良い展開に持ち込もうとするんだ？
別に今時点でのATI Stream SDKのOpenCLの出来が悪い事自体は
否定はしていないだろう。誰もフォローが入らないのは、正しい事を言っているから。
激しく突っ込みが入っているのは、どちらかと言うと使用者側の勘違いとか
そういう可能性のある内容だからだろう。

突っ込み側の書き込みについても、詳細を聞くのは問題を特定して
適切な対策を示したいからで、問題解決して開発を進めたい人間にとっては
プラスになるような内容だろ。
09359142010/06/02(水) 12:30:24
不具合があるというなら追試してやろうという俺が何で噛み付かれてるのか分からん。
と思ったら、文句の対象は Khronos じゃなくて ATI で、しかも単に文書の不備だったのか。

正直確かにひどいｗ
defined(__GNUC__) が無い限り無名 struct の方にはアクセスできないしｗ

だがやはり、今見ても 907 の文章は混乱している。
907 だと Khronos が叱られているように見えるし、VC をあのコードで境界が狂うような
劣等コンパイラと思っているように見える。
0936デフォルトの名無しさん2010/06/02(水) 22:18:23
正直、Khronosは酷いっす。
cl.hppはnamespaceの使い方がムチャクチャだし。
0937デフォルトの名無しさん2010/07/06(火) 12:35:24
AMD CALについて語ってください
0938デフォルトの名無しさん2010/07/13(火) 19:42:00
>>937
なにそれマイナー杉
0939デフォルトの名無しさん2010/08/09(月) 23:57:19
win7, NVIDIAのグラボ（GeForce9500って書いてある）でVC9.0のプログラムからGPGPUなリソースを利用したいのですが、なんて調べたらいいんでしょうか？
「VisualC++ OpenCL」でぐぐったらAMDのATI STREAMによるOpenCLの実装が出てきましたが、AMDの製品を利用していないので関係ありませんよね。
0940デフォルトの名無しさん2010/08/10(火) 00:01:48
バカかおまえ
0941デフォルトの名無しさん2010/08/10(火) 00:10:22
自己解決。NVIDIAのOpenCL見つけました。どうもありがとう。
0942デフォルトの名無しさん2010/08/10(火) 00:28:23
それで解決したならいいんじゃね？ｗ
0943デフォルトの名無しさん2010/08/10(火) 00:29:11
すみません嘘付きました。
0944デフォルトの名無しさん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
0945デフォルトの名無しさん2010/08/12(木) 14:48:11
nVもAMDもとりあえず1.1に対応したか


…S3用のOpenCLってどこ？
0946デフォルトの名無しさん2010/08/12(木) 14:58:11
NDeveloperから登録完了メール来ないからOpenCL落とせないお （｡ﾟ´ω｀ﾟ｡） ﾋﾟｰ
0947デフォルトの名無しさん2010/08/12(木) 15:04:18
>>946
OpenCLの普及を阻害する牛歩戦術か…
0948デフォルトの名無しさん2010/08/12(木) 18:07:24
>…S3用のOpenCLってどこ？

アナウンスはしていても
実際に何のソフトもない出てないものに
躍起になると思うのか？
0949デフォルトの名無しさん2010/08/13(金) 22:15:38
だれもS3でやろうとは思わないからな
現状NかAの二択
0950デフォルトの名無しさん2010/08/14(土) 07:43:26
だがハード的に一番汎用に向いてるのはChromeなんだがね
0951デフォルトの名無しさん2010/08/14(土) 13:11:27
nvidiaの目指す汎用性って
cのプログラムがなるべく変更無く動くかどうかで
もともとのGPGPUの目指していたはずの方向とは違うような。
NVの目指す未来の究極はマルチコアCPUでしかない。
0952デフォルトの名無しさん2010/08/14(土) 13:27:28
向いててもさ
4コアCPUにピーク性能でもメモリ帯域でも劣ってるGPGPUとか一体どこに魅力を見出せばいいのかね？
0953デフォルトの名無しさん2010/08/15(日) 01:56:52
GPGPUの載っているハード限定なんだからChromeはない。
0954デフォルトの名無しさん2010/08/15(日) 07:54:31
CPUに劣るってのはAMD

逆にS3はあれでCPU並なのはすごい
0955デフォルトの名無しさん2010/08/15(日) 09:13:39
製品はすごいらしい(信者曰く)
けど積極的に使おうとは思わないのが現実
0956デフォルトの名無しさん2010/08/15(日) 12:11:36
一番カスなのはAMDで間違いないけどな
0957デフォルトの名無しさん2010/08/15(日) 12:23:24
＞GPGPUの載っているハード

これってどういうこと？
0958デフォルトの名無しさん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持ってきたら差は更に開く
0959デフォルトの名無しさん2010/08/15(日) 14:44:05
理論値持ってきてる時点で頭悪い
0960デフォルトの名無しさん2010/08/15(日) 14:44:58
＞GPGPUの載っているハード

ねぇこれってどういうこと？
0961デフォルトの名無しさん2010/08/15(日) 14:48:28
積極的に使いたいけどハードがうんこなので
一向に普及しないOpenCL
0962デフォルトの名無しさん2010/08/15(日) 14:54:00
OpenCLはEPから実用になるみたい
0963デフォルトの名無しさん2010/08/15(日) 16:49:49
>>959
GPUは理論性能と実効性能が剥離するのが通例
いかにChromeであろうと同じだしこれだけ理論性能で
CPUに差を付けられたら普通勝ち目は無い

まぁバカに言っても無駄だろうから死ぬまでChrome持ち上げてるといいよ
0964デフォルトの名無しさん2010/08/15(日) 18:38:04
そうだね,そのchromeに負けちゃうradeonって
どうやって持ち上げればいいんだろうね
0965デフォルトの名無しさん2010/08/15(日) 18:41:59
OpenCLが普及しないのはAMDのせい？appleのせい？
0966デフォルトの名無しさん2010/08/15(日) 18:44:43
CPUにさえ勝てないChromeってGPGPUの価値の何たるかさえ実感できないよね
0967デフォルトの名無しさん2010/08/15(日) 18:46:28
GPGPUの価値ってなに？
Havok clothでcpuより遅いって公言すること？
0968デフォルトの名無しさん2010/08/15(日) 18:49:12
Open Physicsって、まだ実用化されないの？
0969デフォルトの名無しさん2010/08/15(日) 18:52:56
AVXの登場によってGPGPUなんて何の価値もなくなるよ
0970デフォルトの名無しさん2010/08/15(日) 18:53:35
PhysXGPUはx87+シングルスレッドじゃないとPhysXCPUと勝負にならないよ

とバラされる事じゃないかな
0971デフォルトの名無しさん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
0972デフォルトの名無しさん2010/08/15(日) 19:27:45
で、実パフォーマンスでGeforceに負けてるRadeonって・・
0973デフォルトの名無しさん2010/08/15(日) 19:47:48
GeforceってGPGPUではRadeonを無双できるんじゃなかったっけ？
http://www.computemark.com/

できてないっぽいけどどうしちゃったの？
0974デフォルトの名無しさん2010/08/15(日) 20:00:04
ComputeMark(笑)
0975デフォルトの名無しさん2010/08/15(日) 20:05:37
結局ベンチ回すしか使い道がないんだな
0976デフォルトの名無しさん2010/08/15(日) 20:15:47
勝てないアプリ見つけたら語尾に（笑）を付けるだけの簡単なバイトです
0977デフォルトの名無しさん2010/08/15(日) 20:18:50
そうだね、そのベンチが信頼できるなら
東工大もradeon使ったろうね
0978デフォルトの名無しさん2010/08/15(日) 20:20:53
今日はこのスレにしては珍しく、キチガイが暴れてるね。
0979デフォルトの名無しさん2010/08/15(日) 20:22:03
そういえばLinpackも実効率低かったなぁ
Nebulaeのおかげで天河笑えなくなっちゃったね
結局GPUなんてHPC用途で期待されてるのはメモリ帯域だけだったわけだ
0980デフォルトの名無しさん2010/08/15(日) 20:28:00
東工大はずっとTeslaでやってきたから蓄積を重視しただけ
逆に多体のように向いてる用途ならRadeon使ってるところもある
ただそれだけの話
0981デフォルトの名無しさん2010/08/15(日) 20:28:56
そのメモリ帯域もすでに頭打ちだからな
0982デフォルトの名無しさん2010/08/15(日) 20:31:51
まぁ、ECC無の時点でお笑いなんですが
0983デフォルトの名無しさん2010/08/15(日) 20:33:58
何でもいいからRadeon用のGPGPU商用実用ソフトってないの？
0984デフォルトの名無しさん2010/08/15(日) 20:34:37
自作板では「Geforce ゲーム糞遅せえ。使えねえ」と煽っておいて
こっちじゃありがたくGeforceを使う。

これがこの板の流儀だが、なにやら勘違いしたお子様が混じっているようだ。
0985デフォルトの名無しさん2010/08/15(日) 20:35:18
所謂GPGPU向けのアプリケーションなら
今のラデのアーキテクチャ位が
一番トランジスタ効率・電力ともに優れている。

汎用向けに振るのは、なるべく効率を落とさないで
汎用性を上げる努力だけど、究極の目標となる
汎用性が現状のCPUなら、バランス的に
現状のCPUを超えるのは不可能なんだよ。

だから汎用といいつつ、ターゲットを絞って
特定分野向けのコードならこれに置き換えれば
これだけ速くなりますと言う風に進むのが正しい形
0986デフォルトの名無しさん2010/08/15(日) 20:37:58
なら、がんばってソフト出してよ
0987デフォルトの名無しさん2010/08/15(日) 20:46:02
GPUなんておとなしくテクスチャ張に専念してればいいんだよ
しゃれたShaderなんて使おうとしてもどうせ遅いんだから
0988デフォルトの名無しさん2010/08/15(日) 20:46:36
Chrome厨君に4コアCPUに勝てないよねと現実を叩き込んであげただけなのに

気分を害したなら謝るけど途中から話を逸らしまくって
Geforceの話し出したのは俺じゃないし非難される謂れは無いよ
0989デフォルトの名無しさん2010/08/15(日) 21:02:34
>4コアCPUに勝てないよね

radeonのhavok clothのことね
0990デフォルトの名無しさん2010/08/15(日) 21:05:32
chromeの場合4coreに勝てなくても問題無いだろ
どうせ組み合わせはnanoとチップセットのVN1000(Chrome520)しかないんだから

そもそもOpenCLがもっと広まらなきゃ
対応する意味も無いわけだがね
0991デフォルトの名無しさん2010/08/15(日) 21:18:30
>>989
PhysX87: Software Deficiency
http://www.realworldtech.com/page.cfm?ArticleID=RWT070510142143

下手すりゃCPUでやらせた方が速そうなのにGPUにさせる意義ってあるの？
GPU上で物理演算を実行してもらわないと困る人？

NVIDIAの中の人ならそら困るのかもね
0992デフォルトの名無しさん2010/08/15(日) 21:32:03
つーか、そもそもCPUでやってもリアルタイムで
どうにかなる程度の軽い演算を、わざわざCPUから遠い
GPUでやるのは意味が無い。

実用するにはCPUの10倍程度の速度アップが
必要なくらい重い演算を持ってくると意味が出てくる。
0993デフォルトの名無しさん2010/08/15(日) 21:41:51
なまじCPUもGPUも持ってると、どちらでやった方がいいか突き詰めてからでないと商売できないのはつらいね
0994デフォルトの名無しさん2010/08/15(日) 21:42:32
だからテクスチャだけ張ってろよ
0995デフォルトの名無しさん2010/08/15(日) 21:46:33
もともとのPPUの中の人も
GPUに物理処理は向かないって言ってたもんね
0996デフォルトの名無しさん2010/08/15(日) 21:49:41
次スレ立ててきたぞ
落ちてからでも良かったかもしれないが

GPGPU#5
http://hibari.2ch.net/test/read.cgi/tech/1281876470/l50
0997デフォルトの名無しさん2010/08/15(日) 21:50:29
＞下手すりゃCPUでやらせた方が速そうなのにGPUにさせる意義ってあるの？

radeonでデモする意味あったの？
0998デフォルトの名無しさん2010/08/15(日) 21:51:01
と言いつつAgeiaの中の人も今じゃAMDにいるからなぁ
とんだ詐欺師なのかねあの人
0999デフォルトの名無しさん2010/08/15(日) 21:52:29
ＧＰＧＰＵなんて飾りです
偉い人にはそれがわからんのです
1000デフォルトの名無しさん2010/08/15(日) 21:53:30
>>997
さぁな
おまえみたいにGPU PhysX信じてるバカをだまくらかして株価を上げたかったんだろうよ
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。