元スレcellプログラミングしちゃいなよ3
cell覧 / PC版 /みんなの評価 : ☆
252 = :
一番上が29Mticksくらい
253 = :
何とか6MTick突破。spu_timing 見る限りもっと詰められそうな気もする…。
これからドルアーガの中継見て寝る。
>>228
今は3Dプログラミングだけに集中したいと思っていたりもします。
255 = :
256 = :
>>252
ども。29M って事は、50 倍だとやっぱとりあえずの目標が 6M なのね。
いま、ちょっとやったら 10M@gcc4.1 にはなった。さっきは 20M。
さらに半減かぁ。だんだん最適化できる所が減ってきたなぁ。
257 = :
アンローリングしまくったら遅くなって、アセンブラ見るとローカル変数をLSに読み書きしてる・・・
コンパイラがバカなのか、レジスタ128個じゃパイプライン詰められないのか、よく判らん。
258 = :
5.6M切ったよ
259 = :
うぁー、5M台増えてきたな。
みんなすげー。
260 = :
現在確認されている5M台は、だんごさん、俺、>>227、>>258 と、リーク情報の提出者か。
提出者 = >>258 だったりしないのかな?
261 = :
トリップ付けて、コードのコメントにトリップパスつけるという手もあるな。
262 = :
団子先生(笑)と同じチームだったりします。
263 = :
>>262
名前貸してPS3をゲットを狙ってる人か
>>247の書き込みみると,学生部門じゃなく社会人部門で参加してるのね
ところでCellチャレやってる人はいないのかな
ここ学生少ないんかね?
264 = :
トリップで mt_mine.c の sha1sum 書き込んどきゃいいじゃん
265 = :
証明する気など更々ないんだが
中の人は中の人名義で別の活動やってるからこっちの名前で技術的名声得ても何のメリットもないし。
だんごやさんとは所詮「記号」だ。tanasinnなみに退廃的な概念だ。
なによりでしゃばりすぎだ、だんごやさんは
266 = :
>>264
一度トリップ付けたら、その後ソース改変できなくなるじゃん。
267 = :
ん??改変したらまた新しいの書き込めばいんじゃん?
268 = :
>212
「45nmで32コア+PPE2コアのCell」がどこかで発表されたの?
論理設計してみただけとか言う話じゃなく、試作チップくらい作られた?
検索したけど見つからなかったので差し支えなければソースを教えてくれ。
269 = :
>>268
http://www-06.ibm.com/jp/solutions/deepcomputing/events/pdf/ibm.pdf
270 = :
勘違いだった。投入は来年(2010年)ごろらしいよ。
271 = :
今日と月曜休日出勤命令が出たと言うのに、こんな時間まで現実逃避して
しまって良いのだろうか…。
>>255
何この芸術的な画面。こっちは一画面分片側無しとか有るんですがw
>>258
ようやく追いつけた、けど次にやるべき事が見えてこない罠。
273 = :
5.6M切ったところに壁があるのかな?
274 = :
なんで速くなったのかわかんねーが理論限界にまた一歩近づいた
275 = :
>>273
1%上げるのすら絶対無理な境地に達した。
276 = :
>>275
mjd!? 優勝候補ブチ抜けるんじゃない?
俺も準優勝以上目指して頑張ろう。
プライベートがゴタゴタしまくってて、せっかくの休みなのに殆ど弄れねー。
277 = :
っていうかね
コアループの内側の片方パイプ側が全部隙間無く埋まっちゃって
これ以上どうしようもないんだよね
外側をどうにかするとかいうレベルでのチューンしかできない。
とはいってもTick数が10とか20変わるレベルなんだけど
278 = :
優勝候補ってのはオレのチームに決まってるだろ
279 = :
>>278
ちょw、>>243の優勝候補って団子さん自身だったのかよwww
他人のスコアをリークするfixstars社員がいるのかと思ったよ。
280 = :
っていうか>>271見て焦った
だが、普通無理だろっていう境地に達した
敢えて言う
spu-gcc43の特性見切った
281 = :
>>280
のちの団子氏によると、ここが真のスタートラインだったという。
282 = :
スタートラインに立ってる人間いくらいるんだろうな?
ループ内で片方のパイプ全部埋まってる状態なんだが。
埋めるのしんどかった。アセンブラ使わずにだからな。
283 = :
というコメントを書き込み、団子氏はふと気付いた。
「アセンブラを使ったら…」
284 = :
じゃあ質問してきてよ。
アセンブラ使っていいかどうか
っていうか変数おっかけるのめんどくせぇ
285 = :
というコメントを残しており、
動機は未だに不明。
では、次のニュースです。
286 = :
まさか、そこまで普通しないだろう。
そう、普通はしない。
しかし、Cellをいじる様な人種に常識は通用しないのだ。
287 = :
今までなんとなく、心にぼんやりとあった、疑問が脳裏をよぎる。
"なぜ、MTの限られた最適化で、LSの容量も制限するという、こんなにもきつい制限の課題なのか。"
そう。実は要求レベルは、その領域にあったのだ。
288 = :
スタート地点に立てた人間は、そうは多くない。しかし、そこまで行きついたものは確実に、"次"に気づいた。
だが、それらの人間とは別に、ごく一部、初めからその道を進んでいたものもいた。
そして、その先には、さらなる波乱が待っていた。
289 = :
ってかさぁ、1 tick って何 cycle くらいなの?
そっから逆算すると、5.6 M の時って平均何 cycle / 32bit 生成くらい?
290 = :
>270
納得した。
293 = :
>>289, 291
40cycle/1tickだろ。5.6Mだと3.85cycle/32bitくらいか。
最低限SIMD化したとして15.4cycle/128bit。
unroll効いてるとして16~7cycle/128bitくらいか。
ホントにそんなんで出来るんか???
294 = :
>>282
少ない方が100ぐらい空いてるので、全部詰められれば0.25MTickか…。
コンパイラが糞なら asm volatile を使って手動スケジューリングでも
しようかと考え中です。
>>292
while( spu_read_decrementer() < ~16384 ) rand();
296 = :
配列にマシン語記述ってのどうかな?
ありがちな方法だな。
いけないプログラマ丸出し
298 = :
普段使ってるのと違うPCで書き込みしたらsage忘れた。スマソ。
299 = :
>unroll効いてるとして16~7cycle/128bitくらいか。
これが意味不明なんだけどね。
アンロールしようが何しようが演算ユニットが増えるわけじゃない。
演算ユニットの稼働率をいくらまで詰めるかって課題なわけで。
300 = :
っていうか
「15サイクル」って具体的な数字が出てきたけど、本当にそれでいいのか、そこから考えないといけない。
みんなの評価 : ☆
類似してるかもしれないスレッド
- cellプログラミングしちゃいなよ4 (607) - [97%] - 2009/3/24 11:04 ○
- CELL鬯ッ?ゥ隰ウ?セ??ス??オ????コ?????ッCore2 QX6700鬯ッ?ゥ隰ウ?セ??ス??オ????コ???? (92) - [18446744073709551581%] - 2012/1/21 0:39
トップメニューへ / →のくす牧場書庫について