135 の扱いが厄介だ。

Cell Challenge予選の結果が発表された
(入力をまだみれてないのでおそらくだけど)
2^34の問題が0.2秒で解けてるチームが1位っぽい

imosさんてチームimoか？はえーなあ

お察しの通りチームImoですー
2^34が1秒切ったと喜んでいたけども1位とは4倍の壁…
evenの埋まってる率はおそらく7割以上なのでアルゴリズムの変更が必須で悩み中

1位のチームの人Anthyの開発者？

何気にハックざセルの提出期限近いな
優勝ラインはどれぐらいだろうな？

４．５Mぐらいだと予想しているんだが

# OpenMP で並列化出来るところが少なすぎて発狂しそう…。

>>354
今週の土曜日になれば Hack the Cell のネタバレ解禁だと思うので、
パイプライン両方埋めるテクニックが盗めるかもしれませんよ。

>>356
数字書いちゃうとアレな気もしますが、一月末の時点で３．５Ｍ突破
している方もいますよ。

それはすごいな。
でも、まだフィクスタ賞のチャンスは俺には残ってるはず。

ああ、ふぃく☆すた賞狙ってる人は、コンパイラを飼い慣らすテクニックのほうを重視したほうがいいかもです。

コンパイラを飼い慣らすって
そんなに差がでるのですか

え、gccに限らずVCだろうがiccだろうがコンパイラとの格闘だぜ?

自分はオプションにアンロールとO3つけてstripぐらいしかしてないです。
さすがに-pgとかつけたままにしたりましませんが・・・
けどその位を殺っておけばいいだろうという認識です。
そんなに激しく差がでるのかー

コンパイルオプションはいじったらだめなんじゃ…

自分はcell challengeなので。

無意味なラベルを入れておくとかそういうおまじないレベルの事はやらなくて大丈夫なんだよね？

O3だと動かない＼(^o^)／

今日でひとつの祭りが終わるなぁ。勉強になったし楽しめたよ。満足満足

残念なこともあるにはあるけどなかなか楽しめたな
しばらくしたらコード公開されるのかな
それとも20までお預けかな

へるみさんは80倍ちょっとか。

ビット入れ替え思いつかずに、12cycleの壁超えられなかったもします。
フィックスターズ賞狙いですが、99%越えの接戦に勝てるか不安…。

トランザムってどうやって加算したの？
spu_cntbとかをうまく使うの？
締め切りすぎたけど、結果発表までは内緒なのかな…

俺なんか12.3cycle/qwordだ。ランク外orz

で、トランザムって何なの？
俺が・・・が出自ってことは分かったけれど

>>371
spu_cntbは最初に思いついたね

たとえば、
cntb(a) << 24 | cntb(b) << 16 | cntb(c) << cntb(d)
を8組作って、左シフト＋加算で畳み上げるってのはどう？
8ビット単位のシフト＋論理和ならspu_shuffleでできるからOddパイプ側で処理を割り振ることもできるし
このへんはいろいろやりようは有ると思う。

どっちかというとmt[]の更新のほうがめんどいんだ。
どういうレイアウトを組むかによってOddパイプの演算量が全然変わってくる。

>373
たぶんbitを90度回転したんじゃないかと。
01234...
01234...
を
0000
1111
...
な感じに。

( cntb(a) << 24 ) | ( cntb(b) << 16 ) | ( cntb(c) << 8 ) | cntb(d)
に訂正しときます

>>373
俺が最初に言い出しました。transpose + sumだからトランザム(笑)
あと速いし。さすがにmt[]の更新のほうがネックで3倍にはならないようだけどね。

なんのことはない、1bit×128並列のSIMD演算ですよ。
暗号のクラックなんかでよく使う方法です。

>>376

やっぱり1bitx128並列の事だったか。
その方法ならshift無くせるしｘｏｒとかの回数も減らせることは気が付いてたけど
めんどくさいからやらなかった。

やった場合には１要素平均何cycleまでいくものなんだろう？

>>377
ブログなんかで「大台」って言ってる人がいるけど、これは100倍のことだと思うよ。
だから2クロック切るくらいかな。

鬼すぎるw

The Art of Multiprocessor Programming 届いた。普通に神本っぽい。
ところで、KLabの中の人ってこのスレの住人だったりするのだろうか…。

>>372
12.3は何とか超えたけど、その少し先で詰まっていたりもします。

>>376
普通に translate + sum だと思ってましたo r z

ちょうどビット配列の転置アルゴリズムを「ハッカーのたのしみ」なんかが扱ってる

http://www.hackersdelight.org/HDcode/transpose32.c

temperingはそれこそすげー速くなるんだけどMT[i+1]とMT[i+M]のロードがなかなか難しいよね
いろいろやったけど命令数的に90倍速程度が理論限界で諦めた
コンパイラはレジスタ足りないってわめくし

結局普通の方法で11.75/cycleの68倍速で提出したよ
こっちのコードの方が最適化自体に手間掛けたから気に入ってるんだ

11.75cycle/QWORDだた

ところでオレ以外に学生部門の人はいないの？
学生参加は手を上げて！！

>>382
mt[i+1]のほうは奇数・偶数みたいな分け方をすればpermuteの回数を「減らす」
くらいは出来るという結論に達した。

幸いなことに先頭から226個まではは並列実行できるし。
ただ、128ビット全部使うことは諦めないといけない。
1レジスタにビットを限界までの6分割とか8分割とかにしないといけない。


参加者が少なかったせいか10倍すら超えなくても参加賞は貰えることになったらしいので
ウケを狙うのもアリだったな。

○1レジスタにビットを限界まで詰めることを諦めて104ビットずつ6分割とか78ビットずつ8分割とかにしないといけない。

>>385

全員参加賞もらえるなんてどっか出てたか？
フィクスタの社長ブログとかには参加者１５９人とか載ってるし、参加者少なすぎとかは無いんじゃないか？

http://cell.fixstars.com/challenge/entry.html

参加者特典
課題提出者全員に参加賞をプレゼントいたします。



ボールペンかなんかの予感

>>388
ほんとだ。疑ってすまんかった。
いつの間にか変わっていたんだな。

「トランザム」　=　「とらん、sum」かとおもてたよ
Tempering後のchecksumをとらないのかと。どやってやるんだそんなのと

kikxさんとこのが良く分からない
乱数生成の順番は入れ替わりそうだけど転置ではなさそうだ

> z = si_lqx(spu_slqw(spu_gather(y), 4), mag_lut);
> r = spu_xor(spu_rlmaskqw(y,-1), z);

懐かしい


左4ビットシフトもspu_shuffleでできるよね？
このへんはみんな気づいたかなと思うけど。

シャッフル1回でってこと？
想像もつかない

何となく11.75になる方法分かったorz

>391
mt[]の中の順番が入れ替わるだけ、かな？

>392
団子さんは結局何倍までいけました？

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)

とまったく同じ結果になる筈。

>>395
ノーコメント

shinhさんが俺をオフ会に誘ってるようですなｗｗｗ

>>396
なるほど
そういえば最初のうちは似たような使い方することで
shuffleの定数生成機能を利用して1bitシフトしようとかしてたなぁ

でも、フィックスターズで会合セッティングするって、
社長blogに書いてあったよね。