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


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

cellプログラミングしちゃいなよ3



1 名前:デフォルトの名無しさん mailto:sage [2008/07/07(月) 08:55:08 ]
前スレ

Cellプログラミングしちゃいなよ2
pc11.2ch.net/test/read.cgi/tech/1183091522/

523 名前:デフォルトの名無しさん mailto:sage [2009/01/19(月) 01:10:02 ]
>>520
SPEのLSはポート一個しか無いので、DMAやload,storeが頻発すると、命令フェッチができなくなる場合がある。
Handbook の 3.1.1.3 に、優先度は、 DMA > load,store > 命令フェッチ と書いてある。
命令フェッチが必要な場合は、hbrp命令すると優先度が上げられる。

詳細は、
ttp://cell.scei.co.jp/j_download.html
「プロセッサにおける命令枯渇に起因する Synergistic Processor Elementの無限ストールの防止について」
あたりに書いてある気がするが、読んでもよくわからん。

524 名前:227 ◆eZQcaIaFJs mailto:sage [2009/01/19(月) 01:16:02 ]
とりあえず詰ませてみたけど、asmvis 見てもどこでストールが起きてるのか
分からない状態。片っ端から nop/lnop 入れて検証するのかぁ…orz

>>521
カンで16か20とみた。調子に乗ってループ展開しまくっていた頃だから、
知らない間にリミットを追えてしまったのかもしれませんね。


525 名前:202 mailto:sage [2009/01/19(月) 01:23:42 ]
>>524
分岐ヒント命令のレイテンシが15cycleだから、それ以下の可能性が高い。
12cycle=24命令か8cycle=16命令分でオチるんじゃないかな。

526 名前:デフォルトの名無しさん mailto:sage [2009/01/19(月) 01:42:57 ]
>>523
DMA 用と load/store & ifetch 用の2ポートだった希ガス。
今回は DMA 関係ないけど、DMA は待たせられないからね。
で、load/store と ifetch でポート共有してるから、ifetch が
ストールしないように、load/store は続けちゃだめよ、と。

527 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/19(月) 08:09:41 ]
謎のデチューン(笑)で性能改善された説明になるな。
メモしておこう


528 名前:デフォルトの名無しさん mailto:sage [2009/01/19(月) 12:42:42 ]
学生でやってるけど10倍すらキツい
アセンブラ命令と複数対1命令で対応している組み込み命令は
どの程度コンパイラによる最適化の影響を受けるの?

基礎的な知識が圧倒的に足りていない件・・・orz

