[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/09 17:28 / Filesize : 215 KB / Number-of Response : 912
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

【GPGPU】くだすれCUDAスレ【NVIDIA】



1 名前:デフォルトの名無しさん mailto:sage [2008/03/22(土) 11:13:52 ]
このスレッドは、他のスレッドでは書き込めない超低レベル、
もしくは質問者自身何が何だが分からない質問を勇気を持って書き込むスレッドです。
CUDA使いが優しくコメントを返しますが、
お礼はCUDAの布教と初心者の救済をお願いします。

CUDA・HomePage
www.nvidia.com/cuda

関連スレ
【GPGPU】NVIDIA CUDA質問スレッド
pc11.2ch.net/test/read.cgi/tech/1190008468/
GPUで汎用コンピューティングを行うスレ
pc11.2ch.net/test/read.cgi/tech/1167989627/
GPGPU#2
pc11.2ch.net/test/read.cgi/tech/1188374938/



420 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/02/09(月) 18:02:06 ]
>>416-417
だれも連投してくれなんて頼んでないよ?

421 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/02/09(月) 18:06:41 ]
GPGPU向けの画像・動画関連のソフトってどれも速さばかり求めて品質は二の次だな
ウンコなエンコーダだとRGB/YUV変換で腐る
一番腐るのは量子化だろうけどな

422 名前:デフォルトの名無しさん mailto:sage [2009/02/09(月) 18:25:28 ]
Geforceは何気にGTXシリーズで初めて64bitに対応してるけど
演算装置は1個しかないw
並列処理が得意な分野でfloatだけで済むようなものはほぼ無いだろw

423 名前:デフォルトの名無しさん mailto:sage [2009/02/09(月) 19:05:29 ]
>>420
連投じゃなくて別人
2ch歴長いんだからそれくらい分かれ

424 名前:デフォルトの名無しさん mailto:sage [2009/02/09(月) 20:42:10 ]
甘いな。floatでも速ければ使い物になる用途は結構あるもんだよ。
例えば、近似計算なんかはfloatで近似させてからdoubleで更に近づけることもできるしね。

425 名前:デフォルトの名無しさん mailto:sage [2009/02/09(月) 21:56:34 ]
そういや西和彦もこっちの出身だな。確か甲陽から和田大
だから、落ちこぼれか。そもそも博士余りで高学歴ワープアPD
が社会問題に成ってる今日この頃に、大学院新設とかもうね
アボガドバナナ…。
鴨葱メロンと言えば、金出教授もこっちの出身だったな。
沢山カメラ使って超解像みたいな論文も有ったような無かったような。

426 名前:デフォルトの名無しさん mailto:sage [2009/02/13(金) 13:06:41 ]
>>425
お前、自分の考えまとめるの下手だな。

427 名前:デフォルトの名無しさん mailto:sage [2009/02/13(金) 13:31:44 ]
まあ、CUDAは英文のドキュメントが読めてある程度知能がないと
使えないからな。

スレ違いの話で盛り上がるのも分かるな。バカばっかりだしw

428 名前:デフォルトの名無しさん [2009/02/13(金) 17:06:53 ]
CUDA版のTripcode Explorerができたみたいですね。最適化に期待します。
tripper.kousaku.in/
download.kousaku.in/trip/Tripcode-Explorer-CUDA-test1.zip



429 名前:,,・´∀`・,,)っ-●◎○ mailto:!sage [2009/02/13(金) 18:13:51 ]
ようこそ、バーボンハウスへ。
このテキーラはサービスだから、まず飲んで落ち着いて欲しい。

うん、「絶対に動かない」んだ。済まない。
仏の顔もって言うしね、謝って許してもらおうとも思っていない。

でも、このネタプログラムを見たとき、君は、きっと言葉では言い表せない
「ときめき」みたいなものを感じてくれたと思う。
殺伐とした世の中で、そういう気持ちを忘れないで欲しい、そう思って
5分ででっちあげたんだ。

じゃあ、注文を聞こうか。





--------------------
1M超のバイナリファイルに何が詰まってるか疑問な人は、テキストエディタで開いてみればいいよ><

430 名前:デフォルトの名無しさん mailto:sage [2009/02/13(金) 23:27:26 ]
CUDAはコアレスと分岐の扱いを把握すれば、やりたいことは大体クリア出来ると思われ。

431 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/02/14(土) 00:05:15 ]
結局プレディケートなんだよね。
SMあたりの命令デコーダは1基だからSP毎に別々のフローを実行することができない。

Larrabee(Ct)なら分岐は容易に表現できる。

432 名前:デフォルトの名無しさん mailto:sage [2009/02/14(土) 01:58:51 ]
>>431
プレディケードって??

433 名前:,,・´∀`・,,)っ-●◎○ mailto:sage [2009/02/14(土) 11:48:56 ]
えーとね、たとえば
if (cond) {
  funcA();
} else {
  funcB();
}
なんてコードがあるとしよう。
普通のCPU向けのCだと、 cond の条件にしたがって、funcA()を実行するブロック、
あるいはfuncB()を実行するブロックにジャンプする。
すなわち命令ポインタを操作してコードを飛ぶ。

