09/08/01 07:37:39
これでいいじゃん
URLﾘﾝｸ(tmkk.hp.infoseek.co.jp)
819:デフォルトの名無しさん
09/08/02 20:49:45
３００Wも消費する物体を数週間動かすとは恐ろしいｗ
820:デフォルトの名無しさん
09/08/03 07:25:23
shared memoryって,CPUで言うL1キャッシュみたいなもん？？
821:デフォルトの名無しさん
09/08/03 08:04:31
>>818
これって使うとどれくらい寿命減るの？
作った人って絶対に高負荷かけて石を壊そうとしてるよね・・・
822:デフォルトの名無しさん
09/08/03 15:36:31
>>821
なにいってるの・・・
まあたしかにファンがクソだと熱で死ぬ可能性はあるが
823:デフォルトの名無しさん
09/08/04 03:54:01
>>820
大分違う。つーか、CPUとは考え方を変えないと使いこなせないよ。
824:デフォルトの名無しさん
09/08/04 10:08:33
>>820
CPUで言うレジストリみたいなもんだ
825: ◆DokuomoeW.
09/08/04 13:52:22
>>818
for Macだ…と
826:,,・´∀｀・,,）っ-○○○
09/08/04 21:07:21
Windows用に直せるだろこんなん。（と言ってやらない）
827:,,・´∀｀・,,）っ-○○○
09/08/04 22:06:06
Vistaだと困ったことに、描画に支障ない程度に負荷調整しないとAeroが死ぬｗｗｗ
828:デフォルトの名無しさん
09/08/08 22:45:00
だれかトリップ生成のアルゴリズム説明して？
趣味でCUDA処理のコード書いてみたいからー
>>818のコード読めって話だけど、ハッシュとか暗号系はアルゴリズム知ってないと、時間かかるんでお願いします。
829:デフォルトの名無しさん
09/08/08 23:22:43
309 名前：◆cZfSunOs.U []： 2009/06/19(金) 11:46:10 ID:MLNb4KfK0 (17)
生キー指定以外の12桁以上「##～」形式も将来の拡張用にしておきましょう．
で，まとめ:
if (length $handle_pass >= 12)
{
my $mark = substr($handle_pass, 0, 1);
if ($mark eq '#' || $mark eq '$')
{
if ($handle_pass =~ m|^#([[:xdigit:]]{16})([./0-9A-Za-z]{0,2})$|)
{
$GB->{TRIPSTRING} = substr(crypt(pack('H*', $1), "$2.."), -10);
}
else
{
# 将来の拡張用
$GB->{TRIPSTRING} = '???';
}
}
else
{
use Digest::SHA1 qw(sha1_base64);
$GB->{TRIPSTRING} = substr(sha1_base64($handle_pass), 0, 12);
$GB->{TRIPSTRING} =~ tr/+/./;
}
}
else
{
# 従来形式
}
830:デフォルトの名無しさん
09/08/08 23:23:28
インデント消えたorz
831:デフォルトの名無しさん
09/08/08 23:25:49
Kernel用のCRYPTを自前実装しないといけないのか・・
832:,,・´∀｀・,,）っ-○○○
09/08/09 00:05:13
C++用のコード晒してみる。これは実際に某ツールで使ってる。
char* trip_sha1(const char* key) {
SHA1Context sha1;
SHA1Reset(&sha1);
SHA1Input(&sha1, reinterpret_cast<const uint8_t*>(key), std::strlen(key));
uint8_t digest[SHA1HashSize];
SHA1Result(&sha1, digest);
static char cryptresult[13]; /* encrypted result */
static const char base64mod[] = /* 0..63 => ascii-64 */
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789./";
cryptresult[0] = base64mod[digest[0] >> 2];
cryptresult[1] = base64mod[(digest[0] << 4 | digest[1] >> 4) & 0x3F];
cryptresult[2] = base64mod[(digest[1] << 2 | digest[2] >> 6) & 0x3F];
cryptresult[3] = base64mod[digest[2] & 0x3F];
cryptresult[4] = base64mod[digest[3] >> 2];
cryptresult[5] = base64mod[(digest[3] << 4 | digest[4] >> 4) & 0x3F];
cryptresult[6] = base64mod[(digest[4] << 2 | digest[5] >> 6) & 0x3F];
cryptresult[7] = base64mod[digest[5] & 0x3F];
cryptresult[8] = base64mod[digest[6] >> 2];
cryptresult[9] = base64mod[(digest[6] << 4 | digest[7] >> 4) & 0x3F];
cryptresult[10] = base64mod[(digest[7] << 2 | digest[8] >> 6) & 0x3F];
cryptresult[11] = base64mod[digest[8] & 0x3F];
cryptresult[12] = 0;
return cryptresult;
}
833:デフォルトの名無しさん
09/08/09 00:36:34
ｓｈ１のCUDA版くらいありそうだけど
834:828
09/08/09 00:38:07
ご両人、コードさんくす～
実はC住人なんで（汗
蛇足だが関数内のstaticの使い方が気持ち悪いです（笑
さー昔しらべたSHA-1の資料でもひっぱってくるかー
835:,,・´∀｀・,,）っ-○○○
09/08/09 01:53:23
オリジナルのcrypt(3)でもchar配列はstaticでとってるんだよな
たしかにキモイ
std::stringとか使ってみ？
CUDAに移植できへんで？
836:デフォルトの名無しさん
09/08/09 01:56:33
笑えるくらいきれいなワンツーｗ
837:デフォルトの名無しさん
09/08/09 01:57:37
ごば
838:デフォルトの名無しさん
09/08/09 13:04:04
CUDAでrandは使えない？
839:デフォルトの名無しさん
09/08/09 13:11:14
>>838
使えないよ。自分で用意しないと。
840:デフォルトの名無しさん
09/08/09 13:25:21
CUDA上でのSHA1の実装というとこのあたりか？
URLﾘﾝｸ(forums.nvidia.com)
841:デフォルトの名無しさん
09/08/10 22:49:48
r0,g0,b0,r1,g1,b1,r2,....
というようなグローバルメモリにあるchar型の配列に対して、GPU側からuchar4型変数で
{r0,g0,b0,r1} {r1,g1,b1,r2},....
というようにアクセスすることは可能でしょうか？
842:デフォルトの名無しさん
09/08/11 01:04:40
y*4+x
843:841
09/08/11 01:59:08
あーこれじゃ駄目だった
ごめんなさい、忘れてください
844:828 ◆TripEQ.VNLIV
09/08/11 21:13:55
だめだー
SHA1と総当り攻撃じゃ現実的じゃない。。。
4桁適合ならまだ使える感じorz
845:デフォルトの名無しさん
09/08/21 13:47:21
誰かRADEON HD48xx向けのCUDAドライバ開発してないの？
846:デフォルトの名無しさん
09/08/21 14:23:41
>>845
どちらかというと
AMD Accelerated Video Transcoding（AVT）
では？
847:デフォルトの名無しさん
09/08/21 16:05:07
いや、CUDA互換機能つけて
CUDA対応ソフトを使えるようにならんかなーと。
848:デフォルトの名無しさん
09/08/21 17:49:44
>>847
OpenCLじゃだめですか？
849:デフォルトの名無しさん
09/08/21 17:50:52
ラッパー作ってくれるならいいけど・・・
既存のソフトでCUDAにしか対応してないやつとか
CUDA以外の開発環境が整わなさすぎて、見切り発車でCUDA使いたいなとか
あるんで。
850:デフォルトの名無しさん
09/08/21 18:44:14
CUDAってOpenCL取り込んでたような……気のせい？
851:,,・´∀｀・,,）っ-○○○
09/08/21 20:13:56
CUDAは環境。
OpenCLは言語・フレームワークで、CUDA向けのプログラムを記述出来る物のひとつ。
従来の「CUDA言語」は "C for CUDA" という扱いになった。
852:デフォルトの名無しさん
09/08/21 20:36:51
x64でCUDAをしようと思ったんだけど，vitual studioでプロジェクトが作れない．
CUDA_VS_Wizard_W64.2.0を入れて，
CUDA64WinAppはテンプレートとして表示されるようになったが，
選択してもうまく生成されない．
CUDAWinApp(32bit)の方はうまく生成される．
64bitで開発してる方や，
症状の原因がわかりそうな方，ご教授願う．
853:デフォルトの名無しさん
09/08/21 21:00:40
おっと，自己解決．
スレ汚しスマソ．
854:デフォルトの名無しさん
09/08/21 23:07:09
>>853
いや、教えてよ（笑）
855:デフォルトの名無しさん
09/08/23 20:28:04
共有メモリのBank Conflictがいまいちわからないのですが、
同じ配列のアドレス(添え字)に複数のスレッドが同時にアクセスしなければいよいのでしょうか？
856:デフォルトの名無しさん
09/08/26 07:21:12
最近のマザボってPCIEx16が普通に2,3個あるよな
ところで違う世代のGeForce9800、GTX280とかを積んだ場合
CUDAはどちらのGPUも使ってくれるの？
857:デフォルトの名無しさん
09/08/26 09:24:02
>>856
CUDAはGPUチップを一つだけしか使えない。
どれを使うかは、cudaSetDevice()で指定しないといけない。
サンプルの、MultiGPUを参照のこと。
858:デフォルトの名無しさん
09/08/26 18:32:52
ということは，
最近のグラボ一枚にGPUが2つ積んであるヤツでも，
GPUを指定してやらないといけないのか．
859:デフォルトの名無しさん
09/08/26 18:39:49
そそ、しかも1スレッド1GPUに拘束される。
860:デフォルトの名無しさん
09/08/26 19:17:17
>>858
未確認だけど、SLIの場合はドライバで1つのGPUに見せかけるらしい。
2チップを積んでいるカードは内部でSLI接続されているらしいし、
1デバイスの場合と同じでもいいかもしれない。
861:デフォルトの名無しさん
09/08/26 23:51:13
SLIとCUDAは同時使用できないとかじゃないのか？
862:デフォルトの名無しさん
09/08/27 00:10:58
URLﾘﾝｸ(forum.nvidia.co.jp)
* SLIグループ内の各GPUは個別に列挙されるようになったため、
計算アプリケーションはSLIがグラフィックス向けに有効になっている
場合でも、マルチGPUの性能を活用することができます。
と、リリースノートにはあるね
863:デフォルトの名無しさん
09/08/27 00:25:41
>>862
2.3からはSLIの場合でもCUDAからは個別に見えるように変更なのか。
SLIでゲームの中でPhysXとかCUDAを使う場合とかは特定のチップに負荷が集中して
そのせいで利用効率が落ちたりしないのかな？
864:デフォルトの名無しさん
09/08/27 01:23:53
プログラマが生理整頓するか，
CUDAさんよろしくお願いしますするか，どっちがいいかってことか．
でも，一度の演算に対して，1コアにスレッドが重複しない限りは，
無駄に複数のGPUに処理を分配する必要性はないよな．
演算の命令ごとにGPUを切り替えるなら，効果はありか．
SLIの場合って，GPUのRAMは共有されるのか？
>>859
GPUはGPU内の大量のコアがそれぞれ1スレッドずつ受け取る仕組みじゃないのか？
1スレッド1GPUって並列演算ってレベルじゃねーぞ．
865:デフォルトの名無しさん
09/08/27 03:53:53
>>864
「スレッドを受け取る」っていう意味がわからんのだが。
CPUの１スレッドがGPU１個使って、そのGPUが複数スレッドを実行する。
866:デフォルトの名無しさん
09/08/27 04:59:54
>>865
CPUのスレッドなのね．
スレッドのことをGPUのハードウェアスレッドかと勘違いしてた･･･orz
867:デフォルトの名無しさん
09/09/01 18:44:53
CUDAがでてきた2005年当時は、シングルコアの限界も見えてきて、それなら
有り余るグラフィックボードの性能を、3Ｄレンダリングや、フォトショップフィルタなど、ゲーム以外にも有効活用と歌ってたけど
あれよあれよという間に、インテルCPUがマルチコア化してきて、そっちの方が上記の用途に、大きな効果があり、メインになってきて、
結局グラフィックボードは、結局またGPUはゲーム以外に用なしになったなｗ
868:デフォルトの名無しさん
09/09/01 19:21:06
U-BASICってバージョンアップしないの？
869:デフォルトの名無しさん
09/09/01 19:38:01
>>867
コンシューマーはそうかもしれんけど、エンタープライズはまた少し違うんじゃない？じゃなきゃNVIDIAもTESLAなんて作らんよ。
870:デフォルトの名無しさん
09/09/01 20:10:53
ああシールの貼り替えで10倍の金を取るために始めたアレか
871:デフォルトの名無しさん
09/09/01 23:00:56
>>870
本気でそう思ってるなら偏狭すぎる。少しは頭使えよ
872:デフォルトの名無しさん
09/09/02 00:04:27
>>869
むしろ、nVIDIAはTESLA以外作りようが無かったんでしょ。
だってCPU作れないんだもん。
873:デフォルトの名無しさん
09/09/02 02:29:04
NVIDIA は、2009年8月17日、業界標準の線形代数ライブラリ、LAPACK を、超並列処理の NVIDIA CUDA 対応 GPU に最適化した実装「CULA」のベータ版が EM Photonics 社からリリースされたと発表した。
LAPACK ルーチンは何百万人もの開発者が活用し、数値物理学、構造力学、電子設計オートメーションなどさまざまな問題の解決に役立てられている。
CULA により、ワークステーションやデータセンターで使われている NVIDIA Tesla GPU の力を活用し、クアッドコア CPU 1個の場合でパフォーマンスを最大10倍に引き上げることが可能になるとされる。
EM Photonics には、CULA Basic、CULA Premium、CULA Commercial からなる CULA tools という製品ファミリがある。CULA ライブラリとは、LAPACK ルーチンの実装の1つで、GPU の能力を活用して高速に処理が行えるようにしたもの。
LAPACK というのは線形代数でよく使われる関数の集合体で、科学分野や工学分野で活用されている。科学分野や工学分野の問題は線形モデルで近似できることが多いため、線形代数ルーチンで解が得られる。
CULA は、NVIDIA GPU が持つ超並列 CUDA アーキテクチャを活用し、LAPACK ルーチンの多くを高速で処理できる。
874:デフォルトの名無しさん
09/09/02 08:05:49
>>872
それ以外作りようがなかったからって…事前事業でやってるんじゃないんだぞ？「しょうがなくTESLA作る」とかありえないんだよ。純粋に、戦略的なマーケティングの結果だろ。
875:デフォルトの名無しさん
09/09/02 08:10:12
>>874
× 事前
◯ 慈善
876:デフォルトの名無しさん
09/09/02 09:31:55
戦略的なマーケティングの結果、マザボは作れてもCPUは作れないNVIDIAは仕方なしに、
TESLAをでっち上げたわけですね、判ります。
877:デフォルトの名無しさん
09/09/02 12:41:59
CPUは作れないってどういう意味で言ってるんだろ
x86互換プロセッサなんて作れるところはいくらでもある
ただライセンスの問題なダケ
あとはマーケットな
878:デフォルトの名無しさん
09/09/02 12:46:20
x86互換プロセッサぐらいなら大学の授業でFPGAに実装したことあるぞ
879:デフォルトの名無しさん
09/09/02 12:51:56
互換なんてダレでも作れるべ
性能はムリだが
880:デフォルトの名無しさん
09/09/02 12:58:32
DXCSがくるからCUDAはもういらないかもー
881:デフォルトの名無しさん
09/09/02 12:59:56
作るだけならVIAにだってできる
882:デフォルトの名無しさん
09/09/02 13:07:09
↑↑お前出来ないだろｗ
883:408
09/09/02 14:49:32
NVIDIAってCUDA捨てたん？
ここ1年ぐらい見る限りすげーやる気なさそうなんだけど。
884:デフォルトの名無しさん
09/09/02 15:18:52
捨ててないけどやることないだけだろ
885:デフォルトの名無しさん
09/09/02 17:51:42
今はOptiXに期待
886:デフォルトの名無しさん
09/09/02 18:43:14
URLﾘﾝｸ(news.developer.nvidia.com)
おまいら，
9月30日以降に期待ですよ．
887:デフォルトの名無しさん
09/09/02 21:10:27
CUDAで最適化したいプログラムに条件分岐満載で
実際の演算部分がほとんどなくてDate並列化できそうもないときって
あきらめるしかないのかな･･･。
888:,,・´∀｀・,,）っ-○○○
09/09/02 22:49:22
URLﾘﾝｸ(www.atmarkit.co.jp)
Fixstarsのエンジニアからの有り難い言葉
889:デフォルトの名無しさん
09/09/02 23:43:18
条件分岐でシーケンスを発生させる事そのものが目的でなけりゃ、
何か手はあるんでないの？
何しようとしてるか知らんけど、今使ってるアルゴリズムに以外に
GPU向きの手がないか調べてみたらいいんでない？
890:デフォルトの名無しさん
09/09/03 15:42:37
やっぱりx86コアが100個も200個もあるほうがいいんじゃね？
891:デフォルトの名無しさん
09/09/03 17:29:08
>>889
なるほど
もっとソースを読んで見るよ。
あとCUDAについてのオススメの文献あるかな？
892:デフォルトの名無しさん
09/09/03 21:47:44
>>891
GPU Gems3。訳本はアホみたいに高いが、英語でよければネットで公開されてる。途中までだけど。
893:デフォルトの名無しさん
09/09/03 21:52:19
>>890
そりゃそうかもしれんが、コスト見合わんだろ。
894:,,・´∀｀・,,）っ-○○○
09/09/03 22:31:48
x86のほうが性能マシな演算用途こそ、GPUが何百台あってもコスト的に見合わないんじゃないかと
895:デフォルトの名無しさん
09/09/03 22:43:05
>>892
thx
でかい書店いって立ち読みして検討するかな。
>>894
そうとも限らない。
32bit単精度浮動小数点を扱えるプロセッサが数百個あるわけで、
プログラムの仕方によっては高速化する。
まあ向き不向きがあるのは事実だし、どっちが良いとは決め付けられない。
896:,,・´∀｀・,,）っ-○○○
09/09/03 22:47:43
向き不向きでいえばGPUに向いてない（というか使うことすらできない）演算の方が圧倒的に多い。
897:デフォルトの名無しさん
09/09/04 01:37:54
円周率の計算とかに使えればいいじゃん。
898:,,・´∀｀・,,）っ-○○○
09/09/04 02:08:24
なにそれ誰が得するの？
899:デフォルトの名無しさん
09/09/04 02:10:35
円周率を100万桁まで暗記してる人が、あれ？次なんだったっけって言って調べられる
900:デフォルトの名無しさん
09/09/04 05:48:21
GPUが今後発展するなら、GPUに向いたアルゴリズムが開発されてくるでしょう。
でも、普通のCPUが高速化してくるので、結局特定の分野しか使えないのかもね。まさにハードウェアアクセラレータ。
901:デフォルトの名無しさん
09/09/04 16:30:49
全く依存性がなく並列に計算できるものに向いてるんだっけ？
あんまり計算用途には向いてない気もするんだけど。
902:デフォルトの名無しさん
09/09/04 17:05:27
実際高速化されてるものもあるんだし、得している奴はいるだろ
903:デフォルトの名無しさん
09/09/04 17:31:22
粒子法では，GPUかなり美味しいです＾＾
904:デフォルトの名無しさん
09/09/04 17:34:46
画像や文字のパターンマッチングにもそれなりに使えるよ。
905: ◆TripEQ.VNLIV
09/09/04 21:24:41
実は一般ユーザーが恩恵を受ける事はほとんどない事実。。。
906:デフォルトの名無しさん
09/09/04 22:19:54
ATI臭くなってきたぞ，このスレ
907:デフォルトの名無しさん
09/09/05 01:41:57
ATIのGPUでCUDAが使えるならともかく使えないのに、
なぜかCUDAスレでATIの話題がされる不思議。
908:デフォルトの名無しさん
09/09/05 04:37:45
ATOM３３０搭載PCでCUDAなグラボを付けたら幸せになりますか？
909:デフォルトの名無しさん
09/09/05 05:32:50
>>908
気持ち次第です。
910:デフォルトの名無しさん
09/09/05 07:55:02
NVIDIAへの財務次第です
911:408
09/09/05 09:50:44
あきらかに落ち目でしょNVIDIA