128bitあたり、15サイクルのスループットで済むと仮定して、オーバーヘッド抜きのスループットは5.47M切るくらい？でいいのかな？


えーと、絶望させちゃっていいかな？

【とっくに切ってるよ】
逆にどこに限界があるのかわからなくなってきたよ。

だんごに勝つにはtemperingの命令数減らすことを本気で考えたほうが良い。
そこから道が開けると思う。
アンロールしてタイミング詰めるのはそれからでも遅くない。

>>301
底知れねーな。でも大丈夫、その程度で絶望しないよ。
5.5Mを切る戦いに参戦する敵を増やしたくなかったから、>>297では>>293の数値をもとに話してた。
まだgccの吐くコードに翻弄されてるけど、5.5の壁の先の世界があることは理解している。

・・・でも、俺より先に>>227がだんごさんに追いつきそうなんだよな・・・
昨日一日物件探しまくって、良い物件見つけたと思ったら今朝「もう申し込まれてました」と連絡がorz
早く休日を丸一日使ってだんごさんと同じ世界に行きたい。

>>302
敵増やしたくないから具体的な話はしたく無いんだけどさ。
俺もだんごさんも>>227さんも、とっくにそのレベルで出来る事はやってる。
その程度では勝てないよ。

で、一位がこのスレからでるのは確定状態か

団子3兄弟

スレで情報をホイホイ書き込むような人がトップとれるんだろうか…

具体的な方法論は誰も公開してないんだぜ。
5M台叩き出してる人はアルゴリズムレベルでは殆ど同じコードになってると思う。必然的に。

あとは0.1パーセント単位のチューンってことになるわけだが
最後まで粘ったもん勝ちになりそうだな。

ってかさぁ、15cycle とかホントに出来んの？
ってか、みんなマジでこんなとこに書いてんの？w

とりあえず、良くも悪くもこのスレに書き込まれたことで、ここら辺の性能が
スタンダードになってしまったな。

まだ2か月近くあるしね。

こうならないと面白くないだろ？

ORIGNAL: sum=3c927c56, 294426736 ticks
MINE: sum=3c927c56, 5470853 ticks
ORIGNAL: sum=2e987a4d, 424726988 ticks
MINE: sum=2e987a4d, 7891991 ticks
ORIGNAL: sum=ef1b6aef, 312523179 ticks
MINE: sum=ef1b6aef, 5807115 ticks
ORIGNAL: sum=eedd2516, 290445788 ticks
MINE: sum=eedd2516, 5396877 ticks
ORIGNAL: sum=f7e967a8, 14386174 ticks
MINE: sum=f7e967a8, 267359 ticks
ORIGNAL: sum=1f37a7db, 214504754 ticks
MINE: sum=1f37a7db, 3985803 ticks
ORIGNAL: sum=c7d41f36, 295361550 ticks
MINE: sum=c7d41f36, 5488220 ticks
ORIGNAL: sum=aa9d2e9f, 259914712 ticks
MINE: sum=aa9d2e9f, 4829583 ticks
ORIGNAL: sum=8abd398a, 251182134 ticks
MINE: sum=8abd398a, 4667315 ticks
ORIGNAL: sum=a374bd58, 6118517 ticks
MINE: sum=a374bd58, 113731 ticks

このスコアをここに晒せるって意味を理解してくれ。

ちょっとそのソース晒してくれる？
嘘くさいから。

晒せるかボケ

あれからパイプラインの空きを半分くらいまで詰められたけど、
コンパイラが糞でどうにもならない状態。

.L9: ; メインループの先頭
lqr $81,mt+X
lqr $84,mt+X
lqr $53,mt+X
lqr $41,mt+X
lqr $47,mt+X
lqr $48,mt+X
lqr $59,mt+X
lqr $68,mt+X
lqr $24,mt+X
lqr $71,mt+X
lqr $113,mt+X
lqr $42,mt+X
lqr $43,mt+X
lqr $45,mt+X
lqr $46,mt+X
lqr $58,mt+X
lqr $55,mt+X
lqr $93,mt+X
lqr $104,mt+X
shufb $106,$73,$81,$127

>>312
数日前のスコアですか？

>>313
ちょｗｗｗそれはやりすぎだろｗ
>>312がスタンダードになってしまうｗ

>>312 なら追いつける自信があるけど、そっから先どこまで行ったんだろうね。。。

>>316
自信あるのかよ！
ハッキリ言ってなんでこれで性能上がるのか理解不能っていう（デ？）チューンをしてる

15clkが本当なら>>312は99％突破してるわけだが

虚虚実実ですなw

再提出上等
スコア更新する度にフィックスターズに送りつけてやるぜﾍﾍﾍ

このスレで期限前に最速コードを公開して、コンテストを無効化して、そして伝説へ…
なんてストーリーがあるのかなと妄想してたよ。2chっぽくさ。いやいや、全然勧めてないからやらないでね。

いや、でも、なかなか燃える展開だな。がんばれ、団子３兄弟。

58156364 / 4(SIMD) * 15(cycle) / 40(ticks) = 5452159.125 か。
だれか 15cycle の壁をやぶってくれw

temperingをテーブル参照で・・・


って、数十GBメモリが必要になりますよ

