2のべき乗ならいいんじゃないの？
テキトーに言ってみるけど。

>>400
そこだけでいいと思うけど・・・
PS3なら個数は1~6までSPEが利用できる

>>389
SFMTより速いんじゃね？

>>401-402
ありがとうございます。
変更箇所はこちらであっているみたいですね
タイム関数を利用して処理時間を測定しても、逆にSPEを利用したほうが時間が延びてしまいます。
理論上ではSPE１からSPE4にしたら1/4になるはずですよね？
ppeのメイン関数にあるresultをかこって測定しているのですが適切ではないのかな
すみません、出力に要した時間を測定するにはどこが適切なのでしょう
http://cell.fixstars.com/pukiwiki/index.php?tips_timebase タイム関数はこれを使用しています

>>404
そもそもこの問題ってそんな大規模な数を計算してないから
下手にSPE増やすとデータ転送時間やらその他もろもろが増えて
逆に遅くなる可能性のほうが高いよ

そうですか…わかりました。測定するプログラム自体が間違いだったんですかｗ
性能を見るために適したプログラム・・・どっかありますかね？
探してみます。

質問です。
ＣＥＬＬとLarrabee ってどの程度性能差があるんですか？
大して性能差がないとしたら、仮にＰＳ４が出るとして、
ソニーがＣＥＬＬに拘る意味って、もはや無いのでは？
むしろＰＣの世界で主流になるであろう、Larrabeeに
切り替えた方がコスト的にも有利なのでは？

ゲハ板にお帰りください。

>>403
逆説的だけど、並列演算を前提にした場合、実はオリジナルのMTのほうが並列度の高い
（高くしないと性能の出ない）アーキテクチャに向いてるってのはある。

MTの配列のうち、先頭から224個、残りの400個は並列演算可能だ。
これはCUDAの実装についての説明。
ソースはCUDA SDKのサンプルにも入ってる。
http://developer.download.nvidia.com/compute/cuda/sdk/website/projects/MersenneTwister/doc/MersenneTwister.pdf

それに対して、対してSFMTは4要素（＝128ビット）の計算をしないとその次の4要素の計算ができない。
要するに依存関係があって、128ビット性能が出ない。
各命令のレイテンシが大きいとSFMTは相対的に不向きってことになるかもね。

× 要するに依存関係があって、128ビット性能が出ない。
× 要するに依存関係があって、128ビットSIMD演算を低レイテンシで実行できるアーキでないとが出ない。

つっこみたいんだが

どうぞ


今回の課題のMTはSFMTと比べてレイテンシを埋めるためのテクニックが使いやすいのは事実だよ。
っていうか誰かCUDAにSFMT移植してごらん？4論理スレッドしか並列実行できない悲惨なことになる。

いや、どっちも×なところになんだがｗ

○ 要するに依存関係があって、128ビットSIMD演算を低レイテンシで実行できるアーキでないと性能が出ない。

タイピングしすぎで腱鞘炎になりそう

>407
Larrabeeはまだ世の中に出ていないので誰にも分かりません。
性能比較は用途によって変わるので今、Cellが使われている用途に
そのままLarrabeeが使われたらどうなるかなんて仮定の話は
Intelの中の人ですら分からないでしょう。

またPC用のCPUの世界でLarrabeeのような
シンプルなコアをたくさん集積したメニーコアが
すぐに流行る事も無いでしょう。

流行るとしてもだいぶ先の話（10年先か20年先か？）

>>409
速さもランダム性も優れているなんて虫が良すぎるんじゃないかとは思っていたんだ。
ふつーなら、どっちかのはずだもんな。元がひどくない限りは。

99%超えたおー

http://cell.fixstars.com/challenge/faq.html#kadai4
> インラインアセンブラは使用してもよいですか？
> インラインアセンブラは禁止としていましたが、使用していただいて構いません。(1/15 更新)

中の人このスレ見てるな。

なんか、いきなり競争のルールが変わってしまったな。

