4.3でやれ。

一番上が29Mticksくらい

何とか6MTick突破。spu_timing 見る限りもっと詰められそうな気もする…。
これからドルアーガの中継見て寝る。

>>228
今は3Dプログラミングだけに集中したいと思っていたりもします。

spu_timing ってなんですか？とググらずに聞いてみるテスト。

もっと画期的なモン使えよ

>>252
ども。29M って事は、50 倍だとやっぱとりあえずの目標が 6M なのね。
いま、ちょっとやったら 10M@gcc4.1 にはなった。さっきは 20M。
さらに半減かぁ。だんだん最適化できる所が減ってきたなぁ。

アンローリングしまくったら遅くなって、アセンブラ見るとローカル変数をLSに読み書きしてる・・・
コンパイラがバカなのか、レジスタ128個じゃパイプライン詰められないのか、よく判らん。

5.6M切ったよ

うぁー、5M台増えてきたな。
みんなすげー。

現在確認されている5M台は、だんごさん、俺、>>227、>>258 と、リーク情報の提出者か。
提出者 = >>258 だったりしないのかな？

トリップ付けて、コードのコメントにトリップパスつけるという手もあるな。

団子先生(笑)と同じチームだったりします。

>>262
名前貸してPS3をゲットを狙ってる人か
>>247の書き込みみると，学生部門じゃなく社会人部門で参加してるのね


ところでCellチャレやってる人はいないのかな
ここ学生少ないんかね？

トリップで mt_mine.c の sha1sum 書き込んどきゃいいじゃん

証明する気など更々ないんだが

中の人は中の人名義で別の活動やってるからこっちの名前で技術的名声得ても何のメリットもないし。
だんごやさんとは所詮「記号」だ。tanasinnなみに退廃的な概念だ。
なによりでしゃばりすぎだ、だんごやさんは

>>264
一度トリップ付けたら、その後ソース改変できなくなるじゃん。

ん？？改変したらまた新しいの書き込めばいんじゃん？

>212
「45nmで32コア＋PPE2コアのCell」がどこかで発表されたの？
論理設計してみただけとか言う話じゃなく、試作チップくらい作られた？

検索したけど見つからなかったので差し支えなければソースを教えてくれ。

>>268
http://www-06.ibm.com/jp/solutions/deepcomputing/events/pdf/ibm.pdf

勘違いだった。投入は来年（2010年）ごろらしいよ。

今日と月曜休日出勤命令が出たと言うのに、こんな時間まで現実逃避して
しまって良いのだろうか…。

>>255
何この芸術的な画面。こっちは一画面分片側無しとか有るんですがｗ

>>258
ようやく追いつけた、けど次にやるべき事が見えてこない罠。

一番綺麗なところ見せてるに決まってるじゃんか。

Odd側でレイテンシ1なのはlnopかhbrだと思っていいよ。

5.6M切ったところに壁があるのかな？

なんで速くなったのかわかんねーが理論限界にまた一歩近づいた

>>273
1％上げるのすら絶対無理な境地に達した。

>>275
mjd!? 優勝候補ブチ抜けるんじゃない？
俺も準優勝以上目指して頑張ろう。

プライベートがゴタゴタしまくってて、せっかくの休みなのに殆ど弄れねー。

っていうかね

コアループの内側の片方パイプ側が全部隙間無く埋まっちゃって
これ以上どうしようもないんだよね

外側をどうにかするとかいうレベルでのチューンしかできない。

とはいってもTick数が10とか20変わるレベルなんだけど

優勝候補ってのはオレのチームに決まってるだろ

>>278
ちょｗ、>>243の優勝候補って団子さん自身だったのかよｗｗｗ

他人のスコアをリークするfixstars社員がいるのかと思ったよ。

っていうか>>271見て焦った
だが、普通無理だろっていう境地に達した

敢えて言う
spu-gcc43の特性見切った

>>280
のちの団子氏によると、ここが真のスタートラインだったという。

スタートラインに立ってる人間いくらいるんだろうな？
ループ内で片方のパイプ全部埋まってる状態なんだが。
埋めるのしんどかった。アセンブラ使わずにだからな。

というコメントを書き込み、団子氏はふと気付いた。
「アセンブラを使ったら…」

じゃあ質問してきてよ。
アセンブラ使っていいかどうか

っていうか変数おっかけるのめんどくせぇ

というコメントを残しており、
動機は未だに不明。
では、次のニュースです。

まさか、そこまで普通しないだろう。
そう、普通はしない。
しかし、Cellをいじる様な人種に常識は通用しないのだ。

今までなんとなく、心にぼんやりとあった、疑問が脳裏をよぎる。

"なぜ、MTの限られた最適化で、LSの容量も制限するという、こんなにもきつい制限の課題なのか。"

そう。実は要求レベルは、その領域にあったのだ。

スタート地点に立てた人間は、そうは多くない。しかし、そこまで行きついたものは確実に、"次"に気づいた。
だが、それらの人間とは別に、ごく一部、初めからその道を進んでいたものもいた。

そして、その先には、さらなる波乱が待っていた。

ってかさぁ、1 tick って何 cycle くらいなの？
そっから逆算すると、5.6 M の時って平均何 cycle / 32bit 生成くらい？

>270
納得した。

>>289
知ってるが、教えたくない情報の一つだなｗ

ヒント: cpuinfo

>>289, 291
40cycle/1tickだろ。5.6Mだと3.85cycle/32bitくらいか。
最低限SIMD化したとして15.4cycle/128bit。
unroll効いてるとして16～7cycle/128bitくらいか。
ホントにそんなんで出来るんか？？？

>>282
少ない方が100ぐらい空いてるので、全部詰められれば0.25MTickか…。
コンパイラが糞なら asm volatile を使って手動スケジューリングでも
しようかと考え中です。

>>292
while( spu_read_decrementer() < ~16384 ) rand();

SPU_Decrementerは内部的にチャンネル使ってます。

配列にマシン語記述ってのどうかな？

ありがちな方法だな。
いけないプログラマ丸出し

>>293
unrollするとってくだりからアレだが、そこまでの推測は正しいと思うよ。

15.4という数値がでてきたとすると、15cycle+0.4cycleで0.4がオーバーヘッドになる。
オーバーヘッドは1%くらいに抑えたいから、目標は5.51Mticksを切ること。
トップクラスはそのあたりにある壁にどこまで近づけるかというチキンレース中。

というところまで推測できちゃうから、みんなticks数は有効数字一桁しか出さなかったんだけど、
だんごさんが有効数字二桁の情報を出してきたのは、「cycle数で並ばれても壁までの近さなら
負けない」という意思表示かな。カッコイイ。

普段使ってるのと違うPCで書き込みしたらsage忘れた。スマソ。

＞unroll効いてるとして16～7cycle/128bitくらいか。
これが意味不明なんだけどね。

アンロールしようが何しようが演算ユニットが増えるわけじゃない。
演算ユニットの稼働率をいくらまで詰めるかって課題なわけで。

っていうか
「15サイクル」って具体的な数字が出てきたけど、本当にそれでいいのか、そこから考えないといけない。