前スレ
cellプログラミングしちゃいなよ3
http://pc11.2ch.net/test/read.cgi/tech/1215388508/l50

Cell Broadband Engine 技術情報公開
http://cell.scei.co.jp/

PLAYSTATION3 Linux Information Site
http://cell.fixstars.com/ps3linux/index.php

The Cell Processor - PukiWiki
http://cell.fixstars.com/pukiwiki/index.php

developerWorks : Cell Broadband Engine resource center(IBMのCell技術情報)
http://www-128.ibm.com/developerworks/power/cell/

Cell Broadband Engine Architecture forum (Cellプログラミングの掲示板)
http://www.ibm.com/developerworks/forums/dw_forum.jsp?forum=739&cat=46

Multicore Programming Primer: PS3 Cell Programming
(マサチューセッツ工科大学のPS3を使ったマルチコアプログラム演習。ソースコードなど有り)
http://cag.csail.mit.edu/ps3/

CellPerformance
http://www.cellperformance.com/articles/

推奨NGNAME:●

8.5・・・だと？

6.5だろ

じゃあ、俺は 7.0 位でお願いします。

アナルアナル言うからハッテン後なんだよ

すげーな、8.5とか。
普通に32bit整数型で、ビット順そのままの乱数を生成してるのかな？

脳内レジスタにはちゃんと順番通りにならんでるんじゃん？ｗ

中の人の反応見るになんか迷走してるようだな。出題ミスってレベルじゃね－ぞ。

え、何を瞑想してるの？

条件が変わるかも知れない

またですか？

>>10
公式見解でないねｗ

本当はコンテスト後に「当社のリファレンスコードは～」って
シュバッとする予定だったんじゃねえの？

インラインアセンブラも、最初はまずくねー？、大丈夫だろ？
って方針がコロコロ変わったと考えると滑稽。

今から課題の条件を変えるのはバカ丸出し。
出題ミスを認めるのがそれなりに王道。
リファレンスコードなかったことにするのが正解。


>>前スレ995
そう焦るなって。コンテ終わったら公開するよ。

最適化のベースになるようなアイディアを放出してみんなに
迷惑かける気は、今のところはない。

ついでに、SPU に特化した最適化は、(個人的には)興味ない。
だから intrinsics 使わないで優勝しようと画策していたわけだが、
自分でダメにしちゃったｗ

>>前スレ997
>つか64ビット整数で処理したら速くならない?
速くなると思うよ。

が、uint64_t が portable かといえば(まだ・そんなに) portable じゃ
ないからね。

アナル拡大体なわけだが。

Fixstarsの返事はまだか
既に提出してる人が何人もいて今更変更できないとか

それはそうと団子って再利用性がどうとか実用性がこうとか言ってなかったっけ
結局乱数列の生成には何の役にもたたないコード書いてんのな
今更Cにこだわる必要も無いと思うんだけどどうだろう

俺は俺なりに俺が他のアーキテクチャに移植しやすいように書いてるつもりなんだけど
他って具体的にSSE4/AVXなんだけど

てか、上位入賞者用の参加賞ってさ、どうせ

YDL6.1（ノンサポート版）

だろ？別に要らないんだが。

新しいアルゴリズムだと生成された乱数を毎回デコードすると元より遅くなるんだろ
実用性があるとすれば生成されたそのままのフォーマットで演算に利用できる場合位かな
この大会にしか使えないものの移植性なんて考えるだけばからしいと思うが

PS3持ってない奴がYDL6.1もらっても悲しくなるだけじゃないかｗ
Fixstarsのロゴが入った写真立てとか置物とかじゃないかと思ってるんだが

とりあえず速度さえ出ればなんでもいいってことになれば、
2つのソースを送って古いほうを公開してくださいって言うだろうね。

いちおうPowerPCのMacには使えるだろ？俺的にTigerで充分だけど。

分かってないんだけど、579 のは大量に読み飛ばす場合なんかには高速になるんでしょ？
充分有用だし、却下されるべきではないと思うけど。