CUDAにおいてはシェーダマルチプロセッサ一つにたいし、命令デコーダは1つしかない。
にもかかわらず、condは要素ごとに変わるわけで、条件分岐先はSPごとにバラバラになる可能性がある。
んで、そこで使うのがプレディケートなわけだけど、簡単にいえば、ifとelseの両方を通るようにする。
funcAとfuncBをインライン展開して、条件ビットで選択的に実行するコードに展開する。
んで、各要素に対して、実行するか実行しない(あるいは実行結果を反映しない)かを選択的に行うわけだ。
並列度の高いプロセッサではよく使われる方法だ。

んで、こっからはこのアプローチの弱点。
問題はif-elseを何重にも組み合わせたり、switch文を多用する場合、総当たりにかかる計算時間量が
並列化によるパフォーマンスメリットを相殺し、逆に遅くなるケースもある。
並列処理を諦めて素直に要素ごとに逐次処理をさせてくれたほうがかえって効率がいいかもしれない。

しかしCUDAってそのへんの融通がきかないんだよね。基本的に【並列処理しか記述できない】から。
正確には逐次処理は専用のプリミティブなんかを使って限定的に逐次処理はやれるけど記述面では
かえって面倒になる。
GPUで不得意な処理はCPUでやれってアプローチだからそのへんの融通を利かせる気は無いらしい。

434 名前:デフォルトの名無しさん mailto:sage [2009/02/14(土) 11:57:31 ]
CUDAで困るのはその点のほかに、並列数を途中で変えられないこともあるよね。
一度ホストに処理を戻すと遅くなりかねないし、共有メモリが失われてしまうし。
私の関わっているプロジェクトでは演算処理が中心なので、ある程度融通が利いてくれないとね。

435 名前:デフォルトの名無しさん mailto:sage [2009/02/15(日) 06:24:49 ]
前にも有ったけど、条件分岐したら負け。
Crayだってそうだったじゃん。

436 名前:デフォルトの名無しさん mailto:sage [2009/02/15(日) 12:43:21 ]
CPUだとforループが多重になる部分をGPUに
丸投げすればいいんでしょ?
3項演算子程度は実行して欲しいけど