529 名前:,,・´∀`・,,)っ[昼はカレー] mailto:sage [2009/01/19(月) 12:44:00 ]
要するに128バイト分の命令(32命令)をこなす間に8サイクル以上
LSにロード・ストアしないタイミングを確保すればいいらしい。
完全にEven/Oddが同時実行されてる場合はロード・ストアが1バッファあたり8命令を越えるとアウト。
2命令同時発行できないサイクルがあったりすれば1バッファを使いきるサイクル数が17以上に延びるので、その分は延びる。
たとえばEven側20命令、ロード・ストア12命令の32命令でも、バッファのフィルに必要な8サイクルを確保できる。

530 名前:デフォルトの名無しさん mailto:sage [2009/01/19(月) 14:13:31 ]
>>529
Handbook によると
「SPU instruction prefetches are 128 bytes per cycle.」
らしいので、32命令中に1サイクル空きがあればいいはず。

531 名前:デフォルトの名無しさん mailto:sage [2009/01/19(月) 14:14:19 ]
>>528
結果さえ同一ならバカ正直に「SIMD版MT」を実装する必要がない



532 名前:デフォルトの名無しさん [2009/01/19(月) 14:17:58 ]
>>530
bitじゃなくてbyteかよ

533 名前:デフォルトの名無しさん mailto:sage [2009/01/19(月) 14:30:33 ]
そういえばDMAと命令フェッチが同じバスなんてことが書いてあるような

534 名前:デフォルトの名無しさん mailto:sage [2009/01/19(月) 15:24:33 ]
>>531ありがとうございます。>>209で言ってたようなことかな・・・
もういちど見直してみます


535 名前:デフォルトの名無しさん mailto:sage [2009/01/19(月) 15:45:38 ]
>>533
>>526 じゃなくて?

536 名前:デフォルトの名無しさん mailto:sage [2009/01/19(月) 16:12:20 ]
>>530,532
LS の読み書き単位が 128byte だからね、たしか。
ただ、読み込み自体は 1cycle で終わっても、SPU の pipeline は
結構深くて、15cycle くらい前に fetch されてないとダメなはず。
他にも ifetch 起動条件とか色々あるよ。どっかに資料あると
思うけど、リンクとか張らないでみんな自力で頑張ろうぜw

537 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/19(月) 18:04:15 ]
www2.vipper.org/vip1074688.png.html

上から下までこうなってないところ捜す方がしんどい

538 名前:デフォルトの名無しさん mailto:sage [2009/01/19(月) 18:47:38 ]
あ、当たり前では?

539 名前:デフォルトの名無しさん mailto:sage [2009/01/19(月) 19:50:30 ]
俺も参加したいけど、どうせなら1位2位を争いたい。
でも団子屋さんみたいな暇人じゃないから勝てるわけもないので高みの見物。

540 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/19(月) 19:51:04 ]
ひまじんとはしつれいな

541 名前:デフォルトの名無しさん mailto:sage [2009/01/19(月) 20:30:21 ]
>>531
それ考えてるんだけど思いつかないんだよな
アルゴリズム同じのまま使う命令の入れ替えと並び替えで15サイクルまでは来れたんだけど
しかも現状じゃ隙間は残ってるのに依存性で詰められないところがあってもったいない
ここにいる優勝候補さんたちは社会人部門だと信じてる



542 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/19(月) 21:46:33 ]
__builtin_expect()使っても意味ねー
つか遅くなる

543 名前:デフォルトの名無しさん mailto:sage [2009/01/19(月) 21:49:36 ]
!!!いままで使ってなかったんか!!!w

544 名前:デフォルトの名無しさん mailto:sage [2009/01/19(月) 21:50:14 ]
今さら?
__builtin_expectでぐぐりゃそんな事例出てくるだろ。

545 名前:v127251.ppp.asahi-net.or.jp mailto:sage [2009/01/19(月) 21:54:45 ]
だんごうぜー


546 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/19(月) 21:59:07 ]
ふゅーじゃーねいざん?

547 名前:227 ◆eZQcaIaFJs mailto:sage [2009/01/19(月) 22:00:15 ]
ループ内側の最適化は投げ出して、外側の整形作業に移るとしますか。
知らない間にリアルが2末マイルストーンとか言う無茶苦茶な事に
なってたんで、現実逃避も程々にしとかないとマジでヤバイかも。。。


548 名前:デフォルトの名無しさん [2009/01/19(月) 22:00:49 ]
なんで、こんなところに節穴がいるの?

549 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/19(月) 22:03:18 ]
俺の日記はリアルGateKeeperがよく読んでるけどね

550 名前:227 ◆eZQcaIaFJs mailto:sage [2009/01/19(月) 22:12:55 ]
今更になって>>389見て幻滅してきたorz メモリが無いと勝てる気がしない…。


551 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/19(月) 23:17:44 ]
15,000tick削減成功
いけるところまでやるか



552 名前:227 ◆eZQcaIaFJs mailto:sage [2009/01/20(火) 00:57:49 ]
とりあえず、>>389の一歩手前までたどり着いたのは良いんやけど、ここに
なって拡張アセンブリが使い物にならない(>>458)事がハンデになってくる
とは思わなかったorz

>>551
まだ3日ほど楽しめそうですよw


553 名前:227 ◆eZQcaIaFJs mailto:sage [2009/01/20(火) 01:35:27 ]
>>552
一歩手前じゃなかったっぽい。見れば見るほど>>389が神に見えてきたorz


554 名前:デフォルトの名無しさん mailto:sage [2009/01/20(火) 01:38:13 ]
>>517 は何だったの?w

555 名前:227 ◆eZQcaIaFJs mailto:sage [2009/01/20(火) 01:56:24 ]
>>554
99.91%の壁の高さを痛感しているだけですよ、たぶん。


556 名前:デフォルトの名無しさん mailto:sage [2009/01/20(火) 02:17:10 ]
あー、>>389 の前提がおいらとは違うのか。
>>551 を見て >>389 は最適化途中だっただけと見てたんだが。

557 名前:デフォルトの名無しさん mailto:sage [2009/01/20(火) 11:58:58 ]
素人だけど参加

命令書き換えとか、なかなか上手くいかないけど楽しいわコレw

558 名前:デフォルトの名無しさん mailto:sage [2009/01/20(火) 16:16:18 ]
>>557
命令自己書き換え(self modification)してんの?
仕様書に書いてあるけど、その場合は sync しなきゃ
だめだからあんま早くならない気がするなぁ…

559 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/20(火) 17:53:14 ]
【Oddの】命令数削減法思いついた

560 名前:デフォルトの名無しさん mailto:sage [2009/01/20(火) 19:24:19 ]
何命令くらいの所で頑張ってるんだろう?
自分はもうこれ以上削れる気がしないけど…

561 名前:202 mailto:sage [2009/01/20(火) 19:56:42 ]
だんごさんそのうち4M切りそうだなw



562 名前:202 mailto:sage [2009/01/20(火) 20:24:17 ]
いや、でも4.7Mの壁は今までの壁と比べても相当キツイな。
提出日まで頑張っても超えられない気がしてきた。

563 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/20(火) 20:45:21 ]
なんですか4.7Mの壁って

564 名前:202 mailto:sage [2009/01/20(火) 20:49:02 ]
>>563
余裕で切ってるってことかーーー!!!
マジで勝てる気がしねー。

565 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/20(火) 22:03:02 ]
逆に遅くなったorz

566 名前:デフォルトの名無しさん mailto:sage [2009/01/20(火) 22:08:50 ]
だんご優勝できなかったらブログ閉鎖の方向でよさそうなのかな?

567 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/20(火) 22:13:22 ]
なんでやねん
逆に優勝しちゃうといろいろまずいことならあるが

568 名前:デフォルトの名無しさん mailto:sage [2009/01/20(火) 22:23:08 ]
3Mの壁が・・・。イチからやり直すか・・・orz

569 名前:デフォルトの名無しさん mailto:sage [2009/01/20(火) 22:30:49 ]
16Gくらいメモリ使ったんですか?w

570 名前:202 mailto:sage [2009/01/20(火) 23:24:43 ]
>>568
3Mって、、、俺らと同じ基準なら化け物スコアだな。

571 名前:227 ◆eZQcaIaFJs mailto:sage [2009/01/20(火) 23:29:48 ]
>>557
でも今日は酔っぱらってて自己書き換えの実装出来ないんだなー。
明日時間有ったら挑戦してみる。




572 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/20(火) 23:34:44 ]
30Mの勘違いの予感

573 名前:227 ◆eZQcaIaFJs mailto:sage [2009/01/20(火) 23:59:18 ]
いつの間にか FAQ 更新されててワロタ

> デクリメンタのオーバーフローを利用することは可能ですか?
> 今回の出題の趣旨に反するので不可能とします。


574 名前:デフォルトの名無しさん mailto:sage [2009/01/21(水) 00:03:08 ]
不可能ではないと思うんだ。

575 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/21(水) 00:06:04 ]
本日の捏造

spu-gcc43 -std=gnu99 -O3 -g -c -o mt_mine.o mt_mine.c
spu-gcc43 -Wl,-Map,mt_kadai.map mt_kadai.o mt_mine.o mt19937ar.sep/mt19937ar.o -o mt_kadai
./mt_kadai
ORIGNAL: sum=3c927c56, 294422087 ticks
MINE: sum=3c927c56, 4694973 ticks
ORIGNAL: sum=2e987a4d, 424720276 ticks
MINE: sum=2e987a4d, 6772739 ticks
ORIGNAL: sum=ef1b6aef, 312518235 ticks
MINE: sum=ef1b6aef, 4983550 ticks
ORIGNAL: sum=eedd2516, 290441206 ticks
MINE: sum=eedd2516, 4631487 ticks
ORIGNAL: sum=f7e967a8, 14385949 ticks
MINE: sum=f7e967a8, 229457 ticks
ORIGNAL: sum=1f37a7db, 214501370 ticks
MINE: sum=1f37a7db, 3420537 ticks
ORIGNAL: sum=c7d41f36, 295356889 ticks
MINE: sum=c7d41f36, 4709875 ticks
ORIGNAL: sum=aa9d2e9f, 259910600 ticks
MINE: sum=aa9d2e9f, 4144655 ticks
ORIGNAL: sum=8abd398a, 251178167 ticks
MINE: sum=8abd398a, 4005396 ticks
ORIGNAL: sum=a374bd58, 6118425 ticks
MINE: sum=a374bd58, 97617 ticks

576 名前:227 ◆eZQcaIaFJs mailto:sage [2009/01/21(水) 00:19:26 ]
>>575
目標修正、4.6Morz


577 名前:202 mailto:sage [2009/01/21(水) 00:54:43 ]
ああくそ、やっと正しい答えが出た。
拡張インラインアセンブラ、かなり茨の道だわ。
レジスタ多いから、どのレジスタが期待値と違うのか判らん。

誰が悪いのか判らないアセンブリのデバッグしながら命令削るより、
C言語の上で一つでも多くのアイデアを実装した方が絶対効率的だ。

578 名前:202 mailto:sage [2009/01/21(水) 00:56:33 ]
>>575
まだ4Mは切ってないようでw
大きな差が無くて安心した。

579 名前:デフォルトの名無しさん mailto:sage [2009/01/21(水) 01:05:57 ]
今北。

課題は、MTの最適化ではなく、合計の計算の最適化なんだな。

後段の tempering は mt[] に影響を与えないので、tempering 後の
値を合計せずに、tempering 前の「とある値」を集計する。GF(2)の中で。
すると、tempering (相当の操作)は一回で済む。

<いまここ>

団子「スタートライン」ってこれのことだろ?

次に、「とある値」を集計するだけの目的であれば mt[] を「真面目に」
計算する必要はなくって、かなり端折れる。(仮に、端折って計算した
mt[] を pmt[]とする)

どの計算が端折れるか、いま計算しているところ。

<もうすぐここ>

最後に、num_rand % 624 の端数ぶんをどう計算するかで手詰まり気味。
pmt[] から mt[] を計算し直そうとすると、mt[] を最初から計算する
のとあまりコストが変わらない方法しか思いつかない orz

いっそ、mt19937ar.c の mt[] を LS から探してしまおうか。

まず、num_rand % 624 となっている mti を探して、みつかった mt[]
から pmt[] を検定する。

どうかな。


580 名前:デフォルトの名無しさん mailto:sage [2009/01/21(水) 01:07:43 ]
>>575
人間がレジスタを管理することなんて既に不可能と気づけよ。

581 名前:デフォルトの名無しさん mailto:sage [2009/01/21(水) 01:12:12 ]
>>579
あーぁ、GF(2) とか出してくるなよw
団子の「スタートライン」は全然そこじゃないって。
井戸の中で満足してる奴に餌与えちゃだめだってw



582 名前:デフォルトの名無しさん mailto:sage [2009/01/21(水) 01:16:35 ]
井戸の中w

583 名前:202 mailto:sage [2009/01/21(水) 01:21:54 ]
>>579
ルールブレイカー発動か?
tempering前に何かを集計して・・・ということができれば劇的に
速くなるという発想はあったんだが、多分ムリだろと思ってやってないよ。

学がないもんで、GFを今Wikipediaで調べて、やっぱり意味不明だった。

584 名前:202 mailto:sage [2009/01/21(水) 01:24:09 ]
>>580
Pythonでスクリプト組んで、アセンブラコードを半自動生成させてるから、
うまくいってるときは問題ないんだ。
一度計算結果が狂うと、どこが間違ってるのか全然判らなくなる。

585 名前:デフォルトの名無しさん mailto:sage [2009/01/21(水) 01:46:28 ]
>>202
Matsutomo et al.1994 にも、MK-tempering が GF(2) 行列の掛け算だ、
と書いてあるでしょ。

それから、MTが暗号乱数として脆弱なことは Matsumoto も認めることろ。
そこをつつかなくてどーするw

今すぐ ACM 逝って MT に批判的な論文嫁。


586 名前:579=585 mailto:sage [2009/01/21(水) 01:50:03 ]
とかいいつつ、端数の処理が解決できなかったら俺の負け。


587 名前:デフォルトの名無しさん mailto:sage [2009/01/21(水) 02:04:10 ]
>>579
団子は何もしらないってことにまだ気付いてない。。。

588 名前:デフォルトの名無しさん [2009/01/21(水) 02:07:03 ]
>>579
とりあえずそのままSIMD化しただけで放置してたんだが,
そうゆうの面白そうなんでその方向性で考えてみるわ

589 名前:デフォルトの名無しさん mailto:sage [2009/01/21(水) 02:25:40 ]
ここが井戸か

590 名前:デフォルトの名無しさん mailto:sage [2009/01/21(水) 03:40:48 ]
ttp://www.math.sci.hiroshima-u.ac.jp/~m-mat/TEACH/0407-2.pdf

591 名前:デフォルトの名無しさん mailto:sage [2009/01/21(水) 04:11:57 ]
>>590
ポイントはここですか?w > 「6.5.2 どこがフーリエ変換やねん」



592 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/21(水) 09:33:19 ]
ま た 勘 違 い の 【さ ん す う や】 か
算術師の花園へようこそ

593 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/21(水) 10:18:06 ]
>いっそ、mt19937ar.c の mt[] を LS から探してしまおうか。

このレベルのネタでいいなら、
num_randとseedの組を決めうちにして、switch(num_rand) { } で計算済みの結果返すようにしたら?
変更されるらしいけどwww
アホの言ってることは要するにそのレベル。
螺旋の飛んださんすうやさんは計算機で如何実装するかという論点が欠けてる。

余談までに松本教授&斎藤氏のSFMTがオリジナルのMTと比べて如何違うかって、最大の違いは
Temperingの結果を都度(32bit×4要素分単位で)mt[]にフィードバックしてること。
それでうまい具合にビットレベルで数値がばらけてくれる。
逆にそれで依存関係が起きて128ビットを越えるSIMDでは効率的に実行できないわけだが。


>>580
ばかだな。レジスタ管理がどうとかなんて言ってないだろ。
ここまで全部コンパイラにやらせてるし


594 名前:557 mailto:sage [2009/01/21(水) 10:29:40 ]
>>558
え、そうなの?
仕様書あんまし読んでないからわかんないけど
俺がやってるのは例えばodd命令をeven命令に置き換えたりして
同時発行を促すとかそういうのなのだけど・・・

595 名前:,,・´∀`・,,)っ[タミフル] mailto:sage [2009/01/21(水) 10:45:30 ]
oddをevenかよ。俺様はそれをやる段階じゃないな。


てか、件のOdd側の命令数削減法、実際やろうとするとレイテンシチェインが伸びて
アンロールするレジスタ足りなくなる罠。本末転倒。








インフルエンザですが何か?

596 名前:,,・´∀`・,,)っ[タミフル] mailto:sage [2009/01/21(水) 10:55:31 ]
>>578
俺が現在進行中のスコア貼ったことは一度も無い。
いまのところ3日前くらいのスコアばっかし貼ってる。

597 名前:デフォルトの名無しさん mailto:sage [2009/01/21(水) 12:02:37 ]
>>575が3日前だとして
>>551の時点で15,000tick削減成功

だから少なくとも今は4.67M台未満ってことかな?

598 名前:202 mailto:sage [2009/01/21(水) 12:11:40 ]
やっぱりやる気でないから、数学的手法への挑戦はやめとく。
レジスタ上に一瞬とはいえ目的の乱数が出現する俺や団子さんに比べて、
数学的手法だと一瞬たりとも目的の乱数が出現しないから、
※似乱数列は、メルセンヌ・ツイスタの実装 mt19937ar.c と同じ乱数列を生成してください。
の条件に違反しているという理由で reject される恐れもあるしね。

コード整理して、レポート書いて、提出しちゃおう。

599 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/21(水) 12:18:46 ]
レジスタ上に一瞬とはいえ目的の乱数が出現する俺や団子さんに比べて、

え?アレって出てるって言うのかな?
俺はデータ構造的にあやしいことやってるけど。

600 名前:デフォルトの名無しさん mailto:sage [2009/01/21(水) 12:20:02 ]
>>593
結局自分で管理しないでコンパイラ任せじゃないか。
レジスタがいっぱいあるからといって自分で全て管理できるはずはないけど。

601 名前:202 mailto:sage [2009/01/21(水) 12:24:23 ]
ひょっとしてまじめに乱数作ってチェックサム取ってるの俺だけか??
俺が団子さんに敵わないのもそのせい???



602 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/21(水) 12:31:58 ]
>>600
だから何なんだ?管理できるとかできないとかお前は一体何を言ってるんだ?
俺にはさっぱりわからない。

603 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/21(水) 12:47:36 ]
>>601
ちなみに、彼の珍理論で演算時間の短縮を図るには超次元立方体構造のレジスタや演算ユニットが必要だったりするから気にするなwwww

604 名前:デフォルトの名無しさん mailto:sage [2009/01/21(水) 13:08:44 ]
団子が天才。はい。だからもうだまれ

605 名前:デフォルトの名無しさん mailto:sage [2009/01/21(水) 13:43:41 ]
>>604
誰だおまえ?スピード狂オタクの分際で調子に乗るな。

606 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/21(水) 14:01:25 ]
MT配列は教科書通りの結果になるように都度更新してるけどtemperingをまっとうな方法でやってる自信はないな。

607 名前:デフォルトの名無しさん mailto:sage [2009/01/21(水) 14:48:01 ]
>>603
おいおい、GF(2) 系の演算の高速化や簡素化はコンピュータの得意分野だぞ?
今時の暗号なら当たり前の事だろ。実装した事ないのか?

608 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/21(水) 14:49:59 ]
だったら実装してみろよ
机上の空論はおなかいっぱい

609 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/21(水) 14:56:08 ]
さんすうや君は端数を処理するのにチートやらないと無理だって言ってるんだろ?
ならどのみち芽がない方法だ。

610 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/21(水) 15:07:30 ]
> GF(2) 系の演算の高速化や簡素化は

やってるよ。
MT[]のデータ状態に矛盾が起きない範囲でな。それが出来ないなら今回のコンテストは諦めろ。

611 名前:デフォルトの名無しさん mailto:sage [2009/01/21(水) 15:21:50 ]
青筋立てないで落ち着け。
どこのスレでも痛すぎる。正しい事を言っているかどうかじゃなくて。
答えて欲しい質問からは逃げるのに叩けるところはどうでもいいところまでしゃしゃり出てくる。



612 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/21(水) 15:35:50 ]
なんだ答えて欲しい質問って?

613 名前:デフォルトの名無しさん mailto:sage [2009/01/21(水) 15:35:58 ]
ゲハ厨学歴厨に何言っても手遅れ

614 名前:202 mailto:sage [2009/01/21(水) 15:38:49 ]
話題変わるけど、spu-gdbってどうやって使うの?
elfspe使ってspe用のバイナリを直接実行できるんだけど、
spu-gdb mt_kadai とかやってもデバッグできない。

今までデバッグは全部コードインスペクションと、mt[]のダンプ取って
バグの箇所を推測するの2種類だけで全部やってた。

615 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/21(水) 15:40:07 ]
負け犬の遠吠え

616 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/21(水) 15:43:17 ]
>>614
SPUの実行イメージをPPEから読み出すローダーでも作れば良いのでは?

cell.fixstars.com/ps3linux/index.php/Libspeプログラムのデバッグ

617 名前:202 mailto:sage [2009/01/21(水) 15:43:37 ]
>>612
※似乱数列は、メルセンヌ・ツイスタの実装 mt19937ar.c と同じ乱数列を生成してください。
の意味について、
1. プログラム中でmt[]の内容を計算していたら良いのか、
2. 全乱数wordについてtempering後の値も計算していないといけないのか、
3. それともチェックサムだけ合ってればなんでもアリなのか、
を質問してみて、質問して回答が2だとヤバイ?

618 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/21(水) 15:46:17 ]
俺に聞くな。

ちなみに俺はgenrand_mineを繰り返し呼んでも安全なように設計してる。
ぶっちゃけ外側の最適化はサボってる

619 名前:デフォルトの名無しさん mailto:sage [2009/01/21(水) 19:26:33 ]
>>612
>>381 は本当? >>389 == 最適化中は本当? >>575 の捏造は本当?w

620 名前:デフォルトの名無しさん mailto:sage [2009/01/21(水) 19:29:02 ]
鼻高々だな団子。

621 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/21(水) 19:41:11 ]
手元にある最新のコードよりわざと悪い結果を貼ってるのは本当。

晒す実行結果は前のバージョンだったり、わざとデチューンしたり、色々。



622 名前:デフォルトの名無しさん mailto:sage [2009/01/21(水) 19:47:57 ]
なんか参加賞あるし、暇だからやってみようかな

プログラム全然書けないけど
このスレ見ながら楽しくやってみよう

623 名前:557 mailto:sage [2009/01/21(水) 20:34:12 ]
>>622
自分もそんな感じ。
勉強と思ってのんびりやろうぜ






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

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

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