いちいちルールなんて再確認しないだろうから、このスレ見てない人が可哀想だよな。

迷走してるな。
アセンブラレベルでCellを熟知してない人間にはチャンスを与えない試験に成り果てた。
コンパイルオプション変更許可しない意味が既に無い。

>アセンブラレベルでCellを熟知してない人間にはチャンスを与えない試験に成り果てた。
そのレベルの人には元々「勝つ」チャンスは無いと思います。
参加する事に意義がある。

アセンブラ許可自体は歓迎だが、こんなことをやると

「受賞者は最初から決めてあったんだよ！」

と言われかねない。

>>アセンブラレベルでCellを熟知してない人間にはチャンスを与えない試験に成り果てた。
>そのレベルの人には元々「勝つ」チャンスは無いと思います。

202がんがれ、超がんがれ

>>425
いやいや、202は既に熟知「した」だろ。

うーん、確かにコンテストを始めてからルールを変えるのはなんだかな。
再提出のチャンスがあるとは言えど。

主催者はルールが変わった事をメールなどで周知徹底すべきだろう。

ちょ、許可になったのかよ！！

アセンブラを生成するスクリプトをCソース吐くように改変して、
どうやって最適化昨日によるデチューンから逃れるか試行錯誤してたのに！
#pragma GCC optimize ("-O0") も、 __attribute__ ((optimize(0))) も使えない、
変数をvolatileにしたらスタックにpush/popするから超遅い、etcetc、、、

俺の2日間かえせーー！

まぁ、でも本当に Hack the spu-gcc43 になってたからな…
おいらも 4.1 だとうまくいった最適化抑制手法が、4.3 だと
使えなかったりして結構虚しくなってたからよかったかも。

敢えて言う。
今までのは全部Cだ。

あ、コンテスト終わったらでいいから、だんごさんがどうやって
最適化抑制してたのか教えてほしいかも。おいらがやってたのは
4.3 にしたら even にまで命令追加されて使えなかったっす。

どうせ、そこまでやるんならコンパイラオプションも変更可能にして
何でもアリアリの条件で競争させて欲しい。

>>432
インラインアセンブラ解禁=何でもアリだよ。
別のコンパイラで、別のコンパイルオプションでアセンブリソース吐かせて、
それをインラインアセンブラで埋め込めば良いんだから。

>>431
あ、even に追加されたのは、ori $n,$n,0 ね。
even に追加することねーだろ、って叫びたいｗ

あ、ごめん。
実質なんでもアリなら、本当に何でもアリにしてくれっていう意味ね。

>>434
ありすぎて困るｗｗｗ
ソース破壊しない命令ばっかだから、絶対いらないのにねー。

>433
うん、だからもはや意味の無い形式だけのコンパイルオプションを
いじるなと言う制約を外した方が分かりやすいだろ？

やるなら mt_mine.c だけオプション分離しないと、
オリジナルの速度とかテストベンチにまで影響が…

SPUのアセンブリ言語はちょっとだけ読めるけどあれだけのコードをまともに書ける気がしない。
うまく飼いならせばspu-gcc43こそ最強の高級アセンブラ

未だに 4.3 は飼いならし方がわからんす。attribute とかじゃないんすよね？

って、コンテスト前なんだから聞いてる場合じゃないかｗ
おいらは asm 行くけど、やり方が気になって気になって。
ちなみに 4.1 なら >>383 の率超えました!! 意味ないけどｗ

>>441
>>383は超えたところで意味が無い数字だぞ。
実は>>389もだけど

なんでそういうの黙ってられないんだろう。

俺SUGEEEEEEEEEE だからじゃん？ｗ

せめて締め切られてからにしたらどうかね。

締切後フカシだった事がばれて「俺参加してねーし」とか言いそうな感じ

ここらで擁護がきそうな感じ

いやいい加減うざいと思ってただろみんな

Cellプログラミングに関係してるだけマシだと思ってたんだけど、
ウザかった？
他になんか話題ある？

糞団子に餌を与えるのはいかがなものか。もそもそ。