08/11/01 10:12:52
・グローバルメモリアクセスは、最大400(?)クロック掛かるが、最短では4クロックで済む。
# そのためには、coalescedにアクセスできるように工夫する必要がある。
・各ストリーミングプロセッサは、独立して動作する。Sharedメモリも同様。
例えば、行列の転置のような処理の場合、普通に書くとcoalescedに読んでincoherentに書かざるを得ない。
# 或いはその逆か。
そこで、CUFFT内で行なっている転置処理では、(プロファイルで見る限り)一旦共有メモリにおいて同期を取ることで、
読み書き共にcoalescedアクセスを維持しているようだ。
283:デフォルトの名無しさん
08/11/01 18:40:52
>>282
早速のレス、さんくす。
なるほど、最短４クロックですか。coalescedにしてもレイテンシー
だからだめかなって思ったけど、よくよく考えると、DRAMへの直接
アクセスに数百クロックってのはおかしいことに気づいた。
各ストリーミングプロセッサは、独立だけど１インストラクション単位で
同期してるんじゃないんかな（んなことぁない？）
・・・っておもったけどブランチがあるから、TPXレベルから見ると独立か???
最初見たときSharedメモリも他のSPのregも０レイテンシで使える
ようだったんで、演算と独立にグローバルメモリとのロード、ストアができん
１６K程度のSharedメモリ、あまり意味ないじゃんとかおもったけど、
そんなことなさそだね。
なかなか面白そうなチップだ。
分岐粒度が32って実際、汎用でどうなんだろ。
ベクトルつかったことないんでわからんが、
適当にセルオートマタでも乗っけて遊んでみまつ。
284:デフォルトの名無しさん
08/11/12 22:42:34
CUDA-Zなんて便利なものがありました。
forum.nvidia.co.jp
285:デフォルトの名無しさん
08/11/12 22:55:32
>>284
kwsk
286:デフォルトの名無しさん
08/11/12 23:19:24
URLﾘﾝｸ(cuda-z.sourceforge.net)
287:デフォルトの名無しさん
08/11/14 19:39:30
あげてすまん。
CUDAのためにGTX280つきのPCかったのだが
ほかにもう一枚グラボ買わないといけんのかな？
あとPCIバスしか残ってないのだが・・・
LINUXで使う予定。
288:デフォルトの名無しさん
08/11/14 22:57:10
>>287
別に一枚でも大丈夫。二枚挿しても(開発には)却って面倒だったり。
まぁ、二枚あれば表示に足引っ張られる心配なくなるから安定はするけどね。
289:デフォルトの名無しさん
08/11/15 00:41:03
>>288
そうなのか、安心した。
ありが㌧
290:デフォルトの名無しさん
08/11/15 17:39:36
質問です。
float にてゴリゴリ計算して、結果を返すプログラムを書いてみたのですが、
普通のアルゴリズム、CUDA+GPU、CUDA+CPU(deviceemu) の2つで比較して
みたところ、思ったより差が大きいのですが、こんなもんですか？
もしくは、機種依存があったりするんでしょうか？
291:290
08/11/15 17:40:23
>>290
すいません、間違えました。
「2つで比較して」->「3つで比較して」
292:デフォルトの名無しさん
08/11/15 19:43:01
何の差?
演算精度なら、そりゃぁあるさ、floatなんだもの。
293:デフォルトの名無しさん
08/11/15 20:51:43
ホストは、デフォルトではfloatをfloatで計算してくれないからな。
SSEを使うなりで、ホストがちゃんとfloatで計算すれば、結果は一致するんジャマイカ？
294:デフォルトの名無しさん
08/11/15 20:57:47
>>293
一致する保証はないよ。CUDAのドキュメントにもあるけれど、超越関数はGPU内部の組み込み版を使うと若干誤差が残る。
いずれにしてもfloatの想定の範囲内だから、実用上は問題にならないけどね。
295:,,・´∀｀・,,）っ-●◎○
08/11/15 22:26:10
x87 SSE CellB.E. CUDA の浮動小数サポートの対比表みたいなのがCUDAのマニュアルにあったな。
確かに完全じゃない。
糞まじめに準拠してるのはx87くらいだ
296:290
08/11/16 02:56:28
>>292-295
なるほど。出てきた結果が、CPU上の double で計算した結果と、
GPUの float で計算した結果が、最大1%程度違ったから、正直
驚きました。普段doubleしか使って無くて、誤差なんかほとんど
気にしなくてよかったので。
誤差が蓄積してくようなタイプのアルゴリズムではないと思っていた
だけに、少し驚きました。
297:デフォルトの名無しさん
08/11/20 18:53:51
Cで使っていた自作ライブラリは、
nvccでコンパイルし直さなきゃダメなの？
298:,,・´∀｀・,,）っ-○◎-
08/11/20 18:58:40
食べてみたけどおいしかったよ。
一つどうぞ、あーんして
299:,,・´∀｀・,,）っ-●◎○
08/11/20 19:44:47
飾りだ、食うなボケ。
300:,,・´∀｀・,,）っ----
08/11/20 21:36:00
僕のもうないです
>>299から貰ってね
301:デフォルトの名無しさん
08/11/20 23:10:32
>>297
ホスト(CPU)上で実行させるものならVC++と一緒にリンクできる。
（cppIntegrationサンプル参照）
GPU上で実行させたいならそれなりにいじくらないと無理。
302:デフォルトの名無しさん
08/12/01 15:16:29
-deviceemuでは動くプログラムが、GPUを使うと誤動作します。
__device__関数に引数が一部しか渡らなくなります(float4のz成分だけしか渡せない)
ループ回数を極端に減らすと改善されるのですが、これはregisterメモリがパンクしてしまったということでしょうか？
303:デフォルトの名無しさん
08/12/01 17:15:56
ソースを見ないとなんとも言えませんが、ループ回数とregisterは依存関係にはありません。
nvcc -ptxでptxファイルを出力して眺めてみては如何でしょう。
304:デフォルトの名無しさん
08/12/01 23:02:30
ptxファイルですか。。。
正直どこをどう見たらいいのかわからないので敬遠していましたが、
遂に避けられないとこまで来てしまいましたかねえ。
見るべきポイントとかありましたら、よろしければ教えてください。
305:,,・´∀｀・,,）っ-●◎○
08/12/01 23:09:56
ptxもネイティブコードじゃなしに中間コードの断片だからな。
レジスタが何本割り当てられるかとかそういった情報すら持ってないから困る。
その点Larrabeeは16本+16本+αとかレジスタ本数が決まってて
コード生成時点で割り当てが決まってしまう。
結果的に静的な最適化がしやすい。
良し悪し。
306:デフォルトの名無しさん
08/12/02 13:02:50
ﾘｮｳﾃﾆ●ヽ( ・∀・)ﾉ● CUDA！
307:デフォルトの名無しさん
08/12/03 17:58:11
.oとかにしてgccでリンクすることってできますか？
308:デフォルトの名無しさん
08/12/04 00:09:51
>>307
何を? どこで? なんで質問もろくにできないの?
ちなみに、エスパー募集ならお門違い。
309:デフォルトの名無しさん
08/12/04 00:52:30
>>307
普通にできますよ。
-l/usr/local/cuda/lib -lcudart
等のオプションは当然自分で追加する必要があります。
310:デフォルトの名無しさん
08/12/04 06:13:34
Windowsで、とかいう話だったりしてね。
311:デフォルトの名無しさん
08/12/04 10:05:39
.objじゃなくて.oって書いてあるんだからそれはないんじゃない？
312:デフォルトの名無しさん
08/12/04 22:31:14
それだったらわざわざ聞くかねぇ。まぁいいか。
313:デフォルトの名無しさん
08/12/12 18:47:36
【GPGPU】CUDA/ATI STREAM 速度・画質検証スレ
ｽﾚﾘﾝｸ(jisaku板)
314:デフォルトの名無しさん
08/12/14 19:30:29
これからCUDAを始めようといろいろサイトを巡回しているのですが、
グリッドサイズとブロックサイズはどのようにして決めたらいいのでしょうか?
同期をとるかとらないかで変わると思いますが、とりあえずとらない場合でお願いします。
315:デフォルトの名無しさん
08/12/14 20:41:30
>>314
BlockSize(スレッド数)は32の倍数で余り大きくない辺り。GridSize(ブロック数)は充分大きく。
316:デフォルトの名無しさん
08/12/14 21:31:49
>>315
ありがとうございます。
もう一つ質問させていただきたいのですが、たとえば、512x512のようにブロックサイズ、グリッドサイズ
ともに最大値未満の場合、<16, 32, 1>のように複数の次元に分けるのと、<512, 1, 1>のように1つの次元
にまとめるのとどちらがいいのでしょうか?
多分通常はブロックサイズは各次元の最大値<512, 512, 64>をオーバーすることが多いと思うので、こちらは
分けることになると思いますが、グリッドサイズの最大値は<65536, 65536, 1>もあるので、
次元を分けなくてもいいときは分けない方がいいのでしょうか?
317:デフォルトの名無しさん
08/12/14 22:01:51
threadサイズが実際の分散処理の単位になる
つまりthread数だけ並列演算が行われる
例えばthread(1)にしてblock(10)とかだと順次処理と変わらない
ただしthreadは256までしか出来ないのでblockという単位が容易されてる
blockは単にプログラムがやりやすいように用意されただけのもので
実際に分散処理には影響しない
318:デフォルトの名無しさん
08/12/14 22:15:42
>>316
言いたいことがよく判らんが、演算量が512x512ならブロックを8x8にしてグリッドを64x64でいいんでない?
或いはxyの区別が重要でないならブロックを64、グリッドを4096とか。
私は後者の方針でptxファイルの出力とプロファイルの結果を睨みながら決定することが多いけど。
# 横着するときは前者だなぁw
319:デフォルトの名無しさん
08/12/14 22:17:30
>>316
単に内部ループが
for(x=0;x<?;x++){}
_global_
か
for(x=0;x<?;x++){
for(y=0;y<?;y++){
_global_
}
}
になるかの違い
320:デフォルトの名無しさん
08/12/14 22:24:34
元の位置を特定する為にglobal関数でインデックスを計算することになるから
もしxやyのどちらかで収まるなら１つだけ使うのが良い
global関数内部の計算コストが一番ネックになる部分だからね
インデックスの計算部分が一番邪魔で削れるだけ削った方が良い
321:デフォルトの名無しさん
08/12/14 22:35:25
>>317,319
ありがとうございます。ようやく喉のつっかえが取れました。
>>318
試しに昔書いた画像処理のコードを移植しようとしていたのですが、入力によって
いろいろサイズが変わるので、512x512で固定するのはちょっとやりづらいかなと…
ただ、ここまでの話からするとchannel(RGB)*height*widthの三次元配列に画像をつっこんで、
grid = <height, channel, 1>
block = <32, width / 32, 1>
で処理を回せそうですね。画像の幅をを32の倍数に合わせる必要はありそうですが。
>>320
ありがとうございます。実際に使うときは上のような感じにブロックとグリッドの数を決めようかなと
思いますが、どうでしょうか?
322:デフォルトの名無しさん
08/12/14 22:59:47
heightは超えてもいいの？
範囲は内部でインデックスが範囲かどうか判定するよりは
端数を含めたメモリを確保して必要無い部分も計算させてしまった方が速いよ
323:デフォルトの名無しさん
08/12/14 23:22:38
>>322
そこまで大きな画像を入れるかどうかは分かりませんが、確かに高さが65536を
超える場合は分割してやる必要がありますね。
>端数を含めたメモリを確保して必要無い部分も計算させてしまった方が速いよ
ということは、配列にコピーするときに幅を合わせてコピーするのではなく、後ろに空白部分を
まとめた方がいいということでしょうか?
#これって多次元配列を引数に渡すのってどうするんだろう…
324:デフォルトの名無しさん
08/12/15 00:01:31
いや、最終的には全て一次元の配列でそれが適切な間隔でアクセスされるように並んでいるのが一番いいことになる。
だから、画像なんかの場合だと座標値に意味がないなら詰め込んで構わない。
実際には、コンボリューションフィルターなどで隣の画素を参照しないといけないことが多いだろうけど、
その場合はどうせ共有メモリを使ってアクセスを減らすなどの工夫が必要だからどの途32の倍数に拘る必要はない気がする。
325:デフォルトの名無しさん
08/12/15 00:50:40
論文用のならともかく普通の画像処理で画像サイズが固定されてることはまずないし
サイズも共有メモリじゃとても足りない
共有メモリを使うならCPUサイドであらかじめ画像を分割して渡すという方法しかないけど効率悪いよ
毎回隣接した画素情報も含めないといけないから
326:デフォルトの名無しさん
08/12/15 01:06:12
>>324
カーネルサイズにもよりますが、sharedメモリはちょっとサイズ的にきつそうですね…
constantメモリならブロックサイズを調整すれば何とかなるかも?
>>325
単なる趣味グラムなので、ぶっちゃけ全部globalメモリからとってきてもいいような気がしたのですが、
逆にそれだとCPUで処理するよりも遅くなりそうですね
327:デフォルトの名無しさん
08/12/16 01:54:49
遅くなりそうというかどんだけがんばっても最終的にはglobalメモリを使うのが一番早いという結論になるよ
まあそれがGPGPUの一番のネックなんだけどね
CPUサイドのメモリを共用するようにいずれはなるんだろうけど今の限界はそこ
328:デフォルトの名無しさん
08/12/16 06:11:12
一番(手っ取り)早いのは同意するが、一番速いとは限らない。
それこそ、思考放棄じゃないかな?
329:デフォルトの名無しさん
08/12/19 00:31:55
詰まってます、助けて・・・
私はVS2005で開発しようとカスタムウィザードを入れ、ツールキットとSDKをインスコし
パスも通したのにLNK1181エラーでるんです・・・存在しないオブジェクトファイルを指定するのはなぜでしょう？
ライブラリパスがみつからないってどういうことなんでしょうか？
330:デフォルトの名無しさん
08/12/20 01:37:50
"Program" "Files"と認識してるとか
331:デフォルトの名無しさん
08/12/20 02:38:31
Windowsってなんで重要なディレクトリ名にスペースなんか入れるんだろう。
MSって頭悪いの？
332:デフォルトの名無しさん
08/12/20 04:16:06
低脳を排除するためかもねｗ
333:デフォルトの名無しさん
08/12/20 05:06:25
プログラマお断り。ずっと消費者で居てくだちい。
334:デフォルトの名無しさん
08/12/20 06:27:59
デスクトップやマイドキュメントのスペースや半角カナフォルダはなくなったが、Program Filesはそのままだな。
335:デフォルトの名無しさん
08/12/20 09:43:22
>>331
その昔１６ビットＯＳが主流だったころＭ＄は８文字ファイル名しか扱えなかった
そしてUnix系ＯＳは既にロングファイルネームに対応していた
そこで登場したのが32bit Window 95だった
長いファイル名が使えるんだぞ、凄いんだぞと新発明でもしたかのように宣伝していた
そして自慢げにフォルダ名を無駄に長くした
336:,,・´∀｀・,,）っ-●◎○
08/12/20 12:23:53
VistaはUNIXerには優しくなったな。
上位エディション限定だけどSUAも使えるし
337:デフォルトの名無しさん
08/12/20 20:39:06
CUDAをさ、VS2005で使えてる人っているの？
つか、なんで英語のマニュアルしかないんだよ。わかんねーよ
338:,,・´∀｀・,,）っ-○◎●
08/12/21 00:44:02
むしろ2005以外でどうやって使うんだ？
2.1βで2008対応したけど
339:デフォルトの名無しさん
08/12/21 00:58:06
>>338
おお、それはいいこと聞いた
やっと2005アンインストールできる
340:デフォルトの名無しさん
08/12/21 01:37:02
>>338
どこか日本語で環境設定を教えてくれるサイト知ってたら教えてくれ・・・
341:デフォルトの名無しさん
08/12/21 01:55:48
環境設定なんか何も要らんがな。スクリプト走らせるだけ。
bashのバージョンによってはウォーニング出るけど、ちゃんと動く。
スクリプト猿にも成れないとは、どんだけゆとり脳なんだよ?スポンジなの?
342:,,・´∀｀・,,）っ-●◎○
08/12/21 10:35:26
どのみちあの程度の英語が読めない人に優れたプログラミング書くのは無理だと思うんだ。
俺の私的な業務の手伝いしてくれるなら日本法人さんに代わりにチュートリアルとかの要求
してあげてもいいんだけど、職権乱用か。
>>340 ここで解らなかったらもう諦めたら？
URLﾘﾝｸ(chihara.naist.jp)
343:デフォルトの名無しさん
08/12/21 11:55:12
どうでもいいけど、↑のURLは「disp_content」を削らないとエラーになった。
344:デフォルトの名無しさん
08/12/21 12:58:13
>>340
サンプルプロジェクトを開いて設定を見て勉強するのがいいよ
345:デフォルトの名無しさん
08/12/24 12:51:08
英語読めないのにプログラミング言語してる男の人って・・・
346:デフォルトの名無しさん
08/12/24 18:35:50
英語に優越感もってるやつって、さもしいな
347:デフォルトの名無しさん
08/12/24 19:03:01
>>345
可愛いもんだよねｖ
348:デフォルトの名無しさん
08/12/24 23:58:39
英語なんて誰でも１ヶ月もあればある程度は読めるようになるよ
出来ないと思い込んでやろうとしないだけで
349:デフォルトの名無しさん
08/12/26 12:46:32
vs2005の環境で拡張子cuの場合、定義参照はできるのですが、
インテリセンスが機能しません。freeとかvcのランタイムも同様に
機能しないのですが、やり方分かる方いますか?
ツール->オプション->テキストエディタ->ファイル拡張子にcu c++として
登録するとできるのは上記だけです
350:デフォルトの名無しさん
08/12/26 22:27:18
いっそ、nvccの拡張機能以外は全部cppでやったら?
351:デフォルトの名無しさん
08/12/27 05:03:22
それがスマートだね
352:デフォルトの名無しさん
08/12/27 17:53:02
質問です。
VC++2005で開発する際に、コマンドプロンプトにデバイス名も含め一切文字を表示させたくないのですが、どのようにすればよいでしょうか？
353:デフォルトの名無しさん
08/12/27 18:38:27
>>352
長いパス名が邪魔なだけなら set PROMPT=$G とか？
354:デフォルトの名無しさん
08/12/27 18:47:25
>>352
CUTILを使うと標準出力があるって話なら、リダイレクトするかCUTILを使わなければいいと思うのだが。
355:デフォルトの名無しさん
08/12/28 01:33:08
プロンプト出したくないって話なら_tmainじゃね
356:352
08/12/28 02:53:51
>>353-355
回答ありがとうございます。
>>353
質問があいまいですみません。
パス名が邪魔、ってわけではないです。
>>354
おそらくこの指摘にあてはまるのだと思います。
＞リダイレクト
リダイレクトしても、コマンドプロンプトに表示が出てしまいます。
＞CUTIL
cutil.hを使わずに、cutil.hで提供されている関数を使わない方法、もしくは、代替可能なヘッダーファイルはありますか？
>>355
_tmainを使ってしまうとWindowsでしか使えないソースコードになってしまうので、別の方法があれば教えてください。
357:352
08/12/28 02:55:28
自己レスですｗ
誤：cutil.hで提供されている関数を使わない方法
正：cutil.hで提供されている関数を使う方法
の間違いです。
358:デフォルトの名無しさん
08/12/28 03:10:48
system("cls");
とか
359:デフォルトの名無しさん
08/12/28 10:49:28
>>356
> _tmainを使ってしまうとWindowsでしか使えないソースコードになってしまうので、別の方法があれば教えてください。
Windows かどうかで #ifdef するくらいは許されるんじゃないの？
360:デフォルトの名無しさん
08/12/28 14:29:28
プロジェクトの設定でWindowsアプリにすればいいだけでしょ
361:デフォルトの名無しさん
08/12/28 14:32:32
>>_tmainを使ってしまうとWindowsでしか使えないソースコードになってしまうので、別の方法があれば教えてください。
mainだろうがWindows依存部分のコードが発生するのは当たり前でしょ
CUDAの部分とC++の部分とWindows依存部分とファイルを分離するのが鉄則だよ
複数の環境で使う場合は#ifdefプラグマを使って分離したWindows依存部分の
#includeを切り替えるようにするだけ
362:デフォルトの名無しさん
08/12/28 17:29:43
コンパイラのオプションで指定できるでしょ
環境ごとにmakefile書くだけじゃね
363:デフォルトの名無しさん
08/12/28 17:48:49
>>361
#ifdefはいつからpragmaになりましたか?
364:デフォルトの名無しさん
08/12/28 17:53:47
>>363
#ifdefディレクティブと言いたかったんじゃないの?
で、使い慣れない言葉なんでつい間違えたと。
句読点もちゃんと使えないようだし、日本語に慣れていない三国人なんでしょ。
365:デフォルトの名無しさん
08/12/28 22:36:27
cudaのMDコードどこかに追ってませんか？
366:デフォルトの名無しさん
08/12/29 12:11:23
たった1行でここまで意味不明なのも凄いな。
367:デフォルトの名無しさん
08/12/29 12:24:23
×追ってませんか？
○オッドアイいませんか？
368:デフォルトの名無しさん
08/12/29 13:39:38
>>365氏はcudaで書かれたMD(分子動力学）コードどこかに落ちてませんか
と聞いてるのかと。当方も知らないので答えられませんが。
Fortranで書いたものを全部はアレなのでGPU上で実行したいサブルーチンだけ
Ｃに変えてCUDAで動かしたいのですが、そんな例とかは落ちてないですかね。
mainルーチンその他関係ないところまで全部Ｃに移植するのが嫌ってだけな
んですが。あ、当方はIntelFortran使用。
当方まだCUDA触りたて、試しにSTREAM BMTのtriadだけ手で適当に書いて
GeForce9600GTで40GB/s弱（効率7割弱）のメモリバンド幅。あ、じゃもうでき
るじゃんとか勝手に思い、Fortranのコードに挑もうとしてあえなく止まってますorz
369:デフォルトの名無しさん
08/12/29 14:08:06
つURLﾘﾝｸ(www.easize.jp)
370:368
08/12/29 14:20:59
>>369
ありがとうございます。m(_ _)m
多次元配列はどのみちGPU上では一次元化するつもりでしたがなるほど。
参考にさせていただきます。
371:デフォルトの名無しさん
08/12/29 14:45:46
>>369
そのページ、ポインタの扱いがメタメタだな
わかってるなら別にいいが
372:デフォルトの名無しさん
08/12/29 14:49:43
うん、ぶっちゃけ「"cuda fortran"でぐぐって一番上に来たリンク貼り付けただけ」なんだ、すまない
373:デフォルトの名無しさん
08/12/29 14:50:01
何か普段使うものをCUDAに移植しようと思いつつ適当な物が見当たらない
374:デフォルトの名無しさん
08/12/30 02:15:09
ぶっちゃけ、俺もそうなんだよね。おまけで付いて来たサンプル書き換えて
動かしてFLOPSベンチしてるだけ。
CUDA動かす環境をコスパ良く構築するには?と考えて色々やってみたが、
構築した環境で動かすモノって、結局サンプルの改造ばっか。まんまと
nVidiaの販促戦略に乗せられたぜw
375:デフォルトの名無しさん
08/12/30 08:50:29
zip圧縮とかjpg圧縮とかを移植したらライセンスの関係はどうなるの？
376:デフォルトの名無しさん
08/12/30 12:52:04
圧縮アルゴリズムに関しては問題ないんじゃね？
377:デフォルトの名無しさん
09/01/19 15:08:44
CUDAプログラミングモデルの概要
URLﾘﾝｸ(http.download.nvidia.com)
CUDAプログラミングの基本（パート I - ソフトウェアスタックとメモリ管理)
URLﾘﾝｸ(http.download.nvidia.com)
CUDAプログラミングの基本（パート II - カーネル)
URLﾘﾝｸ(http.download.nvidia.com)
378:デフォルトの名無しさん
09/01/21 03:21:23
デバイス側に確保したメモリにホスト側から
cudaMemcpyのように一括でコピーするのではなく、
一部分だけコピーする、又は書き換える良い方法がありましたら教えてください。
379:デフォルトの名無しさん
09/01/21 03:28:19
・cudaMemcpy()で一部分だけコピーする。
・cudaMemset()で（ｒｙ
・そういうカーネル関数を用意して呼び出す。
380:デフォルトの名無しさん
09/01/21 12:27:16
一部分だけってのはたいてい順次処理になるからCPUにやらせたほうが有利だよ
381:デフォルトの名無しさん
09/01/22 01:33:54
CUDAのプログラミングでZIPアーカイブのパスワード解析とか、早くなりませんかねぇ。
エンコード/デコードに使えるんだから、どうなんでしょう？
382:デフォルトの名無しさん
09/01/22 06:38:19
CUDAのfortranサポート予定ってGPUカーネルの部分をfortranライクに
書けるようになるって理解でいいのかな？2.0からって見かけたけど、それっぽい記述が全く無い…
383:デフォルトの名無しさん
09/01/22 08:47:26
>>379-380
ありがとうございました。
参考にさせていただきます。
384:デフォルトの名無しさん
09/01/22 19:18:17
>>381
総当りか辞書型か知らんが演算能力よりI/Oの問題だろ普通。
385:デフォルトの名無しさん
09/01/22 20:12:54
>>381
早くなるよ
386:デフォルトの名無しさん
09/01/23 00:20:22
>>384
ファイル数が多い場合はI/Oも問題になるかもしれませんが、
ある程度のサイズであればWindowsでもメモリに読み込むので、
それほど問題にならないのでは？
毎回物理的に読みに行くわけではないし。
387:デフォルトの名無しさん
09/01/26 09:28:38
ファイルI/OじゃなくメモリI/Oなのでは？
388:デフォルトの名無しさん
09/01/28 11:49:27
>>387
お前は何を言っているんだ
389:デフォルトの名無しさん
09/01/28 12:47:12
>>388
pciバスつかうんだろ？
立派なioとおもうが
つかクーダってほんとマイナーなんだね。
390:デフォルトの名無しさん
09/01/28 13:18:14
そりゃNVIDIA限定だからだろ？グラボを選ぶのなら汎用的なアプリは作れない。
CUDAよりもっといろんなグラボに対応しているOpenCLへのつなぎに過ぎないよ。
391:デフォルトの名無しさん
09/01/29 00:08:14
ZIPのパスワード解析にZIPファイル全体へのアクセスが必要だと勘違いしてる馬鹿ｗ
392:384
09/01/29 08:00:22
>>381-391
ああ、俺がぼけてた。なんか知らんけど自分でもなんであんなレスつけたんだろ orz
わけわからない流れにしちまって、すまん。
正しくはこうだな。↓
パス解析では総当りにしても辞書にしてもforなどのループ速度が求められるだけで、
CUDAによる計算は意味があるのかい？と思った。
MD5とかデータから導き出す数値ならば本当の意味での解析だから意味ありそうだけど。
393:デフォルトの名無しさん
09/01/29 23:02:34
こんな記事もあるしな
GPUを利用した無線LANのパスワードクラッキングが主流に
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
394:デフォルトの名無しさん
09/01/30 03:18:20
>>393の言ってるのはまさに本当の意味での解析ってやつだしな。
WPA/WPA2-PSKからの復元は総当り/辞書比較と違ってGPGPUにする意味がある。
395:デフォルトの名無しさん
09/02/01 15:41:49
Catalystだけど、トリップ検索は随分速くなるみたい
URLﾘﾝｸ(sourceforge.jp)
396:デフォルトの名無しさん
09/02/02 21:51:40
ホスト側でconstantメモリを動的に確保できないのでしょうか？
方法がありましたら教えてください。
397:デフォルトの名無しさん
09/02/02 22:44:30
>>396
目的が良く分からないのでなんとも言えませんが、
どうせ64KBしかないのだから静的に64KB確保しておくのではだめなのでしょうか。
398:デフォルトの名無しさん
09/02/02 22:54:45
>>396
あるけど、なんでprograming guide読まないの？？
399:デフォルトの名無しさん
09/02/02 23:59:28
>>397
静的に確保しておいてもよかったんですが，綺麗にかけるならとw
>>398
一度目を通したつもりでしたが，素通りしていたようです。
もう一度読み直してきますm(_ _)m
400:デフォルトの名無しさん
09/02/06 00:08:13
誰かZIPの暗号解析ツール作って＞＜
それか解析のループ部分だけうｐしてくれたら、カーネルは俺が書きます。
401:デフォルトの名無しさん
09/02/06 06:54:02
総当りするだけならどっかのオープンソース実装の
パスワードチェックと復号ルーチンとってくればいいだろ
402:デフォルトの名無しさん
09/02/06 10:20:56
ただでさえ消費電力がデカイのにパスワード解析に何週間も動かしてられっかｗ
403:デフォルトの名無しさん
09/02/07 16:57:19
超解像のような考え方は昔からあるようだな
フリーソフトImageD2
URLﾘﾝｸ(www.tiu.ac.jp)
これは時間軸方向にも参照するものだ。
NVIDIAのMOTIONDSPと同じ考え方だな。
西川善司の大画面☆マニア 第113回 超解像
URLﾘﾝｸ(av.watch.impress.co.jp)
この方法は数フレームを参照することで低解像な映像のブレから情報量をアップさせるようだが、
この方法だとシーンチェンジやめまぐるしく動く映像では逆効果でめちゃくちゃな映像になるのではないか？
（これは上記のフリーソフトの別ページでも注意点として載っていた）
でも東芝などの日本の各社がやってる1フレームだけで行う超解像はそもそも無理がある。だから不自然な画質になったり、情報量が逆に消失したりする。
Lanczosなどでそのままアプコンしたほうがずっと情報量あるし自然な画質だ。比較してみれば一発で分かる。
URLﾘﾝｸ(plusd.itmedia.co.jp)
ここの元画像を720×480にし、それをAVIUTLなどでLanczosでフルHDにしたもののほうがずっと綺麗。
超解像は単純な処理だから柵とか崩れてるし、文字も駄目だし、元からあった情報を処理によって消しちゃう副作用のほうが強い。
超解像、超解像と目新しくいって盛り上げようとしたいのは分かるが、こんなのはまやかしだよ。
URLﾘﾝｸ(www1.axfc.net)
比較用画像もうｐしておいた
一方、数フレームでやる方法は計算が大変だが、シーンチェンジや盛大な動きの問題さえクリアすればかなり使えそうではある。
MOTIONDSPや↓はそのあたりちゃんとクリアしているのだろうか？
URLﾘﾝｸ(www.flashbackj.com)
404:デフォルトの名無しさん
09/02/07 17:01:19
10年ぐらい前にカーネギメロン大学で勉強してた頃に超解像のプログラム作れっていう課題を出されたことがある
405:デフォルトの名無しさん
09/02/07 17:34:44
ちょー解像は判ったからマルチすんなや。
406:デフォルトの名無しさん
09/02/07 20:13:09
>>403
スレ違いじゃない？
GPGPU 向きな処理なのは確かだし、そもそも Cell なり SpursEngine は GPU じゃないし。
画像処理スレとかあったと思うよ？
407:デフォルトの名無しさん
09/02/07 23:45:41
アメリカのメロン大学は一応名門だけど日本校はどうなんだ？
408:デフォルトの名無しさん
09/02/08 01:05:45
>>404
なにその高レベルな課題
俺の大学時代と雲泥の差
409:デフォルトの名無しさん
09/02/08 02:58:06
超解像の原理が未だに理解出来ません
複数の映像フレームの同じポイントの色の出現頻度に一番高い色を適用するってことですか？
410:デフォルトの名無しさん
09/02/08 13:45:42
は？今の超解像って、時間軸の補完までやってるのか？
411:,,・´∀｀・,,）っ-○◎●
09/02/08 13:52:05
MPEGの原理は主にフレーム間差分をとってJPEG圧縮なんで、それを改めてチェックしたところで・・・
412:,,・´∀｀・,,）っ-○◎●
09/02/08 21:06:32
>>407
神戸のハーバーランドの近くにあるあれか？
兵庫県の財政圧迫してるらしいよ。
学生少なくて撤退の噂もあります
同じビルの同じ階に神戸電子専門学校の学校法人が経営する大学院がある。
何を勘違いしたのか兵庫県立大学も情報科学の大学院を神戸市内に置いてる。
神戸という都市に何を求めてるのか、理解不能である。
たしかに古くからの工業都市で組み込みソフト屋の数がそれなりにいるのはわかる。
最大の勘違いは、日本のITドカタは職場を離れて大学院に通えるほど裕福ではないことだ。
413:デフォルトの名無しさん
09/02/08 21:49:03
俺はてっきり、ラーメン大学とか、洗車大学と同じノリで、
神戸電子専門学校が作ったヒト寄せパンダだと思ってた。
ってか別法人なのか?
学生少なくて、って言う前に、派遣のワーキングプア、
デジタル土方に成る為にわざわざ苦労して大学通う馬鹿
が神戸のどこに居るんだよっ?
俺が居るよ…orz
414:,,・´∀｀・,,）っ-○◎●
09/02/08 22:51:22
兵庫県もネギメロンなんて誘致するくらいなら神戸大に寄附講座でも作ったほうがよかったんじゃね？
現状兵庫県内で優秀な学生がいるんだし。
おっと、「学生」の枠で括ると近くの中高一貫校のほうがよっぽど・・・
415:デフォルトの名無しさん
09/02/09 09:41:15
情報系の大学院は多すぎるよな
旧帝でも定員割れする世の中なのに
このうえ西和彦が秋葉に大学院作るんだから馬鹿としか
416:デフォルトの名無しさん
09/02/09 12:50:30
>>411
誰がMPEGの話をしてるの?
誰も君の知識を披露してくれなんて頼んでないよ?
圧縮で壊れるったって圧縮率によるし、位相が生き残ってりゃ理論的には解像度は上げられる。
圧縮率によっては壊れた分が回復するだけかも知れないけどな。
417:デフォルトの名無しさん
09/02/09 14:21:54
誰がMPEGの話をしてるの?
誰も君の知識を披露してくれなんて頼んでないよ?
418:デフォルトの名無しさん
09/02/09 15:40:30
それを言うなら、なんでいきなり超解像の話になったんだろ？
419:デフォルトの名無しさん
09/02/09 15:43:20
メロン日本校のカリキュラムを見たけど、ウンコすぎて話にならねぇｗ
こりゃ学生もこねーわ
420:,,・´∀｀・,,）っ-○◎●
09/02/09 18:02:06
>>416-417
だれも連投してくれなんて頼んでないよ？
421:,,・´∀｀・,,）っ-○◎●
09/02/09 18:06:41
GPGPU向けの画像・動画関連のソフトってどれも速さばかり求めて品質は二の次だな
ウンコなエンコーダだとRGB/YUV変換で腐る
一番腐るのは量子化だろうけどな
422:デフォルトの名無しさん
09/02/09 18:25:28
Geforceは何気にGTXシリーズで初めて64bitに対応してるけど
演算装置は１個しかないｗ
並列処理が得意な分野でfloatだけで済むようなものはほぼ無いだろｗ
423:デフォルトの名無しさん
09/02/09 19:05:29
>>420
連投じゃなくて別人
2ch歴長いんだからそれくらい分かれ
424:デフォルトの名無しさん
09/02/09 20:42:10
甘いな。floatでも速ければ使い物になる用途は結構あるもんだよ。
例えば、近似計算なんかはfloatで近似させてからdoubleで更に近づけることもできるしね。
425:デフォルトの名無しさん
09/02/09 21:56:34
そういや西和彦もこっちの出身だな。確か甲陽から和田大
だから、落ちこぼれか。そもそも博士余りで高学歴ワープアPD
が社会問題に成ってる今日この頃に、大学院新設とかもうね
アボガドバナナ…。
鴨葱メロンと言えば、金出教授もこっちの出身だったな。
沢山カメラ使って超解像みたいな論文も有ったような無かったような。
426:デフォルトの名無しさん
09/02/13 13:06:41
>>425
お前、自分の考えまとめるの下手だな。
427:デフォルトの名無しさん
09/02/13 13:31:44
まあ、CUDAは英文のドキュメントが読めてある程度知能がないと
使えないからな。
スレ違いの話で盛り上がるのも分かるな。バカばっかりだしw
428:デフォルトの名無しさん
09/02/13 17:06:53
CUDA版のTripcode Explorerができたみたいですね。最適化に期待します。
URLﾘﾝｸ(tripper.kousaku.in)
URLﾘﾝｸ(download.kousaku.in)
429:,,・´∀｀・,,）っ-●◎○
09/02/13 18:13:51
ようこそ、バーボンハウスへ。
このテキーラはサービスだから、まず飲んで落ち着いて欲しい。
うん、「絶対に動かない」んだ。済まない。
仏の顔もって言うしね、謝って許してもらおうとも思っていない。
でも、このネタプログラムを見たとき、君は、きっと言葉では言い表せない
「ときめき」みたいなものを感じてくれたと思う。
殺伐とした世の中で、そういう気持ちを忘れないで欲しい、そう思って
５分ででっちあげたんだ。
じゃあ、注文を聞こうか。
--------------------
1M超のバイナリファイルに何が詰まってるか疑問な人は、テキストエディタで開いてみればいいよ＞＜
430:デフォルトの名無しさん
09/02/13 23:27:26
CUDAはコアレスと分岐の扱いを把握すれば、やりたいことは大体クリア出来ると思われ。
431:,,・´∀｀・,,）っ-○◎●
09/02/14 00:05:15
結局プレディケートなんだよね。
SMあたりの命令デコーダは1基だからSP毎に別々のフローを実行することができない。
Larrabee（Ct）なら分岐は容易に表現できる。
432:デフォルトの名無しさん
09/02/14 01:58:51
>>431
プレディケードって？？
433:,,・´∀｀・,,）っ-●◎○
09/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:デフォルトの名無しさん
09/02/14 11:57:31
CUDAで困るのはその点のほかに、並列数を途中で変えられないこともあるよね。
一度ホストに処理を戻すと遅くなりかねないし、共有メモリが失われてしまうし。
私の関わっているプロジェクトでは演算処理が中心なので、ある程度融通が利いてくれないとね。
435:デフォルトの名無しさん
09/02/15 06:24:49
前にも有ったけど、条件分岐したら負け。
Crayだってそうだったじゃん。
436:デフォルトの名無しさん
09/02/15 12:43:21
CPUだとforループが多重になる部分をGPUに
丸投げすればいいんでしょ？
3項演算子程度は実行して欲しいけど
437:,,・´∀｀・,,）っ-●◎○
09/02/15 16:42:36
> forループが多重になる部分
重要なのは回数であって多重かどうかはあまり関係ないです。
32の倍数であることは有る程度重要かな
一番重要なのは依存関係がないこと。
たとえばループを逆順で実行しても結果が等価であったりとかね。
240 SP（30 SM）を使えるとすれば、フルに使うには、最低960程度の演算が並列実行可能である必要があります。
ただし、全部のSMでまったく同じ処理をする必要はないです。
438:デフォルトの名無しさん
09/02/15 17:06:37
>一番重要なのは依存関係がないこと。
そうだね。そのためiCotの時も関数型言語の並列化
に七転八倒してたね。
今ならerlangで良いんじゃね? CUDAスレでこんなこと
言うのも何だけど、Cライクな手続き型言語だとどうして
もすぐに壁にぶつかってしまって、スケーラビリティが
出せない。もしくは出そうとするとプログラマの負担が
重過ぎる。
個人的には今更lispやprologに復活されたくはないけど。
439:デフォルトの名無しさん
09/02/15 17:15:56
>>438
そう、わかったよ
じゃあ俺様がCUDA用erlang処理系書いてやる
440:デフォルトの名無しさん
09/02/15 17:57:47
ループを並列処理に展開するのって自動化出来そうだけど
441:デフォルトの名無しさん
09/03/04 19:00:05
>>424
おいおい調子に乗って嘘つくな。
「簡単にできるぜ！」っとか鼻高々なのはいいけどそんなのないよ。
442:デフォルトの名無しさん
09/03/05 00:44:05
>>441
いや数値計算なら反復法とか1次連立方程式の陰解法で使えるだろ
443:デフォルトの名無しさん
09/03/05 00:59:48
また自信満々な人の嘘つき合戦ですか？
444:デフォルトの名無しさん
09/03/05 01:00:38
なんだよ微分方程式、というか積分使うのか。
積分を近似計算といっていいのか？
実用内ではあると思うけど、それもfloat(7)からdouble(16)だろ。何回ループするつもりなんだよ。
445:デフォルトの名無しさん
09/03/05 03:47:40
積分を近似計算と言ってはいけない理由がわからん。
446:デフォルトの名無しさん
09/03/05 06:23:04
数値計算なら兎も角、シミュレーション関係なら大いに有り得る話だな。
自分が知っていることが全てではないと認めることができれば世界は広がるのに。
447:デフォルトの名無しさん
09/03/05 20:24:13
他人を否定することでしか自分を正当化できない、ということか。
448:デフォルトの名無しさん
09/03/05 21:39:34
>>447
数値計算と近似計算の違いを教えてくれませんか？
449:デフォルトの名無しさん
09/03/06 04:35:50
>>448
1+1=2となるのは、数値計算ではあるが近似計算ではない。
450:デフォルトの名無しさん
09/03/06 08:57:12
CUDA 2.1 Notebook Drivers for Windows
URLﾘﾝｸ(forums.nvidia.com)
βだけども
451:デフォルトの名無しさん
09/03/06 14:44:51
>>446
とすると、貴方の世界ではシミュレーションとは近似計算をしてるってことですか？
452:デフォルトの名無しさん
09/03/06 15:05:56
物理にしろ確率モデルにしろコンピュータシミュレーションは近似計算だろ
453:デフォルトの名無しさん
09/03/06 15:08:22
整数演算は近似計算ではありません。
454:デフォルトの名無しさん
09/03/06 15:15:06
approximationの意味分かってるの
455:デフォルトの名無しさん
09/03/06 15:38:46
なんかめんどくさそうな人がいっぱいいますね。
どうでもいいですが、早いところストリーム用のプログラミング手法を確立して、ストリームに特有な技法を紹介する本を出してくださいな。
456:デフォルトの名無しさん
09/03/06 16:26:22
どうして煽りを入れる人ほど知識が足りないんだろう？
457:デフォルトの名無しさん
09/03/06 17:11:04
>>456
知識が足りないから煽るじゃないですかね？
そういう低脳な人は「煽ることしか出来ないよね」っとも言いますけど。
そんなことどうでもいいんで「ストリームんグ・プログラミング技法」とかいうブログを早く作ってくださいな。
「approximationの意味分かってるの」とかめんどくさそうな人との議論とかいかめしい顔した人が言う哲学に興味はないんで。
458:デフォルトの名無しさん
09/03/06 17:14:51
↑
低脳な人の煽りの見本
459:デフォルトの名無しさん
09/03/06 18:03:55
458 名前： デフォルトの名無しさん [sage] 投稿日： 2009/03/06(金) 17:14:51
↑
低脳な人の煽りの見本
460:デフォルトの名無しさん
09/03/06 19:56:54
プログラム板なんだから少しはプログラム出せって
461:デフォルトの名無しさん
09/03/06 20:18:50
↑
低脳な人の煽りの見本
462:デフォルトの名無しさん
09/03/06 20:40:17
↑
低脳な人の煽りの見本
↓
463:デフォルトの名無しさん
09/03/06 20:41:28
>>448
1+1=2となるのは、数値計算ではあるが近似計算ではない。
464:デフォルトの名無しさん
09/03/06 22:21:12
VIPのまとめWikiに書いたこともあるが、今はネタがない。
あーそうそう、x16バスに繋がった8800GTの方がx8バスに繋がったGTX280よりも速かったってこと位か。
但し、転送量が多目の用途だからだとは思うが。
465:,,・´∀｀・,,）っ-○◎●
09/03/06 22:22:16
VIPPERプログラミングスレの派生なのかここ？
466:デフォルトの名無しさん
09/03/06 22:23:45
大丈夫、私はvipには書いていないw
でも何故かまとめWikiには複数投稿している罠。
467:デフォルトの名無しさん
09/03/07 02:00:17
自分が知らない事はWeb見て知ったかぶらないで馬鹿げたレスする暇で
amazonで本の一冊でも買えばいいのに。
ところでCUDAで性能だすためのまとまった日本語の文書ないかな？
468:デフォルトの名無しさん
09/03/07 02:22:11
そもそもCUDAに関して有用な日本語資料がなくね？
公式でさえ日本語マニュアルはあんなだったし。
469:,,・´∀｀・,,）っ-●◎○
09/03/07 02:25:00
大丈夫、英語資料すらろくなのないから。
470:デフォルトの名無しさん
09/03/07 02:30:32
やはり本家のドキュメントにあたるしかないのか。
めんどくせー。環境の開発もいいけどドキュメントの整備も力入れてほしいわ。
471:,,・´∀｀・,,）っ-●◎○
09/03/07 07:18:34
逆に日本語ドキュメントがあっても大して意味無いよ。
IntelのプログラミングマニュアルなんていまだにPentium 4のことしか書いてないぞ。
日本法人仕事しなさすぎる。
CUDAを勉強するより前に英語アレルギーを克服したほうが何かと良くなるかも。
472:デフォルトの名無しさん
09/03/07 07:55:47
英語アレルギーってなに？
473:デフォルトの名無しさん
09/03/07 08:25:11
そう言いたくなるくらい、英語から目を背ける人は世の中に意外と多い。
474:デフォルトの名無しさん
09/03/07 08:45:27
俺の場合英語と日本語だと読むスピードが１０倍～１００倍違うorz.
475:デフォルトの名無しさん
09/03/07 11:19:36
母国語でないと読むスピードが遅いだけじゃなく小さなとこで思い
違いがでてきて結局後からまた参照したりして嫌だ。
476:デフォルトの名無しさん
09/03/07 11:23:45
技術的文書に機械翻訳はどの程度通用するんだろ。奇想天外な訳になってしまうのかな。連投ｽﾏｿ
477:,,・´∀｀・,,）っ-●◎○
09/03/07 11:41:59
英文学読めって言ってるんじゃないんだし、書ける・話せるも別問題。
技術ドキュメントの英語なんて、有る程度形式ばった言い回ししかやらないので
単語を摘み出すだけでも回数を重ねればそこそこ意味はわかるようになると思う。
慣れてくれば技術系ニュースサイトとかも読んでみたり。
478:デフォルトの名無しさん
09/03/07 11:51:27
だんごさんはどーゆーサイトみてますか
スレ違い申し訳ない
479:,,・´∀｀・,,）っ-●◎○
09/03/07 12:17:36
Intelの開発者ブログとかRSSに入れてる
480:デフォルトの名無しさん
09/03/07 22:13:23
団子はGPGPU嫌いなんじゃなかったの？
481:,,・´∀｀・,,）っ-○◎●
09/03/07 22:18:46
逆に、好きな奴いるのか？
非生産的で変態だけど性能のために仕方なく使う類のモノだろ
482:デフォルトの名無しさん
09/03/07 22:22:35
おれもGPGPUなんて嫌いだな。
開発したことあるけどPSシリーズも大嫌い。
483:,,・´∀｀・,,）っ-●◎○
09/03/08 08:31:15
x86でいうMMX/SSEって、分岐が除去できるとか直列方向のパフォーマンスメリットがあった。
GPGPUって並列方向のスループットありきで、ホスト側のコードでお膳立てしてやらないといけない。
484:デフォルトの名無しさん
09/03/08 19:46:25
>非生産的で変態だけど
それってintelアーキのことじゃん。昔からずっと言われ続けてることだが。
mc68kやsparc,mipsの方がよっぽど素直に書ける。
けど市場規模のために仕方無く使わされてる。
485:デフォルトの名無しさん
09/03/08 20:10:12
アセンブラはmc68とx86しかやったことないけど、
mc68はかきやすかったな～。
欲を言えば16本すべて汎用レジスタだったらよかったんだけどｗ
486:,,・´∀｀・,,）っ-●◎○
09/03/09 01:10:52
>>484
あー？
メモリアドレッシングモードが貧弱すぎるんだけどー？
まじうけるー？
ﾊﾟﾈｪっすよ
487:デフォルトの名無しさん
09/03/09 01:20:53
インテルに慣れきってるとそう思うかもね。
どうせ団子はインテル一筋なんだろ？w
488:,,・´∀｀・,,）っ-●◎○
09/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:デフォルトの名無しさん
09/03/09 02:50:28
団子の脳みそがx86のアーキテクチャで凝り固まってて、現代風のプログラミングパラダイムについて来れないってことだろ。
あと１０年もすればおまえの持ってる小手先業などは博物館の展示資料でしかないし、おまえの能書きなど頑固オヤジの戯言同じなるだろう。
インテルのブログで洗脳されまくっちゃうのもいいけど、アーキテクチャマニュアル云々よりも団子が頭の切り替えをできるかどうかのほうが問題なんじゃないの？
490:デフォルトの名無しさん
09/03/09 02:57:29
現代風のプログラミングパラダイムって何だ？
491:,,・´∀｀・,,）っ-●◎○
09/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のほうが効率がよくなってるわけさ。
このへんは ｽﾚﾘﾝｸ(i4004板:76番)あたりと同意見
しかしさ、16要素とか32要素とか、全部バラバラのアドレスだとしてみ？
とてもワーストケースで要素数分だけメモリアクセスが必要だぜ。
RISCの守備範囲じゃねーよ
んで、個人的にCUDAの問題は、scatter/gatherスカラ命令を備えないことなんだよね。
常に32並列単位で演算しないといけない。それで小回りがきかない。
スカラレジスタでアドレス指定するベクトル単位のロード・ストアと
scatter/gather
Larrabeeあたりがまさにこれをやってるわけだが。
> あと１０年もすればおまえの持ってる小手先業などは博物館の展示資料でしかないし、おまえの能書きなど頑固オヤジの戯言同じなるだろう。
残念だが俺は流行りものの言語・フレームワークには目がない。
Ruby On Railsとか大好きだし。むしろ高級言語をより効率的に使うためにマシン語レベルで理解する必要があるんだよ。
たとえばさ、LLって性能的にはネイティブマシン語より遅いから、LL向けのJITコンパイラ書きたいとするじゃん。
どうしてもアセンブラの知識は必要なんだよね。もちろん業務じゃないよ。
ということでプロ高級言語er、趣味マシン語er
それでARM語もx86語もそれなりにたしなんでおきたいわけ。
492:,,・´∀｀・,,）っ-●◎○
09/03/09 03:37:32
○んで、個人的にCUDAの問題は、スカラ命令を備えないことなんだよね。
493:デフォルトの名無しさん
09/03/09 03:52:38
頑固オヤジの戯言ごとと同じになるだろう。
ニート相手に５行も書くの面倒だから誤字脱字なおすのも面倒だよな。
「CISC的」とかいう概念がもう古いパラダイムってこと。
おまえみたいな純粋な「消費者」の戯言などどうでもいいけど、ストリームなのに128/256bits単位とか全く鼻糞だろ。
ストリーム演算やってるのに、「スカラ演算もやりたい！」「アドレッシング！」という考え自体を改めたほうがいいと思うけどね。
どうでもいいけど、ストリーミング・プログラミングの小技を集めたブログをはよ作ってよ。
C#だとスニペットというんだったか？そういうイディオム集みたいのでもいいから。
494:,,・´∀｀・,,）っ-●◎○
09/03/09 03:59:04
Intelの中の人のブログって言っても、本当に自社製品のプログラミングがらみの話題って
月に1回出るかどうかのレベルだぜ
次期Windowsの話題だったり、XMLやLLなんかのWebまわりの技術がどうこうだったり。
中の人の興味のあることが書いてあるって感じだけど、頭の悪い技術系ゴシップサイト
よりはよっぽど為になる。さすが半導体総合メーカーだわって思うわ。
NVIDIAのニュースも購読してたけど本当に自社製品向けのコンピュータグラフィックスのノウハウとか
グラフィックよりの物理演算が中心で、そっち方面はそんなに深入りする気はないので読む価値なしと。
（そっち方面で食ってる人ごめんなさいね）
495:,,・´∀｀・,,）っ-●◎○
09/03/09 04:01:57
>>493
> どうでもいいけど、ストリーミング・プログラミングの小技を集めたブログをはよ作ってよ。
> C#だとスニペットというんだったか？そういうイディオム集みたいのでもいいから。
ﾌﾟﾌﾟﾌﾟﾌﾟﾌﾟ
496:,,・´∀｀・,,）っ-●◎○
09/03/09 04:11:02
ソースコード例文をいんたーねっつで検索してきてコピペをするのが
プログラミングだと思ってる人はそう言うのに本質を求めるよね。
いや、いいんだけどね。
俺とて業務では最高級の言語から低級言語で書かれたライブラリを使わせてもらってる立場だし。
497:,,・´∀｀・,,）っ-●◎○
09/03/09 04:43:49
ちなみにマルチコアとかSIMDを使いこなして最適化コード書いたりできる人間は稀少性があるから
長い目でみれば食いっぱぐれしないよ。
今でこそ団塊COBOLerの後釜需要があったりするくらいだし
（徐々にJavaや.NETに置き換わってるので将来性を考えれば微妙だが）
自動並列化ランタイム環境使えばいいとか言うだろ？
そう言う考えの三流プログラマは食いっぱぐれる。間違いなく。
じゃあその並列化ランタイムは誰が書くんだと。書きもしないのに沸いてくるのかと。
最近流行のJavaScriptのJIT部分のコードでも見てみればいい。各CPU用のバイトコードの山だ。
その点、覚えさせれば小学生でも出来るような、コードをコピペして貼り合わせる能力なんて誰が評価するんだよ。
知識が無いと難しい作業こそ高い市場価値がある。
CUDAはまだ市場として育ってないがな。とがってる分、苦手なことが多すぎて。
498:デフォルトの名無しさん
09/03/09 05:31:36
俺の団子が火を吹くぜ！
499:,,・´∀｀・,,）っ-○◎●
09/03/09 05:54:25
っていうか、電子の移動度の限界とか云々でクロックが上がらないのでフリーランチ終焉、
SIMDやマルチコアを明示的に使いこなさないと性能出ませんよ
これ以上1スレッドの負荷の重たいソフト書くなよ、なんて、何年も前から言われてることなのに
「価値がなくなる」だとか何を妄言はいてるんだか。
10年後に100GHｚとか200GHzとかいくのかよ。
数十コアとか数百コアになって最適化屋の需要拡大することはあっても、縮小することなんてねーよ
要するにSIMD・マルチコア使いは10年先もナウい。ﾊﾟﾈｪ
500:デフォルトの名無しさん
09/03/09 06:07:53
最適化できる奴は別にたくさん要らないよなぁ・・・
結局ライブラリ作って終わりだし。
そういうライブラリがなかったり高額だったら、誰も使わないからあまり流行らないわけで、どんどん忘れ去れていく技術なだけだしなぁ・・・
GPUとは関係ないけど、MSの提唱してる技術とかかなり不発が多くて流行らずに忘れ去れてるの多いでしょ。
（スカラの）マルチコアとライバル関係だけど、運が悪いとGPU（ストリーム）の方が流行らずに終わってしまうことだってある。PCってのはそういう世界だったよな。
どうでもいいけど人柱がんばってよ
501:,,・´∀｀・,,）っ-○◎●
09/03/09 06:10:54
せいぜいコードコピペで済む単発案件こなしてなよ
希少価値のある技術には見えないがね。
どっちかというとコピペプログラミングこそ自動化できそうだけどなぁ
お絵かきツールだけでプログラムのフロー書くASTERIAみたいなツールも出てきてるし
502:,,・´∀｀・,,）っ-○◎●
09/03/09 06:52:27
既にゲーム業界では下っ端レベルからそういう技術が要求されるようになってるけどね
PS3とか360やってるところなら半ば強制だぜ
脳天気でいられるのは高級言語屋とローエンド組み込みCPUソフト技術者くらい
CUDAは流石に今のポジション以上の普及はないと思うよ
「汎用」ってものをわかってない。
503:,,・´∀｀・,,）っ-○◎●
09/03/09 07:00:18
GPGPUの【GP】に関してならLarrabeeに食われるだろうね。
たとえば普通のCを使うとして、たとえばtime.hすら使えないのがCellのSPEなら
CUDAはそれ以前の問題だし
504:デフォルトの名無しさん
09/03/09 07:01:11
スニペットとかコピペってのは、結局コードのモジュール化ってことでしょ。
オブジェクト指向による再利用促進とも言うけど、それは時代の流れって言うよりもう当たり前じゃないのか？
IDEとか便利だし、かゆいところは自分でコード書けばいいんじゃないか。
今の時代、３０分で作れるのに一からメモ帳作る奴はよっぽどバカでしょ。
505:デフォルトの名無しさん
09/03/09 07:03:23
ああ抜けてた。
コピペって簡単に言うけど、典型コードの再利用なわけでだからこそメモ帳アプリが３０分で作れる威力があるんだけど。
506:デフォルトの名無しさん
09/03/09 07:05:53
そういえば、ム板でコテ名乗ってるのは団子ぐらいしかいないよね？他にいるの？
507:,,・´∀｀・,,）っ-○◎●
09/03/09 07:23:14
>>504
コピペの単純工程をやるプログラマもいれば
ライブラリを書くプログラマもいるわけで
法律事務所のアルバイトと弁護士くらいの格差は出てくるかもね
いや、既に出来てるか
508:デフォルトの名無しさん
09/03/09 09:07:28
>>505
使い回しでメモ帳に30分ってかかりすぎだろ。3分でやれよ。
テキストコントロール配置してファイル読み書き機能付けるだけで終わりだろ
IDEの雛形だけでほぼ完成なんだからさ
それともGREP機能でも搭載するのか？
509:デフォルトの名無しさん
09/03/09 09:12:15
30秒だろ
#include <stdlib.h>
int main(void) { system("notepad.exe"); return 0; }
再発明する価値もない。
510:デフォルトの名無しさん
09/03/09 09:20:05
無いものを作る、あるいは既にあるものをより良くすることに知的労働の価値があるわけで
劣化コピーの再発明で金とるなど馬鹿の所業だろ。
511:デフォルトの名無しさん
09/03/09 09:42:01
>>509
ワロタｗ
512:デフォルトの名無しさん
09/03/09 10:28:29
30分で作れる程度のエディタなんて誰も使いたくないな
513:デフォルトの名無しさん
09/03/09 12:06:54
なんでおまえらはそのうちいい情報を提供してくれそうな人を叩くんだよ
514:デフォルトの名無しさん
09/03/09 12:13:14
いい情報を提供するのが自分じゃないと気がすまないからさ。
そのために全体が遅延しても問題なし。
515:デフォルトの名無しさん
09/03/09 12:28:58
CUDAは既存の一握りのプログラムの再発明のためデバイス・言語処理系だろ。
性能はともかく効率CUDAでできることは普通のCPUでもできる。
より高いスループットを得るためにこそある。
プログラミング対象を選ぶし、性能を出すには工夫がいる。
テキストエディタの話じゃないけど、生産性を言い訳にして自分で創意工夫が出来ない奴には不向き。
516:デフォルトの名無しさん
09/03/09 12:38:56
,,・´∀｀・,,）っ-○◎● に嫉妬してるだけじゃね？
517:デフォルトの名無しさん
09/03/09 13:34:37
まぁ、団子は必ずしも間違ってはいないからな。
CUDAに未来はないかもしれないけれど、OpenCLはAMDも担いでいるからもう少し生き延びるだろうし。
518:,,・´∀｀・,,）っ-○◎●
09/03/09 19:05:27
OpenCL（笑）
なんかの魔法の言語のように思ってないか？
OpenCLは「GPU版Java」じゃない。
共通化されてるのは言語の基本仕様の部分だけで、細かいところは処理系依存。
んでもって、CUDAやCAL/Brook+のプログラミングの敷居を高くしてるのは言語処理系じゃなくて
少ないスクラッチパッドメモリとレイテンシの大きいメモリと
やたら小回りが利かないベクタ演算ユニット、その他諸々のGPUのパイプライン・・・
要するにシェーダコアの構成そのものにあるのであって、それが解消されない限り
CPUを置き換えて普及していくことなどあり得ない。
普通のCPUと同じ定番言語のC/C++言語をまがりなりにもサポートしてるのに
業界の評価のお寒いCellを見れば、課題は言語じゃなくて汎用プロセッサとしての
柔軟性にあることくらいわかるだろ？
その意味、OpenCLを効率良く実行できるのはよりCPUに近いLarrabeeだと思うよ。
というか本質的にOpenCLなんて要らない。
どうせCellなんかと同じくハード専用にカリカリにチューニングしなきゃいけないんだし。
519:デフォルトの名無しさん
09/03/09 19:35:29
>>518
世の中それほどぎりぎりのチューニングまではしないけどちょっとは速く走って欲しいなんて用途が結構あるのよ。
で、私自身はOpenCLはAMDが必死こいてアピールしているだけで実際には普及しないと思っているのよね。
どうせLarrabee出て来る頃にはCtも来ているだろうから、NVIDIAもAMDも青息吐息でしょ。
まぁ、CUDAスレなんだからLarrabeeの待つ未来を語るのは程々にしましょ。
520:,,・´∀｀・,,）っ-○◎●
09/03/09 19:58:15
期待してなんか無いよ。
Cellと同じくニッチ市場を食い合うだけ。
521:デフォルトの名無しさん
09/03/09 20:55:32
ゲーム屋の意見としては、SPUの数とメモリが倍あったらCellも悪くないと思う。
あとはメモリのバンド幅か。
柔軟性もあったら嬉しいけどね（整数や分岐とか）。
522:デフォルトの名無しさん
09/03/10 04:01:00
>期待してなんか無いよ。
おっと、だんごさんの悪口はそこまでだ
523:デフォルトの名無しさん
09/03/11 03:05:50
>やたら小回りが利かないベクタ演算ユニット、その他諸々のGPUのパイプライン・・・
Crayだってそうだったじゃん。Personal CrayとしてCUDAは良く出来てると
思うけど。
メモリの不自由な階層は何とかしてくれ、と思うけど。Cray同様、IPも持って
一般I/Oも出来て欲しい。
あと出張先でデモ出来るように、CUDAの動くnVidia GPU載ったサブノート
が出てくれないと…。学会発表しようにも、デスクトップ担いで持参しなきゃ
ならんってのは勘弁。
524:,,・´∀｀・,,）っ-○◎●
09/03/11 03:24:55
つ[Asus N10]
525:デフォルトの名無しさん
09/03/11 11:31:57
つ[新Mac Book]
526:,,・´∀｀・,,）っ-○◎●
09/03/11 22:47:25
いや、でも、アカデミック畑の人の求める特化型プロセッサって一般のニーズとかけ離れてると思うよ。
CellやGRAPE-DRでワードやエクセルが動くかっつーの。
当たり前だけどアカデミック色の薄いアプリケーションって書く人少ないのよね。
サンプル探しにCUDA-Zone逝っても「なんとか論文ps.gz」みたいなのしかないし
527:デフォルトの名無しさん
09/03/11 23:01:58
ここにアカデミック色の殆どないアプリケーションを書いている人が居るんだが、
残念なことに特定用途向けだし契約の都合もあるんで公開できないんだわさ。
528:デフォルトの名無しさん
09/03/11 23:04:35
アカデミック色って例えば何？
ブラックホールのシミュレーションとか？
529:,,・´∀｀・,,）っ-○◎●
09/03/11 23:08:18
俺も書いてたよ
NVIDIAの営業さんじきじきに頼まれたがめんどくさくなった
530:,,・´∀｀・,,）っ-○◎●
09/03/11 23:09:07
>>528
そういえばGRAPEのコミュニティではCUDAはやたら受けが良いらしいね。
531:デフォルトの名無しさん
09/03/12 19:48:28
>>523
モバイルCUDA環境が欲しくてN10jc買った
性能は
./nbody -benchmarkで16.472GFLOP/s
./nbodyでタイトルバーにでるやつだと80GFLOP/sくらい
532:,,・´∀｀・,,）っ-○◎●
09/03/12 21:20:13
割と出るんだね
大学時代にやった熱力学シミュレーションのレポートをまた引っ張り出してきてCUDAで実装してみるかな。
Rubyで書いたらアホみたいに遅くてC++で書き直した覚えがある。
533:デフォルトの名無しさん
09/03/13 01:33:06
Rubyで書いてCより性能でればいいのにね。無理言うなって感じだが
534:デフォルトの名無しさん
09/03/13 01:52:39
アルゴリズムが悪いんじゃないの。
535:,,・´∀｀・,,）っ-○◎●
09/03/13 01:58:40
まさに「グリッド」（格子点）だよ。
アホみたいに並列化しないと性能出ないCUDAには向いた問題
536:,,・´∀｀・,,）っ-○◎●
09/03/13 02:20:43
RubyはCでかかれたインタプリタであって、
1語句ごとにループ・switch文で処理を行う以上
それ自体の致命的な遅さはどうしようもない。
YARVとかJRubyなら多少速いかも知れんが
本家はまだJIT以前の問題だし。
Matz氏はXbyak見て「いずれは考えなきゃいけない」的なこと言ってたんだけどね。
537:デフォルトの名無しさん
09/03/13 02:50:22
団子の中の人って、大学逝ってたんだ。
>>531
意外とやるな。電池で動いてそれなら上出来だと思う。
ARM+DSPでは桁違いに負けてると思う。しかし、所詮
ネトブクに毛が生えただけなのに、ThinkPad Xシリーズ
より重いのか。
Linux対応はどない? EeePCのLinux対応はすこぶる良
かったから期待してるのだが。
538:デフォルトの名無しさん
09/03/13 08:17:53
>>537
CentOS5.2はおk
サウンドは自分でドライバ当てる必要あり
無線LANは認識してる
（ドライバ入れてないから使えるかどうかは不明
あとはカメラと指紋認証が使えないくらい
他の鳥は試してないからわからん
BIOSでHT切れないのが気持ち悪い
539:デフォルトの名無しさん
09/03/13 10:27:16
>>537
金を気にしないならネットブックは辞めたほうがいい。
1024x600は割と不便。
EeeUbuntuなら、最初からEeePC向けのカメラやBluetoothの設定ユーティリティが
インストール済みだが。
540:デフォルトの名無しさん
09/03/13 22:33:58
>Matz氏はXbyak見て「いずれは考えなきゃいけない」的なこと言ってたんだけどね。
いつ？
>YARVとかJRubyなら多少速いかも知れんが
>本家はまだJIT以前の問題だし。
YARVはすでにRuby本家だけど？
541:,,・´∀｀・,,）っ-○◎●
09/03/13 22:38:08
>>540
URLﾘﾝｸ(www.rubyist.net)
542:デフォルトの名無しさん
09/03/13 22:41:31
参考になるかもしれない、じゃん
543:デフォルトの名無しさん
09/03/13 23:25:23
>>541
リンク先読んだが、Xbyakじゃなくて「Gecko 3.0にはJIT付きJavaScriptエンジンが添付されるということだが」が、将来の参考になるという風にしか読めないんだが・・・
2007年の時点なら、Matz氏がRuby用のJITについて参考にするという文脈なら、XbyakじゃなくてYARVのJITが暗黙でしょ。
544:,,・´∀｀・,,）っ-○◎●
09/03/13 23:50:07
別に"へるみエンジン"を検討してるなんて言ってないが
「JIT」としか言ってねーよ
545:デフォルトの名無しさん
09/03/14 00:21:40
JITじゃなくて、「「いずれは考えなきゃいけない」的」と「参考になるかもしれない」は違うだろって話でしょ？
あと、
>YARVはすでにRuby本家だけど？
についてはノーコメントのなの？
546:,,・´∀｀・,,）っ-○◎●
09/03/14 00:33:17
YARVはJIT実装があったろ？
あれこそ亜流だけど
547:,,・´∀｀・,,）っ-○◎●
09/03/14 00:39:52
>>545
ちなみにYARVとか鬼車のJITは環境非依存の中間コードに変換するだけであって
CPUネイティブじゃないよ。
んで更にそのバイトコードをインタプリタで動かしてる。
ネイティブコードのJITに言及したのは↓だけ
> _ [言語] IA32(x86)JITアセンブラ Xbyak
548:,,・´∀｀・,,）っ-○◎●
09/03/14 00:41:52
ま、Rubyが動かせそうなGPUはLarrabeeが最初で最後だろうな
549:デフォルトの名無しさん
09/03/14 01:01:14
いつJITの実装の話になったんだ。
話そらすのが上手いなｗｗ
そもそもMatz氏はXbyakについて「「いずれは考えなきゃいけない」的」な事は言ってないので（参考にするのはGecko 3.0の方）、>>541以降のお団子さんのコメントは見当違い。
550:,,・´∀｀・,,）っ-○◎●
09/03/14 01:08:02
Xbyakを採用するなんて俺は言ってないし君が勝手に勘違いしただけでしょ
551:,,・´∀｀・,,）っ-○◎●
09/03/14 01:14:17
もともとはRubyがC++よりクソ遅いって当たり前の話だろ。
スクリプト言語が静的コンパイル言語を超えられる訳がない
それだけのことよ
552:デフォルトの名無しさん
09/03/14 02:39:35
団子、いい加減にしろ。最近のお前はオカシイぞ。
形式言語より、日本語勉強し直せ。マジで。
コミュ力無さ過ぎ。
553:,,・´∀｀・,,）っ-○◎●
09/03/14 02:50:01
自分が思考短絡してるのを棚に上げて他人を避難するｳﾞｧｶがいると聞いて
554:デフォルトの名無しさん
09/03/14 03:08:30
自己紹介、乙。
そんなヴァカ呼んでないから、「避難」してこい。
555:デフォルトの名無しさん
09/03/14 04:45:16
テンプレ入りか
> Matz氏はXbyak見て「いずれは考えなきゃいけない」的なこと言ってたんだけどね。
556:デフォルトの名無しさん
09/03/14 04:46:34
コテ団子の相手はするな。キチガイになっちまうぞ！
557:デフォルトの名無しさん
09/03/14 05:44:29
>>553
自分の技術力をいくら上げても、無責任な発言ばかりしていると誰も君のことを信用しなくなるよ。気をつけたほうがいいと思う。
558:,,・´∀｀・,,）っ-●◎○
09/03/14 11:15:53
「JIT」について話してるのに
一番近くにある単語「Xbyak」を「検討」ということにしたがる思考短絡ぶりがゆとり脳
559:,,・´∀｀・,,）っ-●◎○
09/03/14 11:18:59
Matz氏はXbyak見て（JITの仕組みを）「いずれは考えなきゃいけない」的なこと言ってたんだけどね。
これでいいかな？
560:,,・´∀｀・,,）っ-●◎○
09/03/14 11:46:40
温度分布の立体グラフをExcelでプロットしたいんだが、なんかいい方法ある？
俺もゆとりだからCSVで吐き出して読み出すとか原始的な方法しか思いつかない
561:デフォルトの名無しさん
09/03/14 12:10:49
隔離スレなのか、ここはw
562:デフォルトの名無しさん
09/03/14 15:18:59
>>560
Excelなんかを使いたいなら、csvでいいんでない?
つーか、団子もそれに噛み付く奴も自分の言葉が足りてないことに気付けよ。
563:デフォルトの名無しさん
09/03/14 18:37:07
ここはグダスレじゃないぽ
564:,,・´∀｀・,,）っ-○◎●
09/03/14 18:39:25
くだをまくスレです
565:デフォルトの名無しさん
09/03/14 20:57:56
どのスレでもゆとり脳の団子が来ると荒れる。
そして人がいなくなる。
566:デフォルトの名無しさん
09/03/14 21:02:45
まだゆとりがどうのこうの言ってる時代錯誤な奴がいるのか
567:デフォルトの名無しさん
09/03/14 21:06:25
おまえはヒマになると２ｃｈ開いてるだろ？ｗ
568:デフォルトの名無しさん
09/03/14 21:29:38
お前は○○だろ
↑↑自分がそうだから他人も同じだと思っている奴の決まり文句
569:デフォルトの名無しさん
09/03/15 01:33:02
○○な>>568
570:デフォルトの名無しさん
09/03/16 00:57:27
Vista x64
Device 0: "GeForce 9600M GT"
4096 bodies, total time for 100 iterations: 663.110 ms
= 2.530 billion interactions per second
= 50.602 GFLOP/s at 20 flops per interaction
571:デフォルトの名無しさん
09/03/27 14:21:17
>>567
暇じゃなくても開いてるわボケ
572:デフォルトの名無しさん
09/03/27 14:35:28
忙しいときほど2ch開いちゃう、ふしぎっ
573:デフォルトの名無しさん
09/03/30 08:24:15
■後藤弘茂のWeekly海外ニュース■
KhronosがGDCでGPUやCell B.E.をサポートするOpenCLのデモを公開
URLﾘﾝｸ(pc.watch.impress.co.jp)
574:デフォルトの名無しさん
09/04/02 02:16:00
素人質問で恐縮ですが……
Tesla C870を手に入れたのでCUDAで画像処理をしようとしているのですが、
CUDAでテクスチャフィルタリングユニットの機能を使うにはどうすればいいですか？
○○の○ページを嫁！で構いませんので、教えて下さい。
575:,,・´∀｀・,,）っ-●◎○
09/04/02 02:20:44
tex.filterMode = cudaFilterModePoint;
576:デフォルトの名無しさん
09/04/02 05:33:53
＞Tesla C870を手に入れたのでCUDAで画像処理をしようとしているのですが、
あー、8800GTXからアナログ回路を減らしてメモリを増やした、最早今となっては1万円ちょっとで買える
8800GTと数割程度しか能力の変わらない癖に値段は10倍以上と言う代物ですね。
テクスチャ関係は私はやってないからお役に立てませんがw
577:デフォルトの名無しさん
09/04/02 19:49:08
MV探すのに16x16のSADをCUDAで計算してるんだけど、なんでこんなに遅いんですか？
578:デフォルトの名無しさん
09/04/02 23:51:01
組み方が悪いんでしょ。
579:デフォルトの名無しさん
09/04/03 00:09:14
SADするのに、組み方どうこうとかあるんですか？
テクスチャ使ってるのに、なんかキャッシュミス多い感じだし。。。
580:デフォルトの名無しさん
09/04/03 00:29:06
>>575
ありがとうございます。
cudaFilterModePointでググったら、それらしいものが見つかりました。
URLﾘﾝｸ(forum.nvidia.co.jp)
これから勉強します。
581:デフォルトの名無しさん
09/04/03 10:15:13
>>579
コードも晒さず、自分の無知を曝け出し、文句だけ言うなんて、馬鹿なの?
582:デフォルトの名無しさん
09/04/08 12:16:06
なんでこう沸点低いの？馬鹿なの？
583:デフォルトの名無しさん
09/04/14 20:59:29
ION採用ミニデスクトップAcer AspireRevo、オンライン予約開始
URLﾘﾝｸ(japanese.engadget.com)
584:デフォルトの名無しさん
09/04/15 18:41:51
Mac用の2.1ってツールちゃんと入ってる？
585:デフォルトの名無しさん
09/04/16 23:29:47
誰かN10JでCUDA使ってる人いる？
N10Jにtool kitインスコしようとすると失敗するんだけど。。。
586:デフォルトの名無しさん
09/04/18 23:08:34
今、ブロック数を増やして並列度をあげてみるといったことを
作った行列の積の計算にあててみようと思ったんだが
URLﾘﾝｸ(tech.ckme.co.jp)
に書いてるブロックを複数使った場合の問題は、カーネル内でブロック間の同期を
とる方法が存在しない点である。そのため、下記のプログラムでは、1回計算するたびに、
カーネルを終了し同期をとっている。
というのは1回毎の計算をホストにコピーしてやりたい回数分ループさせるというので
いいのかな？
587:デフォルトの名無しさん
09/04/19 00:37:24
>>586
いちいちホストにデータ転送してたら時間もったいないでしょ？
つか参考にしてるページ見たけど、かなり酷いコードなんだが。。。
>>586が何をしたいかが具体的に判らないから、アドバイスしづらい。
588:デフォルトの名無しさん
09/04/19 02:08:47
１ブロックの最大スレッド数を使った計算じゃ、GPUの処理速度がCPUに対して上回らなかったので
ブロック数を増やして計算しようと思ったんですが、１ブロック制限に到達した時、どうやって次のブロックに
移動すんのかが、記述の仕方がかなりよくわからないんです。
dim3 grid(16, 1, 1);
dim3 threads( 512, 1, 1);
testKernel<<< grid, threads, mem_size*2+sizeof( float)*2 >>>( d_idata, d_odata);
カーネルのほうの計算にこの値を元に何か記述すればいいとはわかってるんですが・・・
何か参考になるとこありませんか？
589:デフォルトの名無しさん
09/04/19 03:34:08
>>588
大いに勘違いしている希ガス。
先ず第一に、>586のサイトは参考にならない。
第二に、スレッド数は必ずしも多いほど速いと言う訳ではないし、共有メモリは使わないで済むなら使わない方がいい。
第三に、行列の積の計算なら、NVIDIAのプログラミングガイドにそれなりのサンプルがある。
590:デフォルトの名無しさん
09/04/19 21:23:36
>>589
レスサンクス、ガイドとＳＤＫもう一回見てきます
591:デフォルトの名無しさん
09/04/20 22:01:56
CUDAスレって何でこんなに勢いが弱いの？
592:デフォルトの名無しさん
09/04/20 23:13:01
ぶっちゃけ2年後位には廃れてると思うからやる気がしない
日本語資料少ないし
.netでもやってる方がつぶしがきく
593:デフォルトの名無しさん
09/04/21 14:56:41
そうか、ＧＰＧＰＵだと他にまともな環境はないだろ
594:,,・´∀｀・,,）っ-○◎○
09/04/21 20:06:27
GPUにこだわる意味がないっていう
595:デフォルトの名無しさん
09/04/21 20:59:48
みんなcellで思い知っただろ？
そういうことだ。
596:,,・´∀｀・,,）っ-○◎○
09/04/22 05:34:39
.NETかGPGPUか選べる立場なら前者でいいんでない？
宗教上の理由でGPUの中でしか選択できない人がいるのももちろん知っております
597:,,・´∀｀・,,）っ-○◎○
09/04/22 05:44:26
強いて言えばOpenCLか？
URLﾘﾝｸ(www.nvidia.com)
598:デフォルトの名無しさん
09/04/22 12:06:34
ドトネトなんてLinuxで動かないじゃん。
*BSDでも動かない。糞。
とにかくGCCで動くようにしろよ。話はそれからだ。
599:デフォルトの名無しさん
09/04/22 16:21:07
.NETはmonaで動くだろ
600:デフォルトの名無しさん
09/04/22 16:25:47
ﾓﾅｰ
601:デフォルトの名無しさん
09/04/22 17:03:27
.NETはMONOで動くが、GCCで.NETアプリってコンパイルできたっけ？
602:,,・´∀｀・,,）っ-○◎○
09/04/22 22:19:21
CUDAかC#かって、ベクトルが全然別ですがな
>>601
Mono入れたらmcsってコンパイラが使えるようになるはずだが。。。
貴殿はGCCに入ってないという理由でPerlやPHPをも嫌うのですか？
603:デフォルトの名無しさん
09/04/22 22:45:40
問題はなぜこのスレは勢いがないのかってことだ
604:デフォルトの名無しさん
09/04/22 23:07:34
CUDAとOpenCLの認識の仕方として、
抽象レイヤ的にこんな感じかな？？
APP
--------
C/C++
--------
OpenCL
--------
CUDA
--------
driver and runtime
605:,,・´∀｀・,,）っ-○◎○
09/04/23 06:04:45
>>603
見た目簡単そうに見えて実は使いづらくて、本質はCellよりも更に応用分野は厳しいからね。
「CPUの数十倍とか言ってたけど全然遅いじゃん！」で、使い方を理解しないままみんな匙j投げる
いや、使い方がわかったところで、その正しい使い方が、本質的に目的のアプリケーション向きじゃなかったり。
606:デフォルトの名無しさん
09/04/23 07:22:35
そうそう、その演算だけに絞れば確かに速いんだけど、アプリケーション全体で見るとXeonに勝てなかったりね。
ボードメーカ側も自覚しているらしく、私の客先でのCUDA開発は2チップGPUボード4枚挿しするところまでいってしまっているし。
607:デフォルトの名無しさん
09/04/23 09:11:40
どうせララビーも期待外れに終るさ
608:デフォルトの名無しさん
09/04/23 16:09:19
nv社員乙ｗ
609:デフォルトの名無しさん
09/04/23 20:57:12
Larrabeeは、たかがx86、されどx86だな
Atomに毛が生えたような小規模なx86コアが数十コアあったら何が出来る？
汎用プロセッサとしては程度が知れてる分、逆に落胆しようがない。
良くも悪くも身の丈以上の期待はされてないからな。
610:デフォルトの名無しさん
09/04/23 21:20:24
流れをぶった切るが
GeforceはCELLより変態的な構造って認識でおk？
611:,,・´∀｀・,,）っ-○◎○
09/04/23 21:43:53
餅は餅屋
612:デフォルトの名無しさん
09/04/23 23:47:54
色々調べて見たけど結局CUDAのsuper piはまだ出てないんだな
CPUとGPUの比較が出来ると思ったのに
613:デフォルトの名無しさん
09/04/24 05:23:51
むしろスーチーパイがもっとリアルにぬるぬる動けば…
614:,,・´∀｀・,,）っ-○○○
09/04/24 06:37:53
＞スッチーのπ
まで読んだ
とりあえずPTXの自己コンパイルは最低限だろ
どっかの営業さんが言うにさ
「たとえCPUより速くなくとも、CPUでやってる仕事を肩代わりしてやることが
出来るだけでも使う価値があるんじゃないでしょうか」
いや、それのお膳立てのためにCPU時間食うから本末転倒なのよ。
615:デフォルトの名無しさん
09/04/24 06:44:16
＞「たとえCPUより速くなくとも、CPUでやってる仕事を肩代わりしてやることが
＞出来るだけでも使う価値があるんじゃないでしょうか」
そういうことを臆面もなく語る営業マンを一人知っているんだけどw
同一人物と考えてよさそうだな。
616:デフォルトの名無しさん
09/04/25 00:58:56
肩代わりしてやるなんて大それたことを無理に言い張るから、おかしくなるんだよね。
重要なのは、ＣＰＵとＧＰＵとが各々の得意分野を担当し、住み分けをすることだろう。
ＧＰＵは汎用計算に向いていないのだから無理にＧＰＵを使わずＣＰＵを使えばいいし、
３Ｄゲームや科学技術計算などＧＰＵの方が効率的な計算でＧＰＵを使えばいいんだよ。
いわゆるアインシュタインとタイピストの喩えだ。
アインシュタインが優れた物理学論文を清書してもらうためにタイピストを雇ったら、
なんとまあそのタイピストよりアインシュタインの方がタイプが速かったとしよう。
じゃあ、そのタイピストを解雇すべきか？答えは否だ。タイプはタイピストに任せ、
アインシュタインは少しでも長い時間、優れた物理理論を考え出すことに費やすべきだ。
それが最も効率がいい。
617:デフォルトの名無しさん
09/04/25 01:48:13
>>615
営業ならだいたい同じこと言うんじゃねぇか？
618:デフォルトの名無しさん
09/04/25 03:57:19
>>616
>答えは否だ。
いや、答えは科研費の額によるだろうｗ
619:デフォルトの名無しさん
09/04/25 05:08:45
>>616
タイピストに指示だすのに、タイプするのと同じような時間がかかるから問題なんじゃね？
620:,,・´∀｀・,,）っ-○○○
09/04/25 06:42:29
清書する段階で更に考えても無駄だろう
621:デフォルトの名無しさん
09/04/25 15:20:06
CPUを管理職、GPUを部下に例えてみよう。
CPUからGPUへの指示の中身が足りなかったりすると
CPU-GPU間のやりとりが増えてしまい遅くなる。
CPUから指示する内容がGPUの能力を超えると
なかなか結果が返ってこない。
逆にCPUの能力が低いとGPUへの指示や対応が遅くなる。
GPUの仕事に信用がおけないとCPU側でのチェックが
必要となり負荷となる。
GPUはCPUほど守備範囲は広くないし経験も少ない。
よいCPUやGPUを入手するには予算が必要である。
またCPU、GPUを動かし続けるには経費がかかる。（電気代、冷却設備）
あまり負荷をかけるとうるさくなったり、たまに壊れたりする。
overclockによる故障は保証の範囲外であることに注意。
622:デフォルトの名無しさん
09/04/25 15:22:15
GPUのIPコアが強化されれば良いんだが。
それをしようとして、intelに待ったを掛けられたんかな。
623:デフォルトの名無しさん
09/04/25 16:40:02
チップセットのバスライセンスと何の関係が？
624:デフォルトの名無しさん
09/04/25 18:21:57
たとえ話にすると細部の理解が必要ないから生半可な知識でも初心者が騙せて優越感に浸れてうめぇw
っていつも思う。
625:デフォルトの名無しさん
09/04/25 21:11:34
CPUとGPUは、お互いに交わる方向で
じきに差は無くなるんだろ
GPUいらねでおわりじゃねーの
626:デフォルトの名無しさん
09/04/25 21:13:38
昔GPGPUスレに書いたが、別のパラメータで同じコンテキストの処理をするようなときに
高速に処理できるのがGPUの利点。
別々のコンテキストが必要なら、丁度良いマルチプロセシングの環境を探しなさい。
どちらも歩み寄っているようだけど、ゲーム屋的には、現行世代機的なトランジスタ
バランスのマシンが次世代にも欲しいところ。
627:626
09/04/25 21:15:48
>>625
似たようなコストで作れるならな。
見当付いてるなら特許とって今すぐ始めるのがいいぞ。
628:,,・´∀｀・,,）っ-○○○
09/04/25 22:56:05
GTX280って28SMじゃなかったか？
629:,,・´∀｀・,,）っ-○○○
09/04/25 22:57:21
260のほうか
280は30か
630:デフォルトの名無しさん
09/04/26 17:16:50
>>619
常識的に考えてそんなことは起こらんだろ。
仮にタイピストに指示だすのにタイプするのと同じくらい時間がかかるなら、
それはこの喩えが適用できないケースだってだけの話だろう。
ＧＰＵに命令だすのにＧＰＵで計算するのと同じくらいＣＰＵ時間がかかるなら、
そりゃＧＰＵを使うのが不適切なケースだってだけのこと。
>>620
いや、清書してもらうのは既に考え出した理論であって、アインシュタインは
タイピストが清書してる間に次の理論を考えるんだよ。
631:デフォルトの名無しさん
09/04/26 17:24:31
たとえ話にすると細部の理解が必要ないから生半可な知識でも初心者が騙せて優越感に浸れてうめぇw
っていつも思う。
632:,,・´∀｀・,,）っ-○◎○
09/04/26 17:34:27
>>631に全面的に同意
633:デフォルトの名無しさん
09/04/26 18:23:11
>>624
>>631
634:デフォルトの名無しさん
09/04/26 23:38:55
>>625
ジョンカーマックが昔言ってたわな。それ。
ま、今は宇宙大好きっ子になっちまったが。
635:デフォルトの名無しさん
09/04/27 01:38:03
>>630
GPUを使うのが不適切なケースばっかりなのが問題。
636:デフォルトの名無しさん
09/04/27 09:13:30
アインシュタインは一人しかいないけど、CPUとGPUがアインシュタインとタイピストのような関係なら、
CPU増やせばいいんじゃね？無理にGPUにしなくても。
637:,,・´∀｀・,,）っ-○○○
09/04/27 21:24:06
なんにも出来ないのになんでも出来ますと宣伝してるから問題なわけで。
638:デフォルトの名無しさん
09/04/28 09:16:56
そらあんた、ドラッグレーサーをそれなりに走らせるためには適当なコースとそこまで運ぶためのトランスポーターと
燃料などの消耗品が必要になりますがな。
>>638
>631
639:デフォルトの名無しさん
09/04/28 12:52:26
>>637 団子
自己紹介、乙。
640:,,・´∀｀・,,）っ-○○○
09/04/28 21:36:19
だんごやさんだよ
だんごせんもんてんだよ
641:デフォルトの名無しさん
09/04/29 15:05:31
AviUtlがCUDAに対応するのを待つか…
642:デフォルトの名無しさん
09/04/30 21:33:03
某フィルタでシェーダで書いたより遥かに遅くて駄目だしされたような
643:デフォルトの名無しさん
09/05/03 00:16:21
今日、CUDASDK入れてみた。CudaSetup-2.1とNVIDIA_SDK10_CUDA_2.10の入れる順番なのか
環境変数でコンパイルエラー、何度かやっているうちになんとか、サンプルが起動できるようになった。
SDKのサンプルはどこにインストールしているんだ アホか C:\に持ってきた。
サンプルへのパスを追加してやっとコンパイル、起動できた。
644:デフォルトの名無しさん
09/05/03 00:24:59
>>643
2.1のサンプルって意味不明なとこおかれるよね。
VistaのUAC対策かと勝手に思ってるけど。
645:デフォルトの名無しさん
09/05/03 06:12:04
NVIDIAは昔っから何でもそう。
ドライバも一旦C:\に展開してからインスコしてくださりやがる。
まぁ、GCCやそれ用のライブラリが、スペースの入ったパスを
嫌うからかも試練。
646:デフォルトの名無しさん
09/05/04 00:48:26
2.0はちゃんとProgram Files配下に置かれてたよ。
647:デフォルトの名無しさん
09/05/04 23:00:36
>>635
ＧＰＵはゲームや科学技術計算では実績をあげているので、
不適切なケースばかりではないだろう。
>>636
アインシュタインという不世出の天才物理学者と
タイピストという（当時は）いくらでもいた職業を
比較しているのが、この喩えの肝なんだよ。
ＣＰＵのコアを１個増やすより、ＧＰＵのＳＰを１個
（１０個でもいい）増やす方が、ずっと簡単だろう。
648:,,・´∀｀・,,）っ-○○○
09/05/04 23:23:48
別にCPUコアなんて年間何億個でも量産できるだろ
649:デフォルトの名無しさん
09/05/05 05:38:26
タイピストが何人もいても意味無いだろｗ
650:デフォルトの名無しさん
09/05/05 22:12:00
こんなコア橋の下に捨てますよ!
651:デフォルトの名無しさん
09/05/06 08:41:31
Compute Capability 1.3 の GeForce って、GTX だけ?
GTS とかはだめなの?
ファンがうるさいのはやだな～
652:デフォルトの名無しさん
09/05/06 12:29:08
GTSは9800シリーズのリネーム
653:デフォルトの名無しさん
09/05/09 23:52:17
初歩的なこと聞くけど、これってグラボ一台でもできるよね？
表示用と別にCUDA専用のグラボって必要？
654:デフォルトの名無しさん
09/05/10 06:05:44
>>653
その程度が分からないと厳しいかと思いますよ。
分からなくても、やってみて駄目だったら買い足すってことで問題ないと思うけど。
655:デフォルトの名無しさん
09/05/10 12:20:36
>>653
URLﾘﾝｸ(ja.wikipedia.org)
656:デフォルトの名無しさん
09/05/10 18:27:35
>>655
赤くなっている。。。
GTS250持っているからできると思ったんだけど、二台必要なのかな？
GPUGRIDに参加しようかと思ったらドライバ入れてるのにCUDA対応のデバイスが見つかりませんっていわれるし・・・・。
657:デフォルトの名無しさん
09/05/10 20:56:39
1台でも使える。
ただ処理中に画面が固まってOSが制御不能になることがある。
658:デフォルトの名無しさん
09/05/10 21:24:34
>>657
うーん、CUDAがちゃんと入ったかどうか確認する方法ってありますか？
659:デフォルトの名無しさん
09/05/11 15:35:15
PyCUDAなんてあるのか、おもしろそう
660:,,・´∀｀・,,）っ-○◎●
09/05/11 20:57:31
RuCUDAが必要だな
661:デフォルトの名無しさん
09/05/11 21:41:12
>>656
参加したいGPUGRIDがどんなのか分からんが、
もし、倍精度浮動小数点の演算が必要なものなら、
GTX200シリーズじゃないと無理。
ちなみに、モニタがつながっているかPhysX指定がされてないと、
CUDAでデバイス列挙されないぽい。
662:デフォルトの名無しさん
09/05/12 01:29:13
Py損とかルビィとか手続き型スクリプト言語は向かんだろ。
ocamlとか、Earlangとかの関数型言語をGPGPU対応に
した方が御利益は大きいんじゃね?
並列計算の場合、副作用とか、計算の依存関係が有ると
性能出ないんで…。
663:デフォルトの名無しさん
09/05/12 22:31:21
Earlang（笑）
664:デフォルトの名無しさん
09/05/16 00:29:01
統計解析ソフト「R」用のパッケージ「gputools」：
URLﾘﾝｸ(cran.r-project.org)
これのWindows版バイナリを作ってくださるネ申はいらっしゃいませんでしょうか。 m(ﾟ-ﾟ；)ｶﾐｻﾏ…
665:デフォルトの名無しさん
09/05/16 10:27:22
>>660
こんなのはあるみたいですが
URLﾘﾝｸ(ruby-opencl.rubyforge.org)
666:デフォルトの名無しさん
09/05/18 17:38:13
GPUの計算部分で
レジスタを多く使っちゃうようにコンパイラで最適化されちゃうんだけど
部分的に無効にする方法はありませんか？
667:,,・´∀｀・,,）っ-○○○
09/05/18 20:36:57
volatile
668:デフォルトの名無しさん
09/05/18 23:05:56
>>667
？volatileは最適化から外すだけで、レジスタには適応されるっしょ
つか>>666 のレジスタ使ったら嬉しくない事ってのが想像できない。。。
669:デフォルトの名無しさん
09/05/18 23:42:16
>>648
ＳＰだって年間何億個でも量産できるけど。
>>649
誰も、ＧＰＵを何個も用意しろとは言ってない。
670:,,・´∀｀・,,）っ-○○○
09/05/18 23:56:12
>>668 volatile __shared__
671:デフォルトの名無しさん
09/05/19 09:21:51
>666の動機によっては__shared__では何の解決にもならないような。
確認していないけれど、恐らくレジスタを使い回さずに消費しまくる方が速いんだろうねぇ。
672:デフォルトの名無しさん
09/05/26 14:36:24
SP2＋未公開パッチで7RC以上に軽くなってるよ
Windows Vista SP3 Part1
ｽﾚﾘﾝｸ(win板:225番)
673:デフォルトの名無しさん
09/05/26 14:38:56
ｺﾞﾊﾞｰｸ
674:デフォルトの名無しさん
09/05/29 18:11:27
SSE ４コアフルに使ったら
最上位品でも大差ないｗ
675:デフォルトの名無しさん
09/05/30 15:06:57
URLﾘﾝｸ(code.google.com)
>Thrust is a CUDA library of parallel algorithms with an interface resembling the C++ Standard Template Library (STL).
676:,,・´∀｀・,,）っ-○○○
09/05/30 18:16:26
きた！STLきた！これで勝つる！
ないない
677:デフォルトの名無しさん
09/05/30 21:28:10
brookみたいだな。
678:デフォルトの名無しさん
09/06/02 17:20:15
仮想マシン上でCUDAのインストールに成功した方はいらっしゃいますか？
当方、ホストOS：Vista、ゲストOS：Ubuntu8.04です。
仮想マシンであるUbuntu上で、NVIDIAドライバ: NVIDIA-Linux-x86-180.22-pkg1.runを起動してみました。
すると、「 You do not appear to have an NVIDIA GPU supported by the 180.22 NVIDIA Linux graphics driver installed in this system」とエラーがでました。
GPUは、GeForce 9800 GTです。どなたか、アドバイスお願いします。
679:デフォルトの名無しさん
09/06/02 17:50:02
仮想マシンは無理
680:デフォルトの名無しさん
09/06/03 02:45:20
>>675
合計なんかCUDAでやって早くなるのか？
681:,,・´∀｀・,,）っ-○○○
09/06/03 02:49:18
分割統治法は並列化の基本だな
682:デフォルトの名無しさん
09/06/03 10:53:10
合計求めるのは苦労したなぁ。
結局、分割数(128とか256とか)置きに足していって、その結果はPCで足した記憶がある。
683:デフォルトの名無しさん
09/06/03 11:18:35
とりあえず公式の３つをインストールしたのですがTMPGEncで確認できませんみたいなことを言われました。
インストールするだけではcudaの恩恵を与れないのでしょうか?
684:デフォルトの名無しさん
09/06/03 11:31:01
すいません、直ぐ解決しましたorz
ｸﾀﾞがちゃんと動いているか確認したいのですが方法はありますでしょうか？
685:デフォルトの名無しさん
09/06/03 11:57:52
>>684
SDKをインストールしたのなら、サンプルもインストールしてビルドしてみよう。サンプルが動けば、大丈夫。
# 特に、deviceQueryは便利。
686:デフォルトの名無しさん
09/06/03 14:12:00
こんにちは。CUDA初心者です。質問があります。
Visual C++ 2008、CUDA tool kit ver2.1、CUDA SDK ver2.1
で、サンプルのsimpleCUBLASをビルドすると、
1>LINK : fatal error LNK1181: 入力ファイル 'cutil32D.lib' を開けません。
と出ます。
そこで、CUDA SDKのlibを調べたところ、
cutil64D.libがあり、32のほうはありませんでした。
この場合、どうすればビルドできるのでしょうか？
687:デフォルトの名無しさん
09/06/03 15:00:01
リリースバージョンをリンクする。
688:デフォルトの名無しさん
09/06/03 16:01:01
リリース構成でビルドしたところ、今度は、
1>LINK : fatal error LNK1181: 入力ファイル 'cutil32.lib' を開けません。
と出ました。
CUDA SDKには、64があり、32はありません。
32と64の違いって一体何なのでしょうか・・・
689:デフォルトの名無しさん
09/06/03 16:17:51
パスが通ってないんだろ
690:デフォルトの名無しさん
09/06/03 17:07:17
OSが64bitだと、32bitのCUDAライブラリはインストールされなかったような。
691:デフォルトの名無しさん
09/06/03 17:07:40
ご回答ありがとうございます。
パスが通っていないということですが、
「パスを通す」について、詳しく説明していただけませんか？
知識不足で申し訳ありません；；
692:デフォルトの名無しさん
09/06/03 17:43:34
環境を名に使ってるかによるが、
Visual Studioだとプロジェクトのプロパティからインクルードするファイルがあるディレクトリのパスと、
libがあるディレクトリのパスをついかする
linuxだとコンパイラのオプションに追加する
詳しくはぐぐれ
693:デフォルトの名無しさん
09/06/03 18:04:37
何度も回答していただきありがとうございます。
リンカの追加ライブラリを調べたところ、
ちゃんと、SDKのcommon/libが指定されてました。
しかし、この中には、cutil32.libではなく、64があります。
ということは、690さんのおっしゃるとおり、
32bitのCUDAライブラリはインストールされなかったということなのでしょうか？
もしそうでしたら、サンプルプログラムは64bitに対応してないが、
自分でプログラムを作る分には、上記のようなエラーはでないということでしょうか？
694:デフォルトの名無しさん
09/06/03 23:53:30
サンプルのリンカ設定を編集して64bitのライブラリをリンクすればいいんじゃね？
695:デフォルトの名無しさん
09/06/04 13:12:53
アクティブソリューションプラットフォームとプラットフォームをWin32からx64へ変更したところ、
エラーがなくなりました。
そのかわり、
1>------ ビルドのスキップ: プロジェクト: simpleCUBLAS ------
1>
========== ビルド: 0 正常終了または最新の状態、0 失敗、1 スキップ ==========
とスキップしてしまいました。
何が原因なのでしょうか・・・
696:デフォルトの名無しさん
09/06/04 18:26:30
threadIdx.xがうまく値を返さなく困っています。
最小のプログラミングだと ちゃんとした値を確認できるんですけど、
規模のあるプログラム書いた物では、threadIdx.xをみると最大でも1000以内の数値が40000を超えていたりします。
かなりラフな書き方していて、グローバル変数使いまくってるのが意見ないのでしょうか？
__device__ kouzoutai[2000];//グローバル変数
とか宣言しまくって搭載メモリーを超えちゃってるかもしれませんが、その時は明確なエラーとか出ますか？