【GPGPU】くだすれCUD ..
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
俺の場合英語と日本語だと読むスピードが10倍〜100倍違う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本すべて汎用レジスタだったらよかったんだけどw
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のアーキテクチャで凝り固まってて、現代風のプログラミングパラダイムについて来れないってことだろ。
あと10年もすればおまえの持ってる小手先業などは博物館の展示資料でしかないし、おまえの能書きなど頑固オヤジの戯言同じなるだろう。
インテルのブログで洗脳されまくっちゃうのもいいけど、アーキテクチャマニュアル云々よりも団子が頭の切り替えをできるかどうかのほうが問題なんじゃないの?
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あたりがまさにこれをやってるわけだが。
> あと10年もすればおまえの持ってる小手先業などは博物館の展示資料でしかないし、おまえの能書きなど頑固オヤジの戯言同じなるだろう。
残念だが俺は流行りものの言語・フレームワークには目がない。
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
頑固オヤジの戯言ごとと同じになるだろう。
ニート相手に5行も書くの面倒だから誤字脱字なおすのも面倒だよな。
「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年後に100GHzとか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とか便利だし、かゆいところは自分でコード書けばいいんじゃないか。
今の時代、30分で作れるのに一からメモ帳作る奴はよっぽどバカでしょ。
505:デフォルトの名無しさん
09/03/09 07:03:23
ああ抜けてた。
コピペって簡単に言うけど、典型コードの再利用なわけでだからこそメモ帳アプリが30分で作れる威力があるんだけど。
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
ワロタw
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の実装の話になったんだ。
話そらすのが上手いなww
そもそも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
おまえはヒマになると2ch開いてるだろ?w
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
1ブロックの最大スレッド数を使った計算じゃ、GPUの処理速度がCPUに対して上回らなかったので
ブロック数を増やして計算しようと思ったんですが、1ブロック制限に到達した時、どうやって次のブロックに
移動すんのかが、記述の仕方がかなりよくわからないんです。
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
レスサンクス、ガイドとSDKもう一回見てきます
591:デフォルトの名無しさん
09/04/20 22:01:56
CUDAスレって何でこんなに勢いが弱いの?
592:デフォルトの名無しさん
09/04/20 23:13:01
ぶっちゃけ2年後位には廃れてると思うからやる気がしない
日本語資料少ないし
.netでもやってる方がつぶしがきく
593:デフォルトの名無しさん
09/04/21 14:56:41
そうか、GPGPUだと他にまともな環境はないだろ
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社員乙w
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
肩代わりしてやるなんて大それたことを無理に言い張るから、おかしくなるんだよね。
重要なのは、CPUとGPUとが各々の得意分野を担当し、住み分けをすることだろう。
GPUは汎用計算に向いていないのだから無理にGPUを使わずCPUを使えばいいし、
3Dゲームや科学技術計算などGPUの方が効率的な計算でGPUを使えばいいんだよ。
いわゆるアインシュタインとタイピストの喩えだ。
アインシュタインが優れた物理学論文を清書してもらうためにタイピストを雇ったら、
なんとまあそのタイピストよりアインシュタインの方がタイプが速かったとしよう。
じゃあ、そのタイピストを解雇すべきか?答えは否だ。タイプはタイピストに任せ、
アインシュタインは少しでも長い時間、優れた物理理論を考え出すことに費やすべきだ。
それが最も効率がいい。
617:デフォルトの名無しさん
09/04/25 01:48:13
>>615
営業ならだいたい同じこと言うんじゃねぇか?
618:デフォルトの名無しさん
09/04/25 03:57:19
>>616
>答えは否だ。
いや、答えは科研費の額によるだろうw
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
常識的に考えてそんなことは起こらんだろ。
仮にタイピストに指示だすのにタイプするのと同じくらい時間がかかるなら、
それはこの喩えが適用できないケースだってだけの話だろう。
GPUに命令だすのにGPUで計算するのと同じくらいCPU時間がかかるなら、
そりゃGPUを使うのが不適切なケースだってだけのこと。
>>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
GPUはゲームや科学技術計算では実績をあげているので、
不適切なケースばかりではないだろう。
>>636
アインシュタインという不世出の天才物理学者と
タイピストという(当時は)いくらでもいた職業を
比較しているのが、この喩えの肝なんだよ。
CPUのコアを1個増やすより、GPUのSPを1個
(10個でもいい)増やす方が、ずっと簡単だろう。
648:,,・´∀`・,,)っ-○○○
09/05/04 23:23:48
別にCPUコアなんて年間何億個でも量産できるだろ
649:デフォルトの名無しさん
09/05/05 05:38:26
タイピストが何人もいても意味無いだろw
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
Wikipedia項目リンク
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
SPだって年間何億個でも量産できるけど。
>>649
誰も、GPUを何個も用意しろとは言ってない。
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 4コアフルに使ったら
最上位品でも大差ないw
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みたいだな。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5334日前に更新/215 KB
担当:undef