>>22
有用であるかどうかが基準のコンテストではないからな。

「同じ乱数列を生成する」という課題に対して、579の解法はチェックサムしか計算してない。
チェックサムを元に「同じ乱数列を生成する」事ができるが、計測している時間は「同じ乱数列を
生成する」時間ではなくて「チェックサムを計算する」時間でしかない。
他の人は、フォーマットの変更のあり・なしの違いはあるものの、「同じ乱数列を生成」した上で
チェックサムの計算まで行って、時間を計っている。

ルールがフォーマット変更可・不可にかかわらず、579の回答は課題の趣旨と違なる。
だが、配布されている課題プログラムでは、チェックサムさえ合ってれば通ってしまう。

「mt_kadaiはチェックサムしかチェックしてないけど、同じ乱数生成しないでチェックサムだけ計算する
のはあり？」と質問したので、回答待ち。
回答が「同じ乱数列を生成しないとダメ」だった場合、「バイト単位・ビット単位の順番を入れ替える
変形はあり？それ以上の変形はあり？」と、質問しなおす予定。

こういうコンテストに応募するのはこういう人種になることくらい容易に想像できるんだから、
きちっと詰めておかないのは甘過ぎると言わざるを得ないなぁ。

出来るってことは重要だけど使う場面はなさそうだな
普通乱数の和が欲しかったら統計的な方法使ってもっとはしょるだろうし
厳密に計算した乱数の和が必要になることがあれば有用かも
もちろん今回は乱数の和だっただけでいろんな演算を同じ様に高速化出来るかもしれないけどね

それはそうと乱数を大量に読み飛ばす場面ってのが初期化以外で思いつかない
それに読み飛ばすだけなら普通の方法の方が高速なきがする

>>23
まぁ fixstars の回答待ちは変らんけど、「チェックサムを計算する」だけなのはなしだけど、
「バイト単位・ビット単位の順番を入れ替える変形はあり？それ以上の変形はあり？」に
関してはありな気がする、っていうか、ありでいいと思うなぁ。疑似乱数列なんて、順番を
入れ替えても乱数性が変らない事が重要なんだから、実用上そう困る事はないだろうし…
あるとしたら、他の環境で再現したいときとかくらいでしょ。。。ってそれなりに大事かw

順番変えたらfixstarsの検証が大変だろ
（疑似）乱数って明確な定義がないんだぜ

計算した値をとりだすことはできるから再現性とかの問題は無い
値をとりだすのに計算以上の時間が必要なだけ
SUMなら値をとりださずに計算できるから高速化可能という話

しかしFixstars反応無いな
審議中なのか事態に気がついていないのか
スルーされた場合どっちを提出しようかな

中の人はちゃんとこのスレ見てるよｗ
回答はちょっと待っててってメール来た。

締切まで期限切られてるのに回答を先延ばしするのは理不尽以外のなんでもない。
結局、方針がどうなるか次第なわけだが、ヤマカンで当て込んだ人が特をするんだろ？

回答もらえたときには既に締切まで時間が足りなかったりする可能性を考えて欲しい

>>27
？？どういう意味で言ってる？順番変えても擬似乱数としては等価でしょ？
順番いれかえて使ったら乱数性が弱くなるなんて擬似乱数としてダメダメだし。
まぁ、応募コードの検証って意味では fixstars は若干大変になると思うがｗ
「擬似乱数列は、メルセンヌ・ツイスタの実装と同じ乱数列を生成すること。
　ただし、メモリおよびレジスタ上の配置方法については言及しない」
でいい気がするんだけどなぁ。(課題のページ、"似乱数列"になってるｗ)

あと、前 688 にあった、
> hash = genrand_mine(num_rand) + genrand_mine(num_rand2);
みたいなのも、本質的ではないからなしにして明言して欲しいなぁ。