437 名前:,,・´∀`・,,)っ-●◎○ mailto:sage [2009/02/15(日) 16:42:36 ]
> forループが多重になる部分

重要なのは回数であって多重かどうかはあまり関係ないです。
32の倍数であることは有る程度重要かな

一番重要なのは依存関係がないこと。
たとえばループを逆順で実行しても結果が等価であったりとかね。

240 SP(30 SM)を使えるとすれば、フルに使うには、最低960程度の演算が並列実行可能である必要があります。
ただし、全部のSMでまったく同じ処理をする必要はないです。

438 名前:デフォルトの名無しさん [2009/02/15(日) 17:06:37 ]
>一番重要なのは依存関係がないこと。
そうだね。そのためiCotの時も関数型言語の並列化
に七転八倒してたね。
今ならerlangで良いんじゃね? CUDAスレでこんなこと
言うのも何だけど、Cライクな手続き型言語だとどうして
もすぐに壁にぶつかってしまって、スケーラビリティが
出せない。もしくは出そうとするとプログラマの負担が
重過ぎる。
個人的には今更lispやprologに復活されたくはないけど。



439 名前:デフォルトの名無しさん mailto:sage [2009/02/15(日) 17:15:56 ]
>>438
そう、わかったよ
じゃあ俺様がCUDA用erlang処理系書いてやる

440 名前:デフォルトの名無しさん mailto:sage [2009/02/15(日) 17:57:47 ]
ループを並列処理に展開するのって自動化出来そうだけど

441 名前:デフォルトの名無しさん mailto:sage [2009/03/04(水) 19:00:05 ]
>>424
おいおい調子に乗って嘘つくな。
「簡単にできるぜ!」っとか鼻高々なのはいいけどそんなのないよ。

442 名前:デフォルトの名無しさん mailto:sage [2009/03/05(木) 00:44:05 ]
>>441
いや数値計算なら反復法とか1次連立方程式の陰解法で使えるだろ

443 名前:デフォルトの名無しさん mailto:sage [2009/03/05(木) 00:59:48 ]
また自信満々な人の嘘つき合戦ですか?

444 名前:デフォルトの名無しさん mailto:sage [2009/03/05(木) 01:00:38 ]
なんだよ微分方程式、というか積分使うのか。
積分を近似計算といっていいのか?
実用内ではあると思うけど、それもfloat(7)からdouble(16)だろ。何回ループするつもりなんだよ。

445 名前:デフォルトの名無しさん mailto:sage [2009/03/05(木) 03:47:40 ]
積分を近似計算と言ってはいけない理由がわからん。

446 名前:デフォルトの名無しさん mailto:sage [2009/03/05(木) 06:23:04 ]
数値計算なら兎も角、シミュレーション関係なら大いに有り得る話だな。
自分が知っていることが全てではないと認めることができれば世界は広がるのに。

447 名前:デフォルトの名無しさん mailto:sage [2009/03/05(木) 20:24:13 ]
他人を否定することでしか自分を正当化できない、ということか。

448 名前:デフォルトの名無しさん mailto:sage [2009/03/05(木) 21:39:34 ]
>>447
数値計算と近似計算の違いを教えてくれませんか?



449 名前:デフォルトの名無しさん mailto:sage [2009/03/06(金) 04:35:50 ]
>>448
1+1=2となるのは、数値計算ではあるが近似計算ではない。

450 名前:デフォルトの名無しさん mailto:sage [2009/03/06(金) 08:57:12 ]
CUDA 2.1 Notebook Drivers for Windows
ttp://forums.nvidia.com/index.php?showtopic=91157

βだけども

451 名前:デフォルトの名無しさん mailto:sage [2009/03/06(金) 14:44:51 ]
>>446
とすると、貴方の世界ではシミュレーションとは近似計算をしてるってことですか?

452 名前:デフォルトの名無しさん mailto:sage [2009/03/06(金) 15:05:56 ]
物理にしろ確率モデルにしろコンピュータシミュレーションは近似計算だろ

453 名前:デフォルトの名無しさん mailto:sage [2009/03/06(金) 15:08:22 ]
整数演算は近似計算ではありません。

454 名前:デフォルトの名無しさん mailto:sage [2009/03/06(金) 15:15:06 ]
approximationの意味分かってるの

455 名前:デフォルトの名無しさん mailto:sage [2009/03/06(金) 15:38:46 ]
なんかめんどくさそうな人がいっぱいいますね。
どうでもいいですが、早いところストリーム用のプログラミング手法を確立して、ストリームに特有な技法を紹介する本を出してくださいな。

456 名前:デフォルトの名無しさん mailto:sage [2009/03/06(金) 16:26:22 ]
どうして煽りを入れる人ほど知識が足りないんだろう?


457 名前:デフォルトの名無しさん mailto:sage [2009/03/06(金) 17:11:04 ]
>>456
知識が足りないから煽るじゃないですかね?
そういう低脳な人は「煽ることしか出来ないよね」っとも言いますけど。
そんなことどうでもいいんで「ストリームんグ・プログラミング技法」とかいうブログを早く作ってくださいな。

「approximationの意味分かってるの」とかめんどくさそうな人との議論とかいかめしい顔した人が言う哲学に興味はないんで。

458 名前:デフォルトの名無しさん mailto:sage [2009/03/06(金) 17:14:51 ]

低脳な人の煽りの見本



459 名前:デフォルトの名無しさん [2009/03/06(金) 18:03:55 ]
458 名前: デフォルトの名無しさん [sage] 投稿日: 2009/03/06(金) 17:14:51

低脳な人の煽りの見本

460 名前:デフォルトの名無しさん mailto:sage [2009/03/06(金) 19:56:54 ]
プログラム板なんだから少しはプログラム出せって

461 名前:デフォルトの名無しさん [2009/03/06(金) 20:18:50 ]

低脳な人の煽りの見本

462 名前:デフォルトの名無しさん mailto:sage [2009/03/06(金) 20:40:17 ]

低脳な人の煽りの見本


463 名前:デフォルトの名無しさん [2009/03/06(金) 20:41:28 ]
>>448
1+1=2となるのは、数値計算ではあるが近似計算ではない。

464 名前:デフォルトの名無しさん mailto:sage [2009/03/06(金) 22:21:12 ]
VIPのまとめWikiに書いたこともあるが、今はネタがない。

あーそうそう、x16バスに繋がった8800GTの方がx8バスに繋がったGTX280よりも速かったってこと位か。
但し、転送量が多目の用途だからだとは思うが。

465 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/03/06(金) 22:22:16 ]
VIPPERプログラミングスレの派生なのかここ?

466 名前:デフォルトの名無しさん mailto:sage [2009/03/06(金) 22:23:45 ]
大丈夫、私はvipには書いていないw
でも何故かまとめWikiには複数投稿している罠。

467 名前:デフォルトの名無しさん mailto:sage [2009/03/07(土) 02:00:17 ]
自分が知らない事はWeb見て知ったかぶらないで馬鹿げたレスする暇で
amazonで本の一冊でも買えばいいのに。

ところでCUDAで性能だすためのまとまった日本語の文書ないかな?

468 名前:デフォルトの名無しさん mailto:sage [2009/03/07(土) 02:22:11 ]
そもそもCUDAに関して有用な日本語資料がなくね?
公式でさえ日本語マニュアルはあんなだったし。



469 名前:,,・´∀`・,,)っ-●◎○ mailto:sage [2009/03/07(土) 02:25:00 ]
大丈夫、英語資料すらろくなのないから。


