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

952 ：デフォルトの名無しさん：2010/11/29(月) 06:15:41

>>947
そういうアイデアはあるが、演算能力がとても足りない

953 ：デフォルトの名無しさん：2010/11/29(月) 11:36:24

標準のH264はエンコードには特許があってフリーソフトなんかには搭載されてない
これは識別子を見るとH264(Video0)のような表記になってる
フリーで出回ってるエンコーダーは主にGPACという開発コードのGPLものをベースにしてるらしい
これはいろいろ種類があるがH264(GPAC ******)とかって識別子のことが多い
GPAC系では標準デコーダーに対応してないものも少なくない

954 ：デフォルトの名無しさん：2010/11/29(月) 14:47:42

>>915
ケイパビリティは1.3あるので大丈夫でした
アーキテクチャの変更を行ったら無事にいけました
ありがとうございます

955 ：デフォルトの名無しさん：2010/11/29(月) 19:35:31

こんにちわ、Visual Profilerがいまいちわからないので質問させていただきます。

Compute_Visual_Profiler_User_Guideを見たのですが、p.53あたりの用語説明がいまいち理解できません。

Tyep.SMとはSM一つだけでカウントされる値、ということでしょうか。とすれば、あるSMでのみカウントされ、ほかのSMでカウントされないのでしょうか。

gld requestとはコアレッシングされた場合、１命令で多くのデータを読み込むと、それは一回とカウントされるのでしょうか。

またL1 global hit とL1 global miss を足し合わせるとgld requestになると思っていたのですが、これらはgld requestと違うタイプ?のカウンタなのでしょうか。

またactive cycle と　active warpsの意味が理解できません。どういう意味でしょうか。

環境はWin7 64bit GPUはGTX480です。

その他visual profilerを見るときに気をつける点、着目すべき点などがありましたら教えてください。
初心者で申し訳ないですが、よろしくお願いします。

956 ：デフォルトの名無しさん：2010/11/29(月) 22:59:24

各カーネルがまったくランダムな場所のグローバルメモリにアクセスせざるを得ない場合、
それはもうCUDAでは書かない方が良いのでしょうか？？

957 ：デフォルトの名無しさん：2010/11/29(月) 23:35:36

>>956
それが本当にランダムなら、ホスト側で順序を変えてから転送できないの?

958 ：デフォルトの名無しさん：2010/11/29(月) 23:44:17

メモリアクセスとCUDAは直接関係ないだろ。
メモリコントローラ次第だろう。

959 ：デフォルトの名無しさん：2010/11/30(火) 00:05:47

>>956
カーネル？
スレッドブロックのこと？？コアレスにできないから遅くて不向きってこと？
扱うプログラムが計算時間メインか通信時間メインかで変わってくる気がする。
実行時間のほとんどが通信時間で占められているプログラムでコアレスにできないなら不向きだよなぁ。

960 ：956：2010/11/30(火) 00:20:33

二体間の距離に対応する10000の配列のテーブルを読みたいです
この計算は10000回どころじゃないくらいやるのですが、演算量が多く、時間がかかるのでテーブルにしています

選ぶ二体の座標はカーネルの順番に応じて順番なグローバルメモリから読み込むので
いい感じに連続だと思うのですが、二体間の距離は実行中にどんどんかわるので
カーネルごとにランダムになってくるとおもいます。

961 ：デフォルトの名無しさん：2010/11/30(火) 00:48:29

読み込みしかしないならテクスチャか足りるならコンスタントメモリつかえばいいんじゃない

962 ：デフォルトの名無しさん：2010/11/30(火) 00:52:04

MDで似たような粒子数でやったけど十分速くなったよ
テクスチャメモリ使って積極的にキャッシュさせれば？

963 ：デフォルトの名無しさん：2010/11/30(火) 21:18:46

>>961
コンスタントはランダムアクセスには効かないお

964 ：デフォルトの名無しさん：2010/12/01(水) 01:11:57

>>961
10000要素をfloatでもたせるとコンスタントメモリにギリギリ収まるけど
>>963の通りコンスタントメモリキャッシュ(8KB)にはのらないな
それでもテクスチャキャッシュよりは速いんじゃね？

965 ：デフォルトの名無しさん：2010/12/02(木) 11:42:04

非fermiでwarp内のスレッドが全部同一メモリにアクセスする場合、
shared memory(broadcast), constant memory, texture memory, global memoryでどれほどの差が出ますでしょうか？
普通ならconstant memoryですがデータが入りきらない可能性がありますので。

966 ：デフォルトの名無しさん：2010/12/02(木) 13:47:20

ゆとりがいるな

967 ：デフォルトの名無しさん：2010/12/03(金) 01:15:00

ゆっとりしていってね!!

968 ：デフォルトの名無しさん：2010/12/03(金) 09:00:30

CUDAプログラミング実践講座 - 超並列プロセッサにおけるプログラミング手法
という本は初心者にお勧めなものでしょうか？

私はC++言語初心者でCUDAに興味が出たレベルの人間です。

969 ：デフォルトの名無しさん：2010/12/03(金) 19:43:25

ＣＵＤＡって将来性がないな
ＣＰＵだとマルチコア＋ＳＳＥなんか使うと別にＣＵＤＡと性能変わらないし
もうすぐ出るSandyBridgeはメニーコアアーキテクチャの前進になる命令セットが既に組み込まれてて
CPUに直結したGPUコアを利用した並列演算が出来るようになってるから
ＣＵＤＡを超えると思われる

970 ：デフォルトの名無しさん：2010/12/03(金) 20:04:16

>>968
並列プログラミングの経験が皆無ならいきなりCUDAはきついぞ
MPIの数倍難しい

971 ：デフォルトの名無しさん：2010/12/03(金) 20:32:56

何に使えるのかを思いつくのが難しいって感じか。プログラミング自体は難しくないもんね

972 ：デフォルトの名無しさん：2010/12/03(金) 20:36:16

>>969
釣られてやるよ
それはGPGPUの使い所の設計が悪すぎるか、まるっきりGPGPUに合わない処理の話だな
ま、従来のシステム開発の延長で考えてもまず無理
プログラミングへの造詣が低いSEには手を出せない代物だよ

973 ：デフォルトの名無しさん：2010/12/03(金) 22:08:36

>>970
CUDAとMPIだとMPIの方が断然難しいだろ。

974 ：デフォルトの名無しさん：2010/12/03(金) 22:20:01

つうか汚い言語だよな

975 ：デフォルトの名無しさん：2010/12/03(金) 22:43:06

専用コンパイラが必要ってところがスマートじゃないんだよな
書式のそれほど拘らなければＣ＋＋標準のまま外部ライブラリとして出来たと思うんだけど
OpenCLはライブラリ形式なのはいいがソース丸見えだしなんだかな

976 ：デフォルトの名無しさん：2010/12/03(金) 23:02:59

>>973
一般人とお前の頭だとお前の頭の方が断然悪いだろ。

977 ：デフォルトの名無しさん：2010/12/03(金) 23:12:09

>>971
まるで的外れなこと言ってるな
扱うシステムのサイズに対する計算量とかで向き不向きは大体分かる
チューニングの難しさも扱う問題によって全く変わる

978 ：デフォルトの名無しさん：2010/12/03(金) 23:54:10

>>969
IntelさんはLarrabee出せなかったよね・・・（´・ω・｀）

979 ：デフォルトの名無しさん：2010/12/04(土) 01:44:22

>>972
まあ、CUDAは用途が限られているからなあ。
ある程度並列度が上がる計算じゃないと今の最新のCPUとじゃ、
あまりアドバンテージがないのも事実。
いわば直線番長なんだよ。

>>プログラミングへの造詣が低いSEには手を出せない代物
これはちょっと違うと思うな。
チューニング技術があまりないならCUDAに手を出したほうがいい。
Fermiなら大抵は早くなるだろうから。

980 ：デフォルトの名無しさん：2010/12/04(土) 02:40:50

SandyBridgeだかLlanoだか知らんが、CPUやCPU内蔵GPUと、ディスクリートGPU(=CUDA/Stream)は同時に動作させることが出来る

981 ：デフォルトの名無しさん：2010/12/04(土) 03:26:08

OpenCLで書いておけば、AVXにもGPUにもSSEにも対応できる。

982 ：デフォルトの名無しさん：2010/12/04(土) 09:37:02

OpenCLであるハードに実用的なスピードが出るくらい
最適化したカーネルコードは、基本的に別のハードでは使い物にならないよ。

983 ：デフォルトの名無しさん：2010/12/04(土) 10:07:13

ゲロフォースでしか動かない苦ニダよりはマシ

984 ：デフォルトの名無しさん：2010/12/04(土) 10:32:06

ＣＵＤＡのネックはＰＣＩＥのメモリ帯域でいくらＧＰＵが早かろうが何の意味もない
SandyBridgeのAVXはＰＣのメインメモリに直接アクセスするから
Larrabee前のGPU仮実装品でさえCUDAを超えた性能を出してるし

985 ：デフォルトの名無しさん：2010/12/04(土) 10:34:29

AVXってSSEでしょ
そんな餌じゃ釣れないよ

986 ：デフォルトの名無しさん：2010/12/04(土) 10:36:25

もうそういう設計能力の低さを晒すの止めろとけよ
GPUは用途が限られて万能じゃないんだし、それも分からん低能は使わないほうがいい
ある特定分野では素晴らしいパフォーマンスを発揮するのがGPU

987 ：デフォルトの名無しさん：2010/12/04(土) 10:39:18

たとえばあれだな
SDKにmulMatrixという行列積の問題があるから
あれをCPUでGPUより高速に計算できるコードが書けるか試してみることだな

988 ：デフォルトの名無しさん：2010/12/04(土) 10:59:40

どうせチューニングはデバイスごとに行なわなければならないからOpenCLのメリットは薄い。
CUDAなんて実装自体は難しくないんだから、自分の頭の悪さを嘆く暇があったらThrustでも使ってみればいい。

989 ：デフォルトの名無しさん：2010/12/04(土) 11:03:10

倒産寸前ゲロビデア専用言語なんかを覚えるのは時間の無駄

990 ：デフォルトの名無しさん：2010/12/04(土) 11:06:19

だからさぁ、そうやって固有名詞を弄って悦に入るくらいだから覚えられないんだってば。
普通はCUDAの文法くらい一時間あれば覚えられるだろ。使いこなすのは数ヶ月掛かるにしても。

991 ：デフォルトの名無しさん：2010/12/04(土) 11:06:33

>>979
>チューニング技術があまりないならCUDAに手を出したほうがいい。
>Fermiなら大抵は早くなるだろうから。

何と比べて早いと言ってるのか分からんが少なくとも価格性能比だと
core i7 920で３万、tesla C 2050で２７万(2070なら４０万以上)
もしCPU16コアとGPUボード16枚で比べるなら36倍以上高速化しないと
得にはならないぞ。

992 ：デフォルトの名無しさん：2010/12/04(土) 11:09:35

元のプログラムがタコならそのくらいは速くなるな。
でもその過程で得られたノウハウでCPU向けにチューニングしたら差は縮むわけだけどw

993 ：デフォルトの名無しさん：2010/12/04(土) 11:16:53

プログラマを無給で使い捨てにできる大学にはいいよね。
今ちょっと名前の出てる学生達の１０年後を見てみたいね。

994 ：デフォルトの名無しさん：2010/12/04(土) 11:27:57

うわ、チップ単体とボードの値段比べてる馬鹿がいる・・・

995 ：デフォルトの名無しさん：2010/12/04(土) 11:55:49

>>987
CUDAのネックはメモリ転送だって言ってるのに
メモリ転送がない行列積なんて非実用的な例で競争しても意味ないだろ
エンコードにしても、画像処理にしてもメモリ転送が一番ネックなんだから

996 ：デフォルトの名無しさん：2010/12/04(土) 13:05:03

>>993
大学院とか授業もほとんどないのに金払って教授の手足になってるからな～
せめて授業料免除くらいにはして欲しいもんだ

>>994
ボード同士で比べればいいのか？

997 ：デフォルトの名無しさん：2010/12/04(土) 14:17:31

だからメモリ転送はメモリコントローラの問題であって、
CUDAと関係ないっつーの。