>>14
>最適化のベースになるようなアイディアを放出してみんなに
>迷惑かける気は、今のところはない。
曝しちまえって。そうすればコンテ側もそれＮＧにするからさｗ
尤もハッタリだったら曝せないだろうけどなーｗｗｗｗ

チェックサムのみの検証だってさ！
ショートカット万歳！！

>>32
temperingする前の乱数列だって乱数の1表現なんだぜ？
その値から一意に求めるデータを取り出せるんだからな
tempering前の方が乱数的に弱いんだけどそれでもbit自由に入れ替えておｋっていえる？

結局おｋになったんだけど

Hack the Cell 2009 ご参加の皆様

この度は、Hack the Cell 2009にご参加いただき、
誠にありがとうございます。

Hack the Cell 2009の課題について、お詫びと訂正をさせていただきます。

皆様から課題の検証方法に関して多数のご質問がありました。
課題内容が不明瞭であったことを深くお詫び申し上げます。

「課題の検証方法に関しては、チェックサムの整合性でのみ判断いたします。」

課題 kadai1.tar.gz に含まれるcompare関数が乱数列のチェックサムを検証するもので
あったにも関わらず 「mt19937ar.cと同じ乱数列を生成してください」という定義のあい
まいな表記がありました。

課題内容の不完全性を深く反省するとともに、既に課題を提出した方々を配慮し、 現段
階での課題プログラムの変更はせずに、乱数列のチェックサムの整合性により検証を行
い、順位を決めることにさせて頂きます。

自由な発想での最適化を歓迎いたします。

また予想以上の盛り上がりに感謝し、「実用性に優れている」と弊社にて判断したプログ
ラムに対して「フィックスターズ賞」を追加することに決定しました。

「実用性に優れている」と判断する基準
* MT 乱数 (tempering された乱数) を生成している
* オリジナルコードと同じ順序で乱数を出力している
* MT 乱数を簡単に取り出せること (関数の戻り値, 配列に格納, など)
* 高速である
※上記の基準をもとに総合的に判断します。

どう見ても出来レースの悪寒。

優勝よりフィックスターズ賞狙うほうが俺のポリシー的にアリだな。
へたに優勝狙って3位とかになるよりは歯切れもいい。

>>38
それには同意
しかしフィクスタ賞は倍率高そうだな

このスレは202と団子が反省し合うスレになりますた

主催者的にはフィックスターズ賞が優勝なんだろうなぁ。

>>41
フィックスターズ惨めだなおい。

>>35
tempering 前の乱数列はメルセンヌ・ツイスタの実装と同じ乱数列ではないよ？
順番を入れ替える(配置を変える)のは等価だけど、演算(tempering)を変えたら
そら違う乱数列でしょ。乱数列の使い方を変えただけなら価値は変わらん。
(endian 変えて使おうが、bit flip して使おうが、証明された乱数性は変わらん)

って結局おｋになったんだけどｗ

いやー、でも、こうなると 579 のが本当ならやる気なくなるなー orz

ってか、フィックスターズ賞の賞品はなに？ｗ

> 「実用性に優れている」と判断する基準
> * MT 乱数 (tempering された乱数) を生成している
> * オリジナルコードと同じ順序で乱数を出力している
> * MT 乱数を簡単に取り出せること (関数の戻り値, 配列に格納, など)
> * 高速である

さて、フィクスターズの暖めてたもはんかいとうを探ろうかw

>>44
YDL6.1（サポート版） とかｗｗｗｗ

>>32
注意事項の "似乱数列" が訂正線引かれてるのに擬似乱数に修正されてるｗ
どんだけここチェックしてんすかｗ

> 一回 genrand_mine() を呼び出す前には必ず一回以上 init_genrand_mine() が呼び出される
あ、これ明記されたのね。前 688 をやる必要はなくなったな。

>>47
でも実質ここが一番活発なフォーラムじゃない?
良くも悪くも団子が参加したからだけど。

真の優勝争いは O(1) 計数を持ってきた者どうしとなる。