元スレcellプログラミングしちゃいなよ4
cell覧 / PC版 /みんなの評価 : ○
354 = :
お察しの通りチームImoですー
2^34が1秒切ったと喜んでいたけども1位とは4倍の壁…
evenの埋まってる率はおそらく7割以上なのでアルゴリズムの変更が必須で悩み中
356 = :
何気にハックざセルの提出期限近いな
優勝ラインはどれぐらいだろうな?
4.5Mぐらいだと予想しているんだが
357 = :
# OpenMP で並列化出来るところが少なすぎて発狂しそう…。
>>354
今週の土曜日になれば Hack the Cell のネタバレ解禁だと思うので、
パイプライン両方埋めるテクニックが盗めるかもしれませんよ。
>>356
数字書いちゃうとアレな気もしますが、一月末の時点で3.5M突破
している方もいますよ。
358 = :
それはすごいな。
でも、まだフィクスタ賞のチャンスは俺には残ってるはず。
359 = :
ああ、ふぃく☆すた賞狙ってる人は、コンパイラを飼い慣らすテクニックのほうを重視したほうがいいかもです。
360 = :
コンパイラを飼い慣らすって
そんなに差がでるのですか
362 = :
自分はオプションにアンロールとO3つけてstripぐらいしかしてないです。
さすがに-pgとかつけたままにしたりましませんが・・・
けどその位を殺っておけばいいだろうという認識です。
そんなに激しく差がでるのかー
363 = :
コンパイルオプションはいじったらだめなんじゃ…
365 = :
無意味なラベルを入れておくとかそういうおまじないレベルの事はやらなくて大丈夫なんだよね?
367 = :
今日でひとつの祭りが終わるなぁ。勉強になったし楽しめたよ。満足満足
368 = :
残念なこともあるにはあるけどなかなか楽しめたな
しばらくしたらコード公開されるのかな
それとも20までお預けかな
369 = :
へるみさんは80倍ちょっとか。
371 = :
トランザムってどうやって加算したの?
spu_cntbとかをうまく使うの?
締め切りすぎたけど、結果発表までは内緒なのかな…
372 = :
俺なんか12.3cycle/qwordだ。ランク外orz
373 = :
で、トランザムって何なの?
俺が・・・が出自ってことは分かったけれど
374 = :
>>371
spu_cntbは最初に思いついたね
たとえば、
cntb(a) << 24 | cntb(b) << 16 | cntb(c) << cntb(d)
を8組作って、左シフト+加算で畳み上げるってのはどう?
8ビット単位のシフト+論理和ならspu_shuffleでできるからOddパイプ側で処理を割り振ることもできるし
このへんはいろいろやりようは有ると思う。
どっちかというとmt[]の更新のほうがめんどいんだ。
どういうレイアウトを組むかによってOddパイプの演算量が全然変わってくる。
375 = :
>373
たぶんbitを90度回転したんじゃないかと。
01234...
01234...
を
0000
1111
...
な感じに。
376 = :
( cntb(a) << 24 ) | ( cntb(b) << 16 ) | ( cntb(c) << 8 ) | cntb(d)
に訂正しときます
>>373
俺が最初に言い出しました。transpose + sumだからトランザム(笑)
あと速いし。さすがにmt[]の更新のほうがネックで3倍にはならないようだけどね。
なんのことはない、1bit×128並列のSIMD演算ですよ。
暗号のクラックなんかでよく使う方法です。
377 = :
>>376
やっぱり1bitx128並列の事だったか。
その方法ならshift無くせるしxorとかの回数も減らせることは気が付いてたけど
めんどくさいからやらなかった。
やった場合には1要素平均何cycleまでいくものなんだろう?
378 = :
>>377
ブログなんかで「大台」って言ってる人がいるけど、これは100倍のことだと思うよ。
だから2クロック切るくらいかな。
379 = :
鬼すぎるw
380 = :
The Art of Multiprocessor Programming 届いた。普通に神本っぽい。
ところで、KLabの中の人ってこのスレの住人だったりするのだろうか…。
>>372
12.3は何とか超えたけど、その少し先で詰まっていたりもします。
>>376
普通に translate + sum だと思ってましたo r z
381 = :
ちょうどビット配列の転置アルゴリズムを「ハッカーのたのしみ」なんかが扱ってる
http://www.hackersdelight.org/HDcode/transpose32.c
382 = :
temperingはそれこそすげー速くなるんだけどMT[i+1]とMT[i+M]のロードがなかなか難しいよね
いろいろやったけど命令数的に90倍速程度が理論限界で諦めた
コンパイラはレジスタ足りないってわめくし
結局普通の方法で11.75/cycleの68倍速で提出したよ
こっちのコードの方が最適化自体に手間掛けたから気に入ってるんだ
384 = :
ところでオレ以外に学生部門の人はいないの?
学生参加は手を上げて!!
385 = :
>>382
mt[i+1]のほうは奇数・偶数みたいな分け方をすればpermuteの回数を「減らす」
くらいは出来るという結論に達した。
幸いなことに先頭から226個まではは並列実行できるし。
ただ、128ビット全部使うことは諦めないといけない。
1レジスタにビットを限界までの6分割とか8分割とかにしないといけない。
参加者が少なかったせいか10倍すら超えなくても参加賞は貰えることになったらしいので
ウケを狙うのもアリだったな。
387 = :
>>385
全員参加賞もらえるなんてどっか出てたか?
フィクスタの社長ブログとかには参加者159人とか載ってるし、参加者少なすぎとかは無いんじゃないか?
388 = :
http://cell.fixstars.com/challenge/entry.html
参加者特典
課題提出者全員に参加賞をプレゼントいたします。
ボールペンかなんかの予感
389 = :
>>388
ほんとだ。疑ってすまんかった。
いつの間にか変わっていたんだな。
390 = :
「トランザム」 = 「とらん、sum」かとおもてたよ
Tempering後のchecksumをとらないのかと。どやってやるんだそんなのと
391 = :
kikxさんとこのが良く分からない
乱数生成の順番は入れ替わりそうだけど転置ではなさそうだ
392 = :
> z = si_lqx(spu_slqw(spu_gather(y), 4), mag_lut);
> r = spu_xor(spu_rlmaskqw(y,-1), z);
懐かしい
左4ビットシフトもspu_shuffleでできるよね?
このへんはみんな気づいたかなと思うけど。
393 = :
シャッフル1回でってこと?
想像もつかない
394 = :
何となく11.75になる方法分かったorz
395 = :
>391
mt[]の中の順番が入れ替わるだけ、かな?
>392
団子さんは結局何倍までいけました?
396 = :
spu_gatherやるとさ、プリファードスロットの下位4ビットにLSBが集約されるじゃん。
で、他は0になるじゃんじゃん。
spu_shuffleの第一引数に
{ 0x00, 0x10, 0x20, 0x30, 0x40 ,,, 0xF0 }
ってベクトルブッ込むわけだ。
spu_shuffle( pattern, pattern, (vec_uchar16)spu_gather(y) )
これで
spu_slqw(spu_gather(y), 4)
とまったく同じ結果になる筈。
397 = :
>>395
ノーコメント
398 = :
shinhさんが俺をオフ会に誘ってるようですなwww
400 = :
でも、フィックスターズで会合セッティングするって、
社長blogに書いてあったよね。
みんなの評価 : ○
類似してるかもしれないスレッド
- cellプログラミングしちゃいなよ3 (1001) - [97%] - 2009/1/27 2:23 ☆
- CELL鬯ッ?ゥ隰ウ?セ??ス??オ????コ?????ッCore2 QX6700鬯ッ?ゥ隰ウ?セ??ス??オ????コ???? (92) - [18446744073709551581%] - 2012/1/21 0:39
トップメニューへ / →のくす牧場書庫について