470 名前:デフォルトの名無しさん mailto:sage [2009/03/07(土) 02:30:32 ]
やはり本家のドキュメントにあたるしかないのか。
めんどくせー。環境の開発もいいけどドキュメントの整備も力入れてほしいわ。

471 名前:,,・´∀`・,,)っ-●◎○ mailto:sage [2009/03/07(土) 07:18:34 ]
逆に日本語ドキュメントがあっても大して意味無いよ。
IntelのプログラミングマニュアルなんていまだにPentium 4のことしか書いてないぞ。
日本法人仕事しなさすぎる。

CUDAを勉強するより前に英語アレルギーを克服したほうが何かと良くなるかも。



472 名前:デフォルトの名無しさん mailto:sage [2009/03/07(土) 07:55:47 ]
英語アレルギーってなに?

473 名前:デフォルトの名無しさん mailto:sage [2009/03/07(土) 08:25:11 ]
そう言いたくなるくらい、英語から目を背ける人は世の中に意外と多い。

474 名前:デフォルトの名無しさん mailto:sage [2009/03/07(土) 08:45:27 ]
俺の場合英語と日本語だと読むスピードが10倍〜100倍違うorz.



475 名前:デフォルトの名無しさん mailto:sage [2009/03/07(土) 11:19:36 ]
母国語でないと読むスピードが遅いだけじゃなく小さなとこで思い
違いがでてきて結局後からまた参照したりして嫌だ。

476 名前:デフォルトの名無しさん mailto:sage [2009/03/07(土) 11:23:45 ]
技術的文書に機械翻訳はどの程度通用するんだろ。奇想天外な訳になってしまうのかな。連投スマソ


477 名前:,,・´∀`・,,)っ-●◎○ mailto:sage [2009/03/07(土) 11:41:59 ]
英文学読めって言ってるんじゃないんだし、書ける・話せるも別問題。
技術ドキュメントの英語なんて、有る程度形式ばった言い回ししかやらないので
単語を摘み出すだけでも回数を重ねればそこそこ意味はわかるようになると思う。

慣れてくれば技術系ニュースサイトとかも読んでみたり。

478 名前:デフォルトの名無しさん mailto:sage [2009/03/07(土) 11:51:27 ]
だんごさんはどーゆーサイトみてますか
スレ違い申し訳ない



479 名前:,,・´∀`・,,)っ-●◎○ mailto:sage [2009/03/07(土) 12:17:36 ]
Intelの開発者ブログとかRSSに入れてる

480 名前:デフォルトの名無しさん mailto:sage [2009/03/07(土) 22:13:23 ]
団子はGPGPU嫌いなんじゃなかったの?

481 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/03/07(土) 22:18:46 ]
逆に、好きな奴いるのか?
非生産的で変態だけど性能のために仕方なく使う類のモノだろ

482 名前:デフォルトの名無しさん mailto:sage [2009/03/07(土) 22:22:35 ]
おれもGPGPUなんて嫌いだな。
開発したことあるけどPSシリーズも大嫌い。

483 名前:,,・´∀`・,,)っ-●◎○ mailto:sage [2009/03/08(日) 08:31:15 ]
x86でいうMMX/SSEって、分岐が除去できるとか直列方向のパフォーマンスメリットがあった。
GPGPUって並列方向のスループットありきで、ホスト側のコードでお膳立てしてやらないといけない。