じゃぁ、それを計算で求めるようにしよう！！！

ってのはおいといて、おいらも>>312が視野に入ってきたかな。。。

9%→90%→99%→99.9$→・・・

ですね。わかります

>>322
だんごさんが15を破れることバラしちゃったから俺もバラすけど、
15は数日前にもう破ってるよ。
コンパイラの吐くコードがよろしくなくて、調整の時間が取れてないだけ。

>>325
99.9$ ・・・ 9000円くらい？

未だかつてこのスレでこんなにCellプログラミングが流行ったことがあっただろうか、いやない

きそう、この週末丁度暇になったのにPS3は会社のだから事務所に置きっぱなしだ……
尤も、半年以上放置しているから今更勘が戻らないけどね。

>>328
大丈夫、俺なんてCellプログラミングは初めてだ。
リモートの開発環境も用意してくれるよ。

・・・べ、別に誘ってるわけじゃないんだからねっ！
どっちかっていうとライバルが増えると困るんだからねっ！

>>326
切ったのは16（っていうか18）じゃなくて？

どうせ4要素毎にspu_addして最後に合計を水平加算してるっしょ？
加算はEvenパイプだよ。

あんまり具体的な話をするのは、１～２人で参加という趣旨に反すると
思うよ。

>>328
Cell SDKはx86のLinuxにも入れられるぞ
シミュレータもある。

あー、呑んだ。酔っぱらった。酔ったまんま unroll にとりかかるぜw
>>325,326
おいら今 unroll してない状態で 16cycle だから、近いかなぁ、と。
>>330
18ってなに？ともあれ、なんとか even をあと一つ縮めたいよなぁ…
>>331
どうせおいら申し込んでないしー。ってか名前&社名出せねぇw

>>330
あれ、だんごさんに言われると不安になってきた。
あとで数えなおし＆理論限界の計算しなおししてみる。

>>334
ってか、even 15 切ってるのが居たら神な希ガス
>>322 に書いたけど、だんごさんも 15 は切ってないよ。
どれだけ論理限界(15)に近づけるかの勝負でしょ。
それか誰かが 15 を切るかw

あ、>>301 の 5.47M は間違いだと思われ

パイプラインの空き35位まで詰められたけど、理論性能の95%しか出てない。
>>312が99.6%出してる時点で勝てそうにないorz

>>312は2日前の成果。日増しに（わずかながらではあるが）性能は伸びてる

理論スループット15になる方法思いついたときは俺SUGEEEEEEEEEEって思ったけど
そこまでは案外みんな気づくの早かったな。

>>335
even? odd じゃね？ tempering 的に言って。
>>339
てっきり15サイクル切ったと思ったけど、本気で15サイクルのコードで
そのスコアを超えたのか。すげーな。

おいおい逆だ

＞てっきり15サイクル切ったと思ったけど、本気で15サイクルのコードで
それは秘密。

ただ、部分的に式の変形はしてる。高速化のためにどうしても必要だった。

>>341
おおおおおおおお！
俺、v = mt[k] とかに //e って、 spu_and() とかに //o ってコメント付けてた！
恥ずかしー！

ど素人ですけど、ＣＥＬＬに悪戦苦闘してる方々に質問。
ＣＥＬＬのメモリ構成の扱いにくさって、将来ＬＳの容量が増えて
各ＳＰＵが特定の仕事に専心するようになったら、それほど
大きな足かせにならない気がするんですけど、どうでしょうか？
今はＬＳの容量が少なすぎて、頻繁に書き換えが必要だから超面倒だけど。
クタはそこまで考えて、ＬＳにしたんじゃないんでしょうか？

なんか書き込みがゲハ臭いから回答すべきか「帰りな」と言うべきか迷うが。
クタだけに焦点を当てるなら、PS3を設計している最中に「LSが増えたら」が無いのは考えれば分かる話だよな?

ほんとゲハ臭いなw
>>344
ここで Hack the Cell やるような人は扱いにくいとか思ってないんじゃん？
扱いにくいってなるのは、プロジェクトが大きくなって C# あがりの
へたれプログラマも使わなきゃいけなくなった時じゃないかな？
Hack the Cell やるような職人にとっては LS の容量が少なくて超面倒って
事はなくて(ちょっと面倒くらいw)、へたれにとっては LS の容量が増えても、
ヘテロだったり cache じゃなかったりの時点で超面倒なんだと思われ。
今だったら Larrabee みたいな方がいいに決まってるっしょ。

今だったら => 今から作るんだったら

LarrabeeってCell扱うのはマンドクセッと思ってる
ヘタレ（と言うよりPCのCPUのみ扱い慣れている）
プログラマに取ってはいかにも扱いやすそうに見えるが
キャッシュレベルで勝手に同期が取られる事を良い事に
ついスレッドのあちこちで頻繁に同期を取るプログラムを
書いてしまってそれがキャッシュ用リング？バスの帯域を
圧迫してパフォーマンスが出ないと言う罠に陥りそうな希ガス。

いいからゲハに帰れよ

>>348
何言っているんだか。まるでx86だけがPCのCPUみたいな言い方しなさんな。
つーか、LarrabeeとCellを同列で語ること自体がどうかしている。