[RISC]CPUアーキテクチャについて語れ！[VLIW]２

RISCでimmediateに制限が発生するのは仕方が無い。しかもISAをコンパクトにすれば当然だ。
団子は下らん事を書いてオナニーする癖がどうにも直らんな。

>>854
ええっ

今気づいた。
4.2GFlopsって4要素・4要素の積和算で7オペレーション分だから単純にクロックのちょうど7倍ってことか。
なるほど。激しくクロックがあげられない気がするのは俺だけ？

しかしSSE3の水平加算ってやたら使い勝手悪いのな。
同等の演算を、巧くソフトパイプライニングして1DQWORDあたり10クロック程度？
参考 ftp://download.intel.com/design/Pentium4/manuals/24896612.pdf

どうみても低速です。本当にありがとうございました。

>>857
ベクトル化が上手く填まるようなコードでは、もはや演算速度は問題じゃないでしょ。
スループットはメモリ帯域だけで決まるといって良い。

>>857
実はSH4はドリキャスの時代からクロックの７倍Flopsと主張してる。
クロックの向上に伴ってメモリも高速化してるので実性能が出ないことはないと思うが。

D$にのっかるデータだけをこねくり回すならそこそこ出るよ。

>>854
SH4はもともと128birの2Dグラフィックコア内蔵してて
ドリキャスはそれと別にPowerVR2を搭載してたんだよん。
それで128bit機を名乗っていたのはどうかと思うけどな。

STMicroとの合弁だったからそっち由来のコアかもしれんね。

ソフトパイプラインなんてやってられるか！
MMXや3DNow!でもできる積和をクロックアップのためだけに排除しているSSEは
イヤガラセでしかない

SH778xは2D/3Dアクセラレータ載ってない。
SH7770とかSH-MobileにはPowerVRが入ってる。

>>862
＞クロックアップのためだけ
それだけで十分な理由だと思いますが何か？（漏れそれが(・∀・)ｲｲ!!ﾄﾚｰﾄﾞｵﾌかどうかはわからないけど）



＞イヤガラセでしかない
は、もっと不条理な仕様のための言葉かと

無用に演算コストの大きい命令サポートすると高クロック化が難しくなるってのはPowerPCとか見てればわかるかと。
でもMPC7450シリーズはすごくいい石だよな。バス帯域が狭いけど。

>>857
> 激しくクロックがあげられない気がするのは俺だけ？

なんで?

レイテンシが1ではないよ。
スループットが1だよ。

クロックを上げるのを阻害するのは、
1ステージの長さですよ。

>>866
ステージ細分化（レイテンシ増大）すれば上げられるのは解ってるよ。PPC970がそうやってるし。

Dreamcastってたしか200MHzだったけど、x86ではDeschutesの450MHzや初代Xeonがハイエンドの頃だろ。
SHのクロックが3倍伸びる間にx86は5倍以上伸びてる。
熱設計の制限のきつい組み込み向けと比べるのは酷かもしれんが、
Pentium MならPentium II/IIIと消費電力そんなに変わらない（むしろ落ちてる？）のに
2.26GHzまで出てること考えれば、SHの進化って鈍いんじゃね？

>>867
SHの展開が遅いのは別に今に始まった事じゃないから。
まあ会社の合併やら大変なんだろうなとは思うが。

SSE3の水平加算はK8のほうが性能いいな
Yonahで改善されたか気になるな

PenMはそもそもSSE3サポートしてませんから。
ところでアレ水平加算って言えるの？Intelの開発マニュアル読むにDWORD単位で転置してからaddしてるだけじゃないかと。
PenMはレイテンシの小ささがイイ感じだけど、浮動小数は実クロックが命かと。
MMX＞SSE2整数がSSE2整数≧MMXくらいになってると思っている。

どっかで見つけた4要素積和算

SSE2
mulps xmm0, xmm1
movaps xmm1, xmm0
shufps xmm0, xmm1, 0xb1
addps xmm0, xmm1
movaps xmm1, xmm0
shufps xmm0, xmm0, 0x0a
addps xmm0, xmm1

↓
SSE3
mulps xmm0, xmm1
haddps xmm0, xmm0
haddps xmm0, xmm0

普通に計算したら依存関係のチェインで33クロックかかる。並列実行でようやく元が取れる。
てかレジスタ8本しか無いのがきつい。

>>869
K8では下のコードで15クロックらしい。実クロックの差加味してもK8のが上だな。

続き。どうみても3D NOW!のが高速です。
とっさに思いついた4要素×4要素の積和算2セット同時実行。

pfmul mm0, mm4 -並列実行可能
pfmul mm1, mm5 ┘
pfmul mm2, mm6 ┘
pfmul mm3, mm7 ┘

pfadd mm0, mm1 -並列実行可能
pfadd mm2, mm3 ┘

pfacc mm0, mm2

最後にmm0の上下に2セット分のデータが入る。pfaccってすごいリッチな命令だな。

レジスタ全部使ってるけど、メモリからロードしてもレイテンシは十分隠蔽可能なので
まだまだ並列化の余地は十分ある。

※K8ではmulpsはマイクロアーキレベルでは上下に分けてpfmul×２発行してるだけの実装。
しかもデコーダの負担はxmmベース1命令＝mmベース2命令
mmレジスタのほうが小回りがききやすい→MMX/3D NOW!のほうが速い

小さい計算だけで比較して命令の優劣を語るバカ

大きい計算やってもSSEはうんこ

SSEはユニットが128bit化されてから価値が出てくる。それまではMMXや3D NOW!のが速くても已む無し。
つかK8の整数/単精度浮動小数でSSE＞MMX/3DNOW!になるケースってほぼ皆無じゃね？

Pentium 4はL/Sだけは128bit化されてるからロード/ストア回数が多い演算に限ってはMMXよりSSE2整数のが有利。

じゃあ
プレス子のSSE3で4要素×4要素の積和算4つな

mulps xmm0, xmm1
mulps xmm2, xmm3
mulps xmm4, xmm5
mulps xmm6, xmm7
haddps xmm0, xmm2
haddps xmm4, xmm6
haddps xmm0, xmm4

データシートどおりなら多分これで40clkくらい。
レジスタ無駄遣い辞めて8並列くらいやればもっとスループット上げられるかも。

>>867
当時は200MHzがそもそも無理したクロックなので、166MHz版と比較してやってくれ。

>>867
消費電力やプロセス、パイプラインの段数を考えればSH4はそんなもんじゃないのかな？

組み込みだから割込応答を考えるとパイプライン段数は増やせないし、熱設計を考えれば
プロセスを細かくした分を純粋に周波数アップにも使えないだろうし。

SHはSH3で機能が固まっちゃって、
夢カスあたりで性能向上を諦めた感があるね。
ペルソナだってHandheldPC/Proで止めてるから
デモ機用の性能が不必要になったと言うべきか。

そりゃ、HandheldPC2000なペルソナは見たかったけど(w

ところでここ、PC以外もあり？

もっと有体に言えば非ノイマンOK？

個人的には論理回路とかついてればビー玉だろうがOKだと思っている。
ttp://japanese.engadget.com/2006/01/25/marble-logic/

>>867
> 熱設計の制限のきつい組み込み向けと比べるのは酷かもしれんが、

そうなんだよなあ、、、そういえばサターンにも空冷ファンの準備工事が
してあったような気がするけど、結局ファンは実装されてなかった。

それが今は、Xbox360という、ゲームができてDVDも見ることが
できる電気温風器とか許されるもんなあ。夏が楽しみだ。

SH4に32ビット命令長モードを組み込む予定は無いのか

>>884
それがSH5な訳なんだが、いつまでたってもモノが出てこない。
だいたい、せっかくSH4があっても売れ筋はSH3っぽいし、
ARMも売れ筋はARM7系みたいだし、あんまり高性能な路線はニーズが無いっぽい。

もしかしてSH5はSH4より性能低いんじゃないか？
SH5ってクロックどのくらい？

>>876
その計算は40clkかかるかもしれないけど、
実際は他の処理や次の積和算と並列実行できるから
実質もっと短く済むとオモ。

>>886
SH5は会社ごとお星さまになりますた。
合掌。

>>887
衝突判定の場合なんかは１個ずつやるしかないわけで
素直なデータ配置のままシンプルな命令でやれる方がありがたい
エライ人にはどうでもいいことだけど

Altivecも整数でしか水平加算ができないけどa*b+cをスループット１でできるから
クロックあたりの能力はSSEの倍、、、でも使われない

クロックで決めようとする＞＞８８６は中学生

SH5はシングルスケーラだから同じクロックだったらSH4より遅いと思う。
SH3→SH4のようにSH5→SH6でスーパースケーラになるはずだったんだけど...まぁそういうわけだ。

>>890
いや、８９１のような事をふまえた上で
昔の予定では初期のSH5が700Mhzだったなぁと思いだしてSH4の方が、思った。

まぁ水子のクロックを語ってもむなしいだけだけどねぇ...。

ソフトウェアの互換性を考えれば、
新規追加された命令が128ビット幅なのに、64ビット幅の演算器を2回まわす実装
というのは正しい選択なんですよ。


新しい命令を追加しました。
この命令を使うとスピードアップしますが、
世の中で使われているPCの1%しか、この命令に対応したCPUを積んでいません。

というのでは、お話にならないが、

新しい演算器を追加しました。
このCPUを使うとスピードアップしますし、
世の中で使われているPCの80%が、すでにこの命令に対応したCPUを積んでいます。

というのはｳﾏｰでしょ。

いやそれ因果律遡ってる

ソフトウェアの互換性と演算器の実装は関係ないですよ

ロードした後途方に暮れるようなパズルアーキテクチャだし
３割くらいしかスピードアップしないし
面倒だから今でもFPU
高クロックとメモリ帯域のギャップのおかげで単純な処理なら差なし

>>887
確かにそうだし、OoOの動きを読みまくってアンロール・スケジューリングすれば
今の演算の繰り返しだけでも更に倍近いスループットを稼げると思う。
ただし演算ユニットがいっぱいあってもポートが共有してるから実際にはそんなに性能良くないような。

>>889
VPERM系オペレーション＋垂直加算でよくね？
確かにvmadd*はどう使えばいいか逆に困るよね。

何で富士通が作ってるSPARC64の話が出てこないの？
国産CPUの中では高性能だと思うけどな

互換という現実路線で夢がないから。
独自アーキテクチャーのSH4が人気なのもこの理由。
……もちろん実生活では夢でMPUを語っちゃダメだぞ。

というより触れる機会があまりないからでないかな。

SPARC64積んだマシンってでかくてごついやつばっかりだもの。
中古でもあまり出てこないし。

>>895
演算器の強化と新命令の追加を一度にやるのではなく、
将来を見越して早めに新命令を追加しておくのですよ。

いますぐには64ビットは必要ないけど、
64ビット対応のCPUを売るのと同じですよ。

>>902
意味不明なんだが？
命令追加を隠して入れておいて、演算器を追加したときに公開するって話？
何で隠すのわざわざ？
後で公開するっていうならあらかじめバリデーションしておかないといけないよね。
当面使わない命令のバリデーションをやるのは無駄っぽいけど。

命令追加したときに公開するならやっぱり
＞世の中で使われているPCの1%しか、この命令に対応したCPUを積んでいません。
と変わらないんじゃないの？

>>899
というかそれより上は現行国産CPUだとSX8の中のベクトルプロセッサだけのような