ユー！Cellプログラミングしちゃいなよ

ユー！Cellプログラミ ..

321:デフォルトの名無しさん
07/02/23 23:40:23
将棋プログラムはそれはそれで面白いんだけどさ
今の流れはあまりに Cell と関係ないような

一般的な将棋プログラムの話ならこっちだと思う

おまいら最強の将棋プログラムしてみろよ part5
ｽﾚﾘﾝｸ(tech板)

322:・∀・）っ-○◎● ◆DanGorION6
07/02/23 23:46:12
>>320
だから、成れば動きが増えても減らない駒で自ら不成として可能性を狭めても
自分のクビをしめるだけで相手に弊害はない。むしろ手が絞り込めちゃう。
「と金」をとろうが「歩」をとろうが持ち駒になるのは歩だしね。

俺が知る限りではコンピュータ将棋で不成を選択できるのは３種類だけだよ。

>>321には胴衣

323:デフォルトの名無しさん
07/02/24 00:44:16
AHO 相手の手の合法性のチェックはどうやってするんだ？

324:・∀・）っ-○◎● ◆DanGorION6
07/02/24 02:25:40
動きそのものは桂馬・飛車・角よりもナイト・クィーンのほうが自由度高いしね
将棋も持ち駒うてなかったらおそらく解法はチェス同等かそれより簡単になるとオモ

325:デフォルトの名無しさん
07/02/24 02:29:41
>>324
それは将棋というゲームのルールですかという疑問

つか、将棋の話はストップ続きは>>321で。

326:デフォルトの名無しさん
07/02/24 02:55:21
馬鹿にかまってスレを無駄に消費するより
NG登録しましょう

327:デフォルトの名無しさん
07/02/25 01:59:16
表か裏かの情報なんてせいぜい1ビットのフラグで表せるし、その程度の
情報が増えるくらいのことを状態爆発とは言わない

どんだけ効率の悪いコード書いてるんだよ

328:デフォルトの名無しさん
07/02/25 02:04:28
いやフラグとか記述方法とかそういう問題ではないんだけど、ひょっとしてﾌﾟﾛｸﾞﾗﾑとか書いた事ない？

329:デフォルトの名無しさん
07/02/25 02:10:33
いやそれはお前だろ
たとえば歩を成らずに進める可能性を考慮してどれだけ状態が増えるんだよ
前にしか進まないだろ

330:デフォルトの名無しさん
07/02/25 02:44:09
マジで逝ってるのか…

331:デフォルトの名無しさん
07/02/25 02:47:23
それともお前の脳内ルール上の歩は斜め後ろにでも移動できるのか

332:デフォルトの名無しさん
07/02/25 02:48:49
だからそういう問題じゃないって…

333:デフォルトの名無しさん
07/02/25 02:52:26
たとえばRPGのキャラクタは経験値という状態を表すだけで16777216種類のデータが必要か？
それがわからないならプログラム向いてないよ。

334:デフォルトの名無しさん
07/02/25 02:57:48
だからﾃﾞｰﾀ量の問題じゃないって…ｱﾙｺﾞﾘｽﾞﾑ計算量が見積もれない方がよっぽどﾔﾊﾞｲと思われ

335:デフォルトの名無しさん
07/02/25 02:59:41
327はこの手のプログラムを書いたことが無いんだよ。

336:デフォルトの名無しさん
07/02/25 03:04:20
アルゴリズム計算量が、歩を成らずに進めた場合を想定すると、しない場合に比べて
どれだけ上がるのか説明してみてくれ

337:デフォルトの名無しさん
07/02/25 03:17:09
所詮口だけか（笑）

338:デフォルトの名無しさん
07/02/25 03:25:06
自分がｱﾎなこと逝ってる所為だとは思わないのか
FSMを構成してみればわかるだろが

339:デフォルトの名無しさん
07/02/25 03:34:19
真性ｱﾌｫがいると聞いて飛んできました。

340:デフォルトの名無しさん
07/02/25 03:40:55
歩ってかならず成らないとダメじゃなかったっけ？

341:デフォルトの名無しさん
07/02/25 03:48:35
ﾀﾞﾒじゃない
ただ歩は成っておいた方が状態数(選択肢)が増やせるし、成った事によるpruningも発生しない

342:デフォルトの名無しさん
07/02/25 03:55:08
わかってるじゃないか。
成らない可能性を考慮しようがするまいが大して状態数は増えないんだろ結局。

343:デフォルトの名無しさん
07/02/25 04:03:23
個々の駒の動き自体は元々チェスより少ないくらいだ
持ち駒という概念が状態数を爆発させる最大の要因であって
成って損のない駒が成るか成らないかなんてことに拘る方がアホ

344:デフォルトの名無しさん
07/02/25 04:10:06
なんか成りあがれるのが歩だけだと思ってるのか、このｱﾎは？

345:デフォルトの名無しさん
07/02/25 04:17:58
成らないほうがいいこともある駒は銀桂香くらいだが？
駒の復活による計算量の爆発に比べれば遙かに小さい

見積もりも出来てないのはお前だろアホ

346:デフォルトの名無しさん
07/02/25 04:23:41
>駒の復活による計算量の爆発に比べれば遙かに小さい

だから何？

347:デフォルトの名無しさん
07/02/25 04:24:50
チェスのQueenよりも表裏の2状態がある飛車や角の方が
とれる動き方の状態が多いとが本気で思ってそうだなこの馬鹿

348:デフォルトの名無しさん
07/02/25 04:29:35
飛角歩を不成とするようなのは最初から定石パターンからは除外される
素人はこれ以上反論しても無駄だからオムツ替えて寝ろ

349:デフォルトの名無しさん
07/02/25 04:45:06
駒の動かし方しか考えてなさそうなんだけど、もういいや寝るよ

350:デフォルトの名無しさん
07/02/25 04:56:38
GKの内ゲバスレはここですか？

将棋の探索アルゴリズムを本当に複雑化させてるのは持ち駒を打つとき。
持ち駒というやつは盤上の空きのどこにでも打てる（歩・香・桂馬には若干の制限がある）
盤上の駒を動かすより遙かにオーダに大きい。
成ると駒の動き方が変わることなんて問題としちゃ小さい小さい

351:デフォルトの名無しさん
07/02/25 05:14:26
チェスは駒がどんどん減っていくから次の手はどんどん無くなっていくし
オセロも置ける場所が減っていく。白黒合わせて60手までで必ず終わる。

将棋は局面が進んでも盤上に取った駒を復活させることができるからなかなか収束しない。
だから将棋のアルゴリズムは、定石パターンと照らし合わせて絞り込むことが重要になる。

愚直に総当たり検索なんてやってたらいくらリソースあっても足りない。
削れる枝は大胆に削るのが鉄則。

表か裏かでいちいち状態数云々考える時点でアルゴリズムのセンスなし。

352:デフォルトの名無しさん
07/02/25 05:17:18
そんなこと以前にSPE+LSじゃ探索なんて出来ねーよ。
既存のソースは使い物にならないし
かといってPS3向けに最適化する暇人もいないだろう。

353:デフォルトの名無しさん
07/02/25 05:39:08
結論：みんな口だけ

354:デフォルトの名無しさん
07/02/25 05:51:29
PPE単体でもCele600MHzくらいのパフォーマンスは有りそうだし
少ないとは言っても200MBくらいのメモリは使えるんだし
PCの数年前の将棋ソフトくらいに匹敵する強さにはなるだろう。

355:デフォルトの名無しさん
07/02/25 11:35:29
>>352
まぁ考え方は根本的に変えなけりゃダメだろうな。
たとえば局面評価にしても、ここがこうだから何点などという手続き的な
やり方じゃなく、ひとつの評価関数(どんな複雑なものになるかわからんが)に
落とし込んで、整数条件を緩和して上界を求める、とか。

356:デフォルトの名無しさん
07/02/25 14:07:48
そこでモンテカルロ将棋ですよ

357:デフォルトの名無しさん
07/02/25 19:54:50
やっぱりここは最良優先探索だろう
PPEでキューを管理して
SPEで次のノード探索タスクを並列して実行すれば
幅も深さも適当な探索ができる気がする

358:デフォルトの名無しさん
07/02/26 00:44:12
将棋も将棋のソフトも全然わかんないんだけど、演算速度が例えば100倍早いと
つよくなるものなの？処理に使える時間が重要？覚えておくパターン数が重要？

359:デフォルトの名無しさん
07/02/26 02:55:03
思考時間が無限にかかるCPUは最弱といわれるだろうから
当然短時間でより多くの処理ができる方が強いということになるだろうな。

まあメモリ640kbのZ80マシンでも将棋ソフトは作れたんだしなんかは作れるだろ。

360:デフォルトの名無しさん
07/02/26 04:26:30
ちょっとまて
普通の将棋には制限時間というものがあるお

361:デフォルトの名無しさん
07/02/26 04:57:44
そうなんだ。ググレカスです。わたしは。

362:デフォルトの名無しさん
07/02/26 20:56:43
普通の将棋ってのが公式のなんかルールですかね。
時間制限ありでやったことはほとんどないんでわからんですよ。

363:デフォルトの名無しさん
07/02/26 23:54:22
第17回世界コンピュータ将棋選手権 URLﾘﾝｸ(www.computer-shogi.org)
の場合「持ち時間は25分とする」とルールに書いてある

364:デフォルトの名無しさん
07/02/27 00:58:27
世界コンピュータ将棋選手権に PS3 で参加！とか格好いいな

365:デフォルトの名無しさん
07/02/27 04:35:48
それで優勝したらもう大変

366:デフォルトの名無しさん
07/02/27 04:49:23
次スレは将棋板でおｋ？

367:デフォルトの名無しさん
07/02/27 05:45:45
CellがintelやらAMDやらのCPUに将棋で勝ったら、もう失敗作だとゲハで
叩かれないですむだろうか（涙）

368:デフォルトの名無しさん
07/02/27 09:18:14
ゲハがいくら頑張ってもここの連中には効かないというか
そんなところに当たり判定は無いというか。

369:デフォルトの名無しさん
07/02/27 10:28:54
頑張って俺様スパコンしてるのだろうから、あまり可哀想なこと言うなよ。

370:デフォルトの名無しさん
07/02/28 02:29:37
同じプログラム使えばより強くなるんでは。８コアだし。

371:デフォルトの名無しさん
07/02/28 03:40:05
SPEはそれなりに考えて組まないとパフォーマンスを発揮できないが、Core2辺りだと
Intelコンパイラ使って何も考えなくてもパフォーマンスが得られることもあるからなぁ。

372:デフォルトの名無しさん
07/02/28 08:30:47
？

373:デフォルトの名無しさん
07/02/28 11:45:30
共有メモリじゃないからマルチスレッドと言ってもコードは大違い＜CELL

374:デフォルトの名無しさん
07/02/28 16:59:30
マルチスレッドは普通メモリ共有してるものだけを指すんじゃね。
奇天烈なCellプログラミングは最早マルチプロセスだと思う。

375:デフォルトの名無しさん
07/03/01 01:11:17
すげーガイめっけ
URLﾘﾝｸ(moss.csc.ncsu.edu)

376:ps3cluster
07/03/01 01:38:35
さて、ps3クラスタをのんびり～つくリはじめてみようと思います。
目標はクラスタで大規模数値計算。
計算はニューラルネット。単体で動かす分は大体できた。

377:ps3cluster
07/03/01 01:46:15
ニューラルネットを作るのもいろいろ、紆余曲折がありました。
一番やっかいだったのはコア間の同期と通信。
送ったはずなのにたま～にとどいてなくて、悩んで数日。
メモリの一貫性(というのか？)を身をもって体験しました…。

378:ps3cluster
07/03/01 01:56:18
他にもいろいろ面白いことが。
最適化の作業ってはじめての経験でしたが、ループアンロールというのを
やってみたところ、ある部分ではもんすごいはやく（大体８倍)なって、びっくり。

あとどうしてもスカラで分岐でしかかけないところがあって、やっぱり遅くて
ここも将来何とかできないかなあとは思ってます。

379:ps3cluster
07/03/01 01:58:55
さてPS3クラスタ。
まだ2台目すぐには買えないので、ゆくっりとプランをねります。
とりあえずMPIで通信、gigabit eatherでつなぐと。
クラスタ作るのも初めてなんですが、gigabit eatherのMPI通信のレイテンシは
普通100μs位らしく、まあなんとかなりそう。
でもあと半分くらいになってくれたらうれしいなあ。ちょっと手を入れると
早くなるそうだけど、ど素人なのでいつかできたらね。

380:ps3cluster
07/03/01 02:05:12
そこでちょっと気づいたが、MPIやるとしたら、基本的にPPE間で通信して、
それをSPEにさらに送ることになるだろうということ。
ということは、通信する必要があるデータは、PPEに集めてそっから別PS3に
おくらにゃいけません。
今はPPEは全然使ってないんで、書き換えねばならぬ。失敗した。

381:ps3cluster
07/03/01 02:12:20
そこの書き換えと、MPI用PPEコードをちょっとづつ勉強していこう！
あとPS3のおき場所と電源を考えねば…。安く売ってるとこも探そうっと。

382:・∀・）っ-○◎●
07/03/01 02:13:56
中古の良品が45000円切ってるよ

383:デフォルトの名無しさん
07/03/01 04:53:11
>>381
PPEにお仕事ができて丁度いいじゃん。普通に書こうとするとPPEに仕事させないのが速いから
どうしてもPPEが遊びがちになるから。

384:デフォルトの名無しさん
07/03/01 05:04:37
>>381
HP公開ﾏﾀﾞｧｰ？

385:ps3cluster
07/03/01 23:48:22
>>382
当初に比べると安くなったなあ。あと65nm版がでることを願っているが、半年はかかるかなあ。
>>383
PPEはSPEのMFC的に通信で単独に動けるから、クラスタではうまくはまりそう。
>>381
HPないよ。

386:ps3cluster
07/03/01 23:59:49
うお、あげてしまった。

計算とレイテンシについてかんがえて見た。
大雑把にみて、PPE間の通信が例えば100μsの場合、SPEでデータ転送が必要になる間隔が100μsなら、
PPEが転送してる間にSPEに計算させることで、通信のレイテンシを隠蔽できる。
ほんとは、通信が待ってからじゃないと計算できないはずだけど、ニューラルネットの場合
そこが融通がききます。

387:ps3cluster
07/03/02 00:06:34
ps3一台のときに、同じレイテンシの隠蔽をSPE間の通信でやろうとしたら、
SPE間の通信速度があまりに速くて、隠蔽するまでもなく通信が終わってから計算しても
十分早いという結果になった(SPE間の通信のレイテンシは2,30ns程度)。

388:ps3cluster
07/03/02 00:19:47
現状でSPEの通信が必要になる間隔は60μsなので、ちょっと足引っ張られそう。
SPEにもっと重い計算をさせ、通信間隔が伸びるようにすれば一応、解決になる。
実際にMPIでどれだけレイテンシが発生するかまだわからないので、とにかくつくって
はかってみてから、調整しよう！

389:デフォルトの名無しさん
07/03/03 17:59:57
ガンバレ。期待している。

390:・∀・）っ-○◎●
07/03/03 19:40:42
YDL糞重いってレベルじゃねーぞｗｗｗｗｗ

391:・∀・）っ-○◎●
07/03/03 23:23:24
John the Ripperそのまんま動くね。当たり前だが。
まだPPEだけだけど。

2スレッド動かさないとピークでないっぽいので、MPI対応パッチ当ててみるか。

392:デフォルトの名無しさん
07/03/04 01:04:27
SPU使ってみたんだが、SIMDに向かない処理をどう高速化するかが課題だな
ビットストリームで切れ目が無いものをビット単位に処理するとか。

393:デフォルトの名無しさん
07/03/04 09:59:50
>SPU使ってみたんだが、SIMDに向かない処理をどう高速化するかが課題だな
んなこたない
Cellに向かない処理はCellでやらなければいいだけの話
なんでもかんでもCellで出来ないかとか妄想するから
ﾍｯﾎﾟｺCPUの烙印を押されてしまうんだと気がついた今日この頃

394:デフォルトの名無しさん
07/03/04 10:19:37
>>Cellに向かない処理はCellでやらなければいいだけの話
なんかそれも違う気がする
得意じゃないのであって、出来ないわけじゃない
ペナルティがあったってやらなきゃいけない事はやらなきゃ。
（アクセラレーターがあるわけじゃあるまいし

395:デフォルトの名無しさん
07/03/04 11:06:51
言い方が悪かったか。
ペナルティはあるが、複数のSPUで任せたほうが早い場合、ネックになる部分を
どうするかでさらに高速になるかという話ね。
時間がかかっているところに重点的に手を入れるのは常套手段だし。
PPUでやろうと思ったが、SPUに処理を投げているだけなのに意外とあき時間が無いんだよね。
現時点ではデータ分割で１００個に分割したとして、５個のSPUに２０個筒一気に投げると
先に終わったSPUの遊び時間が長くて無駄。１個筒投げる方がいい。
最初に半分SPUに投げて、PPUで１個やって、残りを終わったSPUに１個筒なげるとやっても、
結果としては早くならなかった。

396:デフォルトの名無しさん
07/03/04 11:48:25
>>395
何か根本的にずれてるよ、
そんな歪な最適化してどうする。

397:デフォルトの名無しさん
07/03/04 12:32:08
>>395
> ５個のSPUに２０個筒一気に投げると
> 先に終わったSPUの遊び時間が長くて無駄

分割した各データの処理にかかる時間がバラバラってことか。
とりあず、その文章だけだと何が悪いのかこちらに伝わらないので、
まぁ、とりあえず同じデータに対して PPU でやったときにかかる時間と、
SPU に投げて処理させて帰ってくるまでの時間を計測して、
何がボトルネックなのかを解析した方がいいと思われ。

SPU は DMA 転送に掛かる時間と SPU 上の計算時間を別にプロファイル
とるといいよ。

398:デフォルトの名無しさん
07/03/04 20:20:39
プロファイルは片っ端から取ってるけどね、
SPU内部に限っていえば、DMA転送やメールボックスなどといったシステム側？
の処理は１%ぐらいの割合かな。SIMD化が難しいところが半分以上の時間を食っているので
その辺をどうするか次第かなと。

通常のスカラー演算と条件分岐の組み合わせの多さが問題なのかなと。
分岐予測コードも入れてみたが入れたほうが遅くなった。

PPU側からはメールボックス経由でSPUをキックしているが、RunCntlチャンネル
で実行自体を制御したほうがいいのか、アトミックDMAでメモリ監視がいいのか
まだまだテストすることは多い。

>>395
kwsk

399:デフォルトの名無しさん
07/03/04 21:10:12
日経エレクトロニクス 2006年12月4日号に東芝とフィックススターズの人が
Cellのプログラミングについて9ページほど書いているのは既出?

SPE内部では条件分岐は算術処理に置き換えるべきなんだそうな
(分岐予測が外れると18サイクルのオーバーヘッド)
あとはTimingTool(プロファイル計測)を解析してパイプライン・ストールをなくしたり
2命令を同時発行する頻度が高くなるように命令を並び替えたりすること。

PPE側の処理が間に合わないのはデータをキャッシュして使い回していた
(サンプルプログラムは7万ポリゴンのレイ・トレーシング)

400:デフォルトの名無しさん
07/03/04 22:55:09
timingツールで解析結果は眺めたけど、特に手を入れるところはなさそう。
この辺はアンロールしておけばコンパイラがある程度はやってくれるらしい。

算術処理で置き換えるのは分岐内が簡単な計算の場合で分岐失敗コスト以上の
処理が必要な分岐はやっぱり分岐のほうがいい。分岐の除去はGPUで経験済み。
ストールもほぼおきていないが、順次データを計算して使っていく個所では
仕方ない個所も多いかなと。

例えばビットストリームからデコードするとき最大１６ビットで最大１６段階の分岐は
８ビットテーブル３つで最大３回の分岐に減らしてはあるが、これを１６ビットテーブル化すると
128KiB使用するのでとても作れない。

このスレのリンク先を読んで基本的な知識を身に付けてる感じです。
日経エレクトロニクスは読んでないので、ちょっと探してみます。
バックナンバーは図書館かなぁ

401:デフォルトの名無しさん
07/03/05 14:35:39
>このスレのリンク先を読んで基本的な知識を身に付けてる感じです。
嘘でもいいからこのスレを読んで、と言ってやれよ

402:・∀・）っ-○◎●
07/03/06 00:35:22
正直メモリ空間独立がここまで厳しいとは思わなかった。
Xbox 360で動くLinuxとかのほうが、あったら幾分か楽だろーね
モニタにも困ること無いし。

403:デフォルトの名無しさん
07/03/06 02:30:31
最初から躍起になってLSで納めようとしない方がいいよ。
まずはコードサイズ抑えて、データは全部DMA経由でも動きゃいいって。

最適化なんてボトルネックが分れば自然と出来るもの。

404:デフォルトの名無しさん
07/03/06 03:16:30
>>402
だが、このストイックなまでの縛りがいい。
趣味でいじってる分には。

405:デフォルトの名無しさん
07/03/06 06:40:26
>>401
ここで応用を（略

URLﾘﾝｸ(cag.csail.mit.edu)
とか現在見てます。

406:デフォルトの名無しさん
07/03/06 12:16:32
ゲーム産業開発者のためのスキルアップ講座
URLﾘﾝｸ(www3.stream.co.jp)
URLﾘﾝｸ(www3.stream.co.jp)

これの、特に後者を読むべし。チューニングには必見。

407:・∀・）っ-○◎●
07/03/06 23:02:22
そろそろRSXのシェーダ使わせろと（ｒｙ

408:デフォルトの名無しさん
07/03/07 00:08:26
ここはCellプログラミングスレ

409:デフォルトの名無しさん
07/03/07 00:41:51
<backOfChirashi>
X86のプログラムをPPEに移植してみた。
入力値はバイナリデータを転送して実行……
うぁはは、エンディアンが違ってたぜ。
速度的には、PPEだけじゃ話にならないね。
</backOfChirashi>

410:・∀・）っ-○◎●
07/03/07 01:04:48
PPEの性能自体はG4以下なんだよな

411:デフォルトの名無しさん
07/03/07 01:11:17
>>410
実際にゃSPEの管理までやっとるからな働きもんだｚ

412:デフォルトの名無しさん
07/03/07 01:12:25
>>406
これ聞いていると SPURS を公開してほしくなるな。
libspe で書いてると、他の SPU モジュールと協調できないのが悲しい。

413:デフォルトの名無しさん
07/03/07 01:47:58
公演聞いてて思ったけど、LameとかH.264はSPURSで実装すべきだよな。

414:デフォルトの名無しさん
07/03/07 05:51:42
IBMのひとは声に聞き覚えがあるな。Sonyの人のはSPURSの説明だし、
IBMのブレードサーバやボード、東芝のリファレンスキット、
PS3開発機とPS3LinuxでSPE管理ライブラリはそれぞれ違うだろうし、なんとも。
それでも、説明を見ていて、処理割り振りの新しい方法を考えついたので試してみるかな。

415:デフォルトの名無しさん
07/03/07 09:57:58
>>409
あれ？エンディアンは両方対応じゃなかったっけ？
後藤のｸﾀﾀﾝとのインタビューでそんなの見た記憶があるんだけど。

416:デフォルトの名無しさん
07/03/07 11:14:01
今CBEハンドブック見たけどBigEndianだと書いてあった。
ついでにビットは上から数えると書いてあったのも見つけた。

417:デフォルトの名無しさん
07/03/07 12:22:09
そうか、うろ覚えで発言するものじゃないな。
それだけだと何だから、ググってみたらこんなの出てきた。
URLﾘﾝｸ(pc.watch.impress.co.jp)

418:416
07/03/07 12:48:12
お、あったあった。こいつのことだな。
＞Load Double Word Byte Reverse Indexed X-form.

419:デフォルトの名無しさん
07/03/08 06:46:48
>>406
早起きしたので見てみた。
要するにSPURS使わない開発は無いな。

420:デフォルトの名無しさん
07/03/08 07:32:14
エンディアン変換ってAltiVecのvec_permとかじゃだめなのかな？
SPUにも同じ命令あるし。

421:デフォルトの名無しさん
07/03/08 11:15:34
SPURS公開されないのかなぁ？
あの公演聞くかぎりCellプログラミングでは必須のようだけど。

422:デフォルトの名無しさん
07/03/08 21:09:04
今日読んでた資料によると32bitの積はコストが高いらしい。
Cで書くとかってに格上げされて32bitの積になるんだろうか？