484 名前:デフォルトの名無しさん [2009/03/08(日) 19:46:25 ]
>非生産的で変態だけど
それってintelアーキのことじゃん。昔からずっと言われ続けてることだが。
mc68kやsparc,mipsの方がよっぽど素直に書ける。

けど市場規模のために仕方無く使わされてる。

485 名前:デフォルトの名無しさん mailto:sage [2009/03/08(日) 20:10:12 ]
アセンブラはmc68とx86しかやったことないけど、
mc68はかきやすかったな〜。

欲を言えば16本すべて汎用レジスタだったらよかったんだけどw

486 名前:,,・´∀`・,,)っ-●◎○ mailto:sage [2009/03/09(月) 01:10:52 ]
>>484
あー?
メモリアドレッシングモードが貧弱すぎるんだけどー?
まじうけるー?
パネェっすよ

487 名前:デフォルトの名無しさん mailto:sage [2009/03/09(月) 01:20:53 ]
インテルに慣れきってるとそう思うかもね。
どうせ団子はインテル一筋なんだろ?w

488 名前:,,・´∀`・,,)っ-●◎○ mailto:sage [2009/03/09(月) 02:18:43 ]
> mc68とx86
その時代だと8086だろ。「x86」って基本的に32ビット以降のことを言うと思うんだけど。
32ビットだとぜんぜん自由度が違うっしょ。セグメントなんて使わなくていいし。
4GBの論理メモリ空間をリニアにアドレッシングできるし。
んで、案の定ローエンドサーバだけにとどまらずHPCもx86に惨敗して虫の息じゃないか
古くからあるRISCなんて。
MIPSも組み込みに逃げたけどARMに食われたね。

それはともかくSSE・MMXも経験ない男の人がCUDAなんて・・・




さて、CUDAの話なんだけど、基本的に最小の演算単位は32ビット×32のSIMDで
メモリロード・ストアも、各要素ごとに計算してscattering/gathering機構付きの
ロード・ストアユニットで、
このへんはCUDAのアーキテクチャマニュアルにも載ってる通り。

従来SIMDって基本的に連続的に並べないと性能出ないけど、
CUDAは動的にベクトルを再構成することで、一気に柔軟性が向上した。

逆にこの強力なロード・ストアユニットを載せたせいで、連続したデータに対する
ロードストアの効率が悪くなってね。
一時変数をどっかに置いとこうとした場合にも、32要素ごとにバラバラにアドレスを計算する
scattering/gathering機構つきのロード・ストアユニットに通す羽目になる。
これじゃエネルギー効率的にもよくないでしょ。

んで、レジスタにそのまま保持すればいいじゃないってことで、それで
1つのシェーダコアあたりのレジスタファイルが、32KBとか64KBみたいな巨大なことになってる。
それにしても一般のCPUのL1キャッシュよりレイテンシの大きいレジスタファイルって一体・・・



489 名前:デフォルトの名無しさん mailto:sage [2009/03/09(月) 02:50:28 ]
団子の脳みそがx86のアーキテクチャで凝り固まってて、現代風のプログラミングパラダイムについて来れないってことだろ。
あと10年もすればおまえの持ってる小手先業などは博物館の展示資料でしかないし、おまえの能書きなど頑固オヤジの戯言同じなるだろう。
インテルのブログで洗脳されまくっちゃうのもいいけど、アーキテクチャマニュアル云々よりも団子が頭の切り替えをできるかどうかのほうが問題なんじゃないの?

490 名前:デフォルトの名無しさん mailto:sage [2009/03/09(月) 02:57:29 ]
現代風のプログラミングパラダイムって何だ?

491 名前:,,・´∀`・,,)っ-●◎○ mailto:sage [2009/03/09(月) 03:33:26 ]
斜め上をいく愚言に感謝する。

しかしながらscattering/gatheringによる柔軟なアクセスはSIMDの新時代を切り拓くものだ。
実際Intelも2〜3年先のSIMD拡張では256ビット、512ビットと幅が広くなってるため、
AoS/SoAの変換をいかに効率よくこなすかがテーマになってくる。
(ちなみにLarrabeeにはscatter/gather命令そのものを導入する)

このへんはむしろCISC的なプロセッサの美学だと思うがね。
AltiVecとかCellのSPEでなら何十命令かかる命令を1命令でこなす。
1クロックサイクルスループットでこなせない命令を実装しないのがRISCだろ。
モダンなCPUではパイプラインの前半部分のほうがALU自体よりもコストがかかるしまってるから
それで処理単位がリッチなCISCのほうが効率がよくなってるわけさ。
このへんは gimpo.2ch.net/test/read.cgi/i4004/1220728356/76あたりと同意見

しかしさ、16要素とか32要素とか、全部バラバラのアドレスだとしてみ?
とてもワーストケースで要素数分だけメモリアクセスが必要だぜ。
RISCの守備範囲じゃねーよ

んで、個人的にCUDAの問題は、scatter/gatherスカラ命令を備えないことなんだよね。
常に32並列単位で演算しないといけない。それで小回りがきかない。
スカラレジスタでアドレス指定するベクトル単位のロード・ストアと
scatter/gather
Larrabeeあたりがまさにこれをやってるわけだが。

> あと10年もすればおまえの持ってる小手先業などは博物館の展示資料でしかないし、おまえの能書きなど頑固オヤジの戯言同じなるだろう。

残念だが俺は流行りものの言語・フレームワークには目がない。
Ruby On Railsとか大好きだし。むしろ高級言語をより効率的に使うためにマシン語レベルで理解する必要があるんだよ。
たとえばさ、LLって性能的にはネイティブマシン語より遅いから、LL向けのJITコンパイラ書きたいとするじゃん。
どうしてもアセンブラの知識は必要なんだよね。もちろん業務じゃないよ。
ということでプロ高級言語er、趣味マシン語er
それでARM語もx86語もそれなりにたしなんでおきたいわけ。

492 名前:,,・´∀`・,,)っ-●◎○ mailto:sage [2009/03/09(月) 03:37:32 ]
○んで、個人的にCUDAの問題は、スカラ命令を備えないことなんだよね。


493 名前:デフォルトの名無しさん mailto:sage [2009/03/09(月) 03:52:38 ]
頑固オヤジの戯言ごとと同じになるだろう。

ニート相手に5行も書くの面倒だから誤字脱字なおすのも面倒だよな。
「CISC的」とかいう概念がもう古いパラダイムってこと。
おまえみたいな純粋な「消費者」の戯言などどうでもいいけど、ストリームなのに128/256bits単位とか全く鼻糞だろ。
ストリーム演算やってるのに、「スカラ演算もやりたい!」「アドレッシング!」という考え自体を改めたほうがいいと思うけどね。

どうでもいいけど、ストリーミング・プログラミングの小技を集めたブログをはよ作ってよ。
C#だとスニペットというんだったか?そういうイディオム集みたいのでもいいから。

494 名前:,,・´∀`・,,)っ-●◎○ mailto:sage [2009/03/09(月) 03:59:04 ]
Intelの中の人のブログって言っても、本当に自社製品のプログラミングがらみの話題って
月に1回出るかどうかのレベルだぜ
次期Windowsの話題だったり、XMLやLLなんかのWebまわりの技術がどうこうだったり。
中の人の興味のあることが書いてあるって感じだけど、頭の悪い技術系ゴシップサイト
よりはよっぽど為になる。さすが半導体総合メーカーだわって思うわ。

NVIDIAのニュースも購読してたけど本当に自社製品向けのコンピュータグラフィックスのノウハウとか
グラフィックよりの物理演算が中心で、そっち方面はそんなに深入りする気はないので読む価値なしと。
(そっち方面で食ってる人ごめんなさいね)


495 名前:,,・´∀`・,,)っ-●◎○ mailto:sage [2009/03/09(月) 04:01:57 ]
>>493
> どうでもいいけど、ストリーミング・プログラミングの小技を集めたブログをはよ作ってよ。
> C#だとスニペットというんだったか?そういうイディオム集みたいのでもいいから。
プププププ


496 名前:,,・´∀`・,,)っ-●◎○ mailto:sage [2009/03/09(月) 04:11:02 ]
ソースコード例文をいんたーねっつで検索してきてコピペをするのが
プログラミングだと思ってる人はそう言うのに本質を求めるよね。
いや、いいんだけどね。
俺とて業務では最高級の言語から低級言語で書かれたライブラリを使わせてもらってる立場だし。

497 名前:,,・´∀`・,,)っ-●◎○ mailto:sage [2009/03/09(月) 04:43:49 ]
ちなみにマルチコアとかSIMDを使いこなして最適化コード書いたりできる人間は稀少性があるから
長い目でみれば食いっぱぐれしないよ。

今でこそ団塊COBOLerの後釜需要があったりするくらいだし
(徐々にJavaや.NETに置き換わってるので将来性を考えれば微妙だが)

自動並列化ランタイム環境使えばいいとか言うだろ?
そう言う考えの三流プログラマは食いっぱぐれる。間違いなく。
じゃあその並列化ランタイムは誰が書くんだと。書きもしないのに沸いてくるのかと。
最近流行のJavaScriptのJIT部分のコードでも見てみればいい。各CPU用のバイトコードの山だ。

その点、覚えさせれば小学生でも出来るような、コードをコピペして貼り合わせる能力なんて誰が評価するんだよ。
知識が無いと難しい作業こそ高い市場価値がある。

CUDAはまだ市場として育ってないがな。とがってる分、苦手なことが多すぎて。

498 名前:デフォルトの名無しさん mailto:sage [2009/03/09(月) 05:31:36 ]
俺の団子が火を吹くぜ!



499 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/03/09(月) 05:54:25 ]
っていうか、電子の移動度の限界とか云々でクロックが上がらないのでフリーランチ終焉、
SIMDやマルチコアを明示的に使いこなさないと性能出ませんよ
これ以上1スレッドの負荷の重たいソフト書くなよ、なんて、何年も前から言われてることなのに
「価値がなくなる」だとか何を妄言はいてるんだか。
10年後に100GHzとか200GHzとかいくのかよ。
数十コアとか数百コアになって最適化屋の需要拡大することはあっても、縮小することなんてねーよ

要するにSIMD・マルチコア使いは10年先もナウい。パネェ

500 名前:デフォルトの名無しさん mailto:sage [2009/03/09(月) 06:07:53 ]
最適化できる奴は別にたくさん要らないよなぁ・・・
結局ライブラリ作って終わりだし。
そういうライブラリがなかったり高額だったら、誰も使わないからあまり流行らないわけで、どんどん忘れ去れていく技術なだけだしなぁ・・・
GPUとは関係ないけど、MSの提唱してる技術とかかなり不発が多くて流行らずに忘れ去れてるの多いでしょ。
(スカラの)マルチコアとライバル関係だけど、運が悪いとGPU(ストリーム)の方が流行らずに終わってしまうことだってある。PCってのはそういう世界だったよな。
どうでもいいけど人柱がんばってよ

501 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/03/09(月) 06:10:54 ]
せいぜいコードコピペで済む単発案件こなしてなよ
希少価値のある技術には見えないがね。

どっちかというとコピペプログラミングこそ自動化できそうだけどなぁ
お絵かきツールだけでプログラムのフロー書くASTERIAみたいなツールも出てきてるし

502 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/03/09(月) 06:52:27 ]
既にゲーム業界では下っ端レベルからそういう技術が要求されるようになってるけどね
PS3とか360やってるところなら半ば強制だぜ
脳天気でいられるのは高級言語屋とローエンド組み込みCPUソフト技術者くらい

CUDAは流石に今のポジション以上の普及はないと思うよ
「汎用」ってものをわかってない。

503 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/03/09(月) 07:00:18 ]
GPGPUの【GP】に関してならLarrabeeに食われるだろうね。
たとえば普通のCを使うとして、たとえばtime.hすら使えないのがCellのSPEなら
CUDAはそれ以前の問題だし

504 名前:デフォルトの名無しさん mailto:sage [2009/03/09(月) 07:01:11 ]
スニペットとかコピペってのは、結局コードのモジュール化ってことでしょ。
オブジェクト指向による再利用促進とも言うけど、それは時代の流れって言うよりもう当たり前じゃないのか?
IDEとか便利だし、かゆいところは自分でコード書けばいいんじゃないか。
今の時代、30分で作れるのに一からメモ帳作る奴はよっぽどバカでしょ。

505 名前:デフォルトの名無しさん mailto:sage [2009/03/09(月) 07:03:23 ]
ああ抜けてた。

コピペって簡単に言うけど、典型コードの再利用なわけでだからこそメモ帳アプリが30分で作れる威力があるんだけど。

506 名前:デフォルトの名無しさん mailto:sage [2009/03/09(月) 07:05:53 ]
そういえば、ム板でコテ名乗ってるのは団子ぐらいしかいないよね?他にいるの?

507 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/03/09(月) 07:23:14 ]
>>504
コピペの単純工程をやるプログラマもいれば
ライブラリを書くプログラマもいるわけで

法律事務所のアルバイトと弁護士くらいの格差は出てくるかもね
いや、既に出来てるか

508 名前:デフォルトの名無しさん mailto:sage [2009/03/09(月) 09:07:28 ]
>>505
使い回しでメモ帳に30分ってかかりすぎだろ。3分でやれよ。
テキストコントロール配置してファイル読み書き機能付けるだけで終わりだろ
IDEの雛形だけでほぼ完成なんだからさ

それともGREP機能でも搭載するのか?



509 名前:デフォルトの名無しさん mailto:sage [2009/03/09(月) 09:12:15 ]
30秒だろ

#include <stdlib.h>
int main(void) { system("notepad.exe"); return 0; }


再発明する価値もない。

510 名前:デフォルトの名無しさん mailto:sage [2009/03/09(月) 09:20:05 ]
無いものを作る、あるいは既にあるものをより良くすることに知的労働の価値があるわけで
劣化コピーの再発明で金とるなど馬鹿の所業だろ。

511 名前:デフォルトの名無しさん mailto:sage [2009/03/09(月) 09:42:01 ]
>>509
ワロタw

512 名前:デフォルトの名無しさん mailto:sage [2009/03/09(月) 10:28:29 ]
30分で作れる程度のエディタなんて誰も使いたくないな

513 名前:デフォルトの名無しさん mailto:sage [2009/03/09(月) 12:06:54 ]
なんでおまえらはそのうちいい情報を提供してくれそうな人を叩くんだよ

514 名前:デフォルトの名無しさん mailto:sage [2009/03/09(月) 12:13:14 ]
いい情報を提供するのが自分じゃないと気がすまないからさ。
そのために全体が遅延しても問題なし。

515 名前:デフォルトの名無しさん mailto:sage [2009/03/09(月) 12:28:58 ]
CUDAは既存の一握りのプログラムの再発明のためデバイス・言語処理系だろ。
性能はともかく効率CUDAでできることは普通のCPUでもできる。
より高いスループットを得るためにこそある。
プログラミング対象を選ぶし、性能を出すには工夫がいる。

テキストエディタの話じゃないけど、生産性を言い訳にして自分で創意工夫が出来ない奴には不向き。

516 名前:デフォルトの名無しさん mailto:sage [2009/03/09(月) 12:38:56 ]
,,・´∀`・,,)っ-○◎● に嫉妬してるだけじゃね?

517 名前:デフォルトの名無しさん mailto:sage [2009/03/09(月) 13:34:37 ]
まぁ、団子は必ずしも間違ってはいないからな。
CUDAに未来はないかもしれないけれど、OpenCLはAMDも担いでいるからもう少し生き延びるだろうし。

518 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/03/09(月) 19:05:27 ]
OpenCL(笑)

なんかの魔法の言語のように思ってないか?
OpenCLは「GPU版Java」じゃない。
共通化されてるのは言語の基本仕様の部分だけで、細かいところは処理系依存。

んでもって、CUDAやCAL/Brook+のプログラミングの敷居を高くしてるのは言語処理系じゃなくて
少ないスクラッチパッドメモリとレイテンシの大きいメモリと
やたら小回りが利かないベクタ演算ユニット、その他諸々のGPUのパイプライン・・・
要するにシェーダコアの構成そのものにあるのであって、それが解消されない限り
CPUを置き換えて普及していくことなどあり得ない。

普通のCPUと同じ定番言語のC/C++言語をまがりなりにもサポートしてるのに
業界の評価のお寒いCellを見れば、課題は言語じゃなくて汎用プロセッサとしての
柔軟性にあることくらいわかるだろ?

その意味、OpenCLを効率良く実行できるのはよりCPUに近いLarrabeeだと思うよ。
というか本質的にOpenCLなんて要らない。
どうせCellなんかと同じくハード専用にカリカリにチューニングしなきゃいけないんだし。



519 名前:デフォルトの名無しさん mailto:sage [2009/03/09(月) 19:35:29 ]
>>518
世の中それほどぎりぎりのチューニングまではしないけどちょっとは速く走って欲しいなんて用途が結構あるのよ。
で、私自身はOpenCLはAMDが必死こいてアピールしているだけで実際には普及しないと思っているのよね。
どうせLarrabee出て来る頃にはCtも来ているだろうから、NVIDIAもAMDも青息吐息でしょ。

まぁ、CUDAスレなんだからLarrabeeの待つ未来を語るのは程々にしましょ。

520 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/03/09(月) 19:58:15 ]
期待してなんか無いよ。
Cellと同じくニッチ市場を食い合うだけ。






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<215KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef