CPUアーキテクチャについて語れ 20

おいお前らいい加減、無能なAMD房・Intel房・GKに振りまわされず、
エンコ時間がどうとかPIがどうとかPS3がどうとかじゃなく、
CPUコアのアーキテクチャについて語りましょう。

x86/RISC/CISC/スーパースカラ/VLIW/MIMD/SIMD
等について語ってもよし、
各SPUの汎用レジスタ128本のCell B.E.マンセー、
x86なワンチップスパコンのLarrabeeマンセー、
時代はGPGPUだ！、Sunは漢の浪漫！、龍芯(笑)、
昔々8086の時代は(以下略・・・等もよし。

さあ、不毛な争いを止めてCPUアーキテクチャについて語ろう！

前スレ
CPUアーキテクチャについて語れ 19
http://hibari.2ch.net/test/read.cgi/jisaku/1305200489/

>>1のつ

パッケージはDIPで頼むわ
1000ピン超のDual inline packageは今にも動き出しそうでかっこいいぞ

>>1乙。

ヘテロジニアスマルチコアマンセー。

Qualcomm's New Snapdragon S4: MSM8960 & Krait Architecture Explored
http://www.anandtech.com/show/4940/qualcomm-new-snapdragon-s4-msm8960-krait-architecture

492: Socket774 [sage] 2011/10/12(水) 15:24:37.43 ID:rgns2cVw (8)
国内レビュー

AMD FXシリーズ最上位「FX-8150」ベンチマーク
http://pc.watch.impress.co.jp/docs/topic/feature/20111012_483000.html
遂に姿を現した8コアCPU「AMD FX」はCPUの覇権を握れるか？
http://ascii.jp/elem/000/000/641/641601/
Bulldozerは気難しい──AMDの新CPUアーキテクチャ“Zambezi”を試す
http://plusd.itmedia.co.jp/pcuser/articles/1110/12/news041.html
「FX-8150」レビュー（前編）。ついに発進するBulldozer世代のCPU「Zambezi」はゲーマーの福音となるか
http://www.4gamer.net/games/100/G010000/20111012001/
Bulldozer世代の8コアCPU「AMD FX」"Zambezi"徹底攻略 - 性能ベンチマーク編
http://journal.mycom.co.jp/special/2011/zambezi/index.html

デニス・リッチー死去・・・

この記事を読んでて今更気付いたんだけどBulldozerのトランジスタ数が20億っておかしくない？

ttp://www.xbitlabs.com/news/cpu/display/20111013232215_Ex_AMD_Engineer_Explains_Bulldozer_Fiasco.html
>AMD publicly said that each Bulldozer dual-core CPU module with 2MB unified L2 cache contains 213 million transistors and is 30.9mm2 large.
(中略)
>As a result, all four CPU modules with L2 cache within Zambezi/Orochi processor consist of 852 million of transistors and take 123.6mm2 of die space.
>Assuming that 8MB of L3 cache (6 bits per cell) consist of 405 million of transistors,
> it leaves around whopping 800 million of transistors to various input/output interfaces, dual-channel DDR3 memory controller as well as various logic and routing inside the chip.

Tukwilaの総トランジスタ数が約20億なんだけど、そのうちの大部分に当たる14.2億は24MBのL3キャッシュに費やされてるんだよね。
一般にアンコアと呼ばれる部分(12ポートのクロスバ、2MBのディレクトリキャッシュ、QPIとFBDのI/Fとコントローラー)のトランジスタ数はわずか1.95億しかない。
粗っぽく仕様を比較するとこんな感じで、明らかにTukwilaのアンコアはBulldozerよりリッチなのでBulldozerがTukwilaの4倍以上もここにトランジスタを費やしてるとは思えないんだが。
Bulldozer … 4M, On-Chip-Memory 16MB(L3$ 8MB), HT 4ch, DDR3 2ch
Tukwila … 4C, On-Chip-Memory 30MB(L3$ 24MB) QPI full*4 + half*2, FBD 4ch,, Directory Cache 1MB*2

あ、ごめん。記事をちゃんと読まずに脊髄反射で書きこみした。xbitもBulldozerの20億は多すぎるって言ってるのね。(そこから設計に不備がある可能性を指摘。)

なんか面白い話が出てきたな
http://northwood.blog60.fc2.com/blog-entry-5351.html
Bulldozerが遅いのは手作業をやめて自動設計ツールに頼ったのが原因らしい

xbitの作文をスルーして読んだらアンコアが悪いとか、どうもそういう単純な話じゃなさそうだな。
AMDが本格的にファブレス企業へなってしまったような印象を受けた。
ttp://www.insideris.com/amd-spreads-propaganda-ex-employee-speaks-out/
Bulldzerは紙(企画書？)の上では素晴らしいチップだった。俺はBulldozerの物理設計が始まる前〜物理設計中の時期にAMDで働いてたんだ。
俺に言えるのはBulldozerはそれ自体の魅力も薄ければIntelに対する競争力も無いってこと。
(何故なら俺はAMDの設計手法が全く駄目だと確信しているから。)
俺がAMDで働いてた頃、Bulldozerに何が起きたかは語りたくもないんだが…

何が起きたかって言うと、経営陣はクロスエンジニアリングを決定したんだ。
これは手作業でのCPUの設計を止めてSoCの設計手法へ移行しろってことだった。
この結果、パフォーマンスやダイサイズや効率性について色々諦めなきゃならなかった。　(DECのところ省略)
今までIntelとAMDは少なくともクリティカルな部分については常に手作業で設計してきた。
だがそれは俺の退社前には変わっちまった。AMDは論理合成、フロアプラン、配線等の自動化ツールに頼り始めてたんだ。
俺はAMDを辞める前の数年間は設計フローの部署に居た。
そこでツールベンダの要望に応えて自動化ツールを使った加算器や乗算器などの試験的なデザインをしたよ。
ツールのパフォーマンスを引き出すために色々な手を講じたけど、毎度ツールから産まれる機能ブロックは、
手作業で設計したものと比べて2割大きくて2割遅い上にエレクトロマイグレーション等の問題を抱えた代物だった。

これが今のAMDの設計手法さ。さぞかし立派な物が出来るに違いないね。

CPUアーキテクチャについて語れ 16
http://pc11.2ch.net/test/read.cgi/jisaku/1253517890/

587 名前：MACオタ[sage] 投稿日：2010/02/14(日) 03:24:04 ID:Wj71GeXX [1/17]
(略)
- The only bad thing is that some guys I know at AMD say that Bulldozer is
　not really all that great a product, but is shipping just because AMD
　needs a model refresh. "Sometimes you just gotta ship what you got."
　でもなぁ… AMDのツレが言うにはAMDは製品サイクルに切迫して製品化
　してくるらしいんだよな。「何でもいいから今出来てるのを出さなきゃいけない
　時もあるんだよ」って。


ここら辺のことって自動配線の話だったのかな

まあベンチ結果があれだし
製造技術で差をつけられてるのに設計まで放棄したら
馬鹿でも結果が分かる
とはいえGPU統合まで考えるとまだまだAMDは捨てたもんじゃないが

ほうほう、なかなか興味深い
設計で手抜きとは…こっから手作業で取り戻せるのかね

意図的に手を抜いたならまだいい。
クリティカルな部分すら自動化ツールに頼らなければならない状況になってなければいいが。

Hot Chips 22 - AMDの小型、低電力CPUコア「Bobcat」
ttp://journal.mycom.co.jp/articles/2010/09/02/hot_chips22_bobcat/index.html
>Bobcatの設計ターゲットの第一は電力、チップ面積が小さいこと、2番目が高い性能であるが、その次にカスタム設計のメモリなどの種類数を少なくして、
>プロセサコアの大部分を論理合成で作れるようにすること、そしてプロセスが変わっても容易に移行できることが挙げられている。
>
>Bobcatコアを使用する最初の製品である「Ontario」はTSMCの40nmプロセスを使うと見られているが、関係の深いGLOBALFOUNDRIESのプロセスへの移行も視野に入っていると思われる。

そしてAMDがBulldozerの後継コア(Piledriver)をTSMCでも生産するという噂が…
ttp://www.techpowerup.com/153567/AMD-to-Turn-to-TSMC-for-Bulldozer-Manufacturing.html

K10あたりからあのクラスのCPUは本格的にAMDの開発リソースでは手に余るようになってきてるんだろうな

やっぱりK10のデコーダとかロードストアとかキャッシュ周りを順当に改良していった方が
良かった気がするんだがそれじゃ駄目なんかね？

K10ってノースブリッジのクロック上げるだけで性能豹変するらしいし
まだいけそうな気がするんだけどなぁ

xbit記事の手作業or自動設計という対立軸はどうなんだ？
ふつー自動設計ツール＆人力カスタムで造り上げていくもんだろ。

長年のノウハウがあるTSMCと比べてGFから提供される
各種デザインキットがショボかった可能性はありそうだが・・・。

>>17
失敗したのを確認してから出てくるような自称5年前までの元社員の投稿に
どれほど意味があるのかは、まあ読み手次第だが。

>>17
この人がAMDに勤めていたと思われる時期はまだFabが売却されてGFになってないのでGFのデザインキットは無関係。
ツールを購入してテストしていたというくだりからするとAMDは社内製ツールをある程度諦めたっぽい。

>>18
記事になったのは2日前だけど投稿自体は1年以上前のものだった。
ttp://forums.macrumors.com/showpost.php?p=9745462&postcount=612
Bobcatも同様な設計をされていることは知らなかったみたいだね。

ふつうは守秘義務で退職後5年間は口外してはいけないことになっている

http://www.theinquirer.net/inquirer/news/2116600/intel-8nm-wont-exascale
このままのやり方では2018年に8nmまで行ってもエクサスケールのスパコンは出来ませんよ

http://www.theregister.co.uk/2011/10/14/intel_predicts_continued_life_for_moores_law/
ハイパフォーマンス向けCPUの上にDRAMを積層させるとCPUの熱でDRAMはまともに動きませんよ
(つまりDRAMは別に積層させ、それとCPUを繋ぐHMCのようなものが必要ですよってこと？)

> Bobcatも同様な設計をされていることは知らなかったみたいだね。
Atomより小さいのに性能がいいとかいいたいんだろうけど
CPUコア自体はAtomのほうが遙かに電力効率はいいんだぜ

N/Dシリーズが残念なのはチップセットがAtomに最適化されていないから。

>>21
後藤さんはIntelはDRAMの上にCPUを載せる方向を考えているって書いてたよ

追加
AMDのデザイナーであるJerry Moenchが2004年のVLSIで「リソースの少ないAMDは自動化ツールに頼る必要があるのでK8とK9の配線層数は非常に多くなる。」という発言をしていたらしい。
ttp://arstechnica.com/civis/viewtopic.php?p=10607812#p10607812

>>22
AMDのトレンドがそうなりつつあったのかなと思っただけでそれ以外の意図はない。

Bulldozerは11層
Bobcatは10層
>>24の話は今回の件に関しては関係無くね
昔からIntelの方が配線層は1,2層少なかったからそのことだと思うけど

そして昔からIntelのキャッシュは速かった。

えっ？ｗ

同じ自動化でもBobcatの方は目に見えるようなアンコアの無駄がないから
AMDから引き継いだGFの設計ツールの方がTSMCのより劣っているじゃないのか？

ボブはデュアルだから4M8Cのブルと比べてもな

アイドル見る限りGFの32nmは優秀っぽいからそこだけ救いかね
まぁ歩留まりはいつものAMDみたいだが

K8のデュアルの頃から同じアンコアの無駄あるから

>>23
後藤さんのIDFレポートで、CPUの上に載せる構想はフェイクだったと言ってる。

http://pc.watch.impress.co.jp/docs/news/event/20110920_478686.html
----
Intelは、これまでDRAMスタックの上にCPUを載せた構想図を示してきたが、それはフェイクで、
実際にはキューブメモリの共同開発を進めていたことがIDFで明らかになった。

つーことは>>21の方針ということだね。

>>31
スカイネット…

>>31
インテルが忍者プログラマなどと言うかww
http://pc.watch.impress.co.jp/img/pcw/docs/478/686/16.jpg

>>34
これ、何度見ても吹くｗ

マイクロソフト、次世代機「Xbox Next」を2013年ホリデーシーズンに投入か
http://www.inside-games.jp/article/2011/10/21/52256.html

ソニー、プレイステーション4向けのプロジェクトを複数の内部スタジオで開始か
http://www.inside-games.jp/article/2011/10/21/52257.html

当然研究開発はするでしょう。PS3は10年もたせると言っていたから、
新箱が2013年末ローンチなら、PS4は1年後の2014年末ローンチでその位だが…

The Cell processor 2 is in development, and go for PlayStation 4
http://translate.google.es/translate?sl=es&tl=en&js=n&prev=_t&hl=es&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fwww.anaitgames.com%2Fnoticias%2Fchip-cell-2-playstation-4

Cell 2　そんなものが存在するのだろうか・・・

まあSPEを乗せないと話にならん

PS4はPS2の機能を最実装して欲しいよ。

エミュでいいと思うが、任天堂が特許とってたな…。

2014年までひっぱるならSPEもソフトエミュでの再現が視野に入ってくるのでは？

ゲハが来ると如実にレベルが下がるな

CellはGPUと違って好きに叩かせてるらしいから
互換を優先するなら載せてくるだろうけど
PS3のように敢えて載せず、PS2を16000円で売るような事もやるだろう
まあ投資額としてはPS4にも載せるつもりだったと思うけど

今頃何言ってるんだっていわれそうだが、時分割で高速に切り替えて
実効的に回路規模数倍相当になるFPGAを売ってるベンチャーがあるんだな

ttp://www.kumikomi.net/archives/2010/06/co13de13.php
ttp://eetimes.jp/ee/articles/1110/18/news125.html

すげーな、これ。

ARM+SPEでPS3のゲームを動かすときだけARMでPPEをエミュでもすりゃいいんじゃないかと
暴論

手堅い
いまどき新PPEを作ったりSPEを他コアでエミュるよりは

どこが手堅いんだかさっぱりわからん
WiiUや次期XboxもPowerだしSPEつけるならPS3との互換性捨ててARMにする意味が全く無い

WiiUは45nmで低消費電力志向だと判ってるから
現行世代のスループットをターゲットにしたコアだろ？
MSはAMDのSoCになるらしいからPowerじゃないんじゃないか？

ARMなら効率も設計自由度もコストも市場環境的にも優位
最新技術をキャッチアップしたいならARMを使うのも手堅い

これからIBM自体がARMに走ってもそれほど驚かないくらい

>>50
現行世代並みのスループット

ARMは魔法のアイテムじゃないぞ

もちろん
だがIBMも魔法使いじゃないしな

>>50
現行の箱もAMDが統合設計したCPU＋GPU1チップコアだし
GFはIBMのプロセスグループだからPowerコアの設計変えずにSoC化するのに有利だろ

次世代箱はFSAでプログラミングするんだろうか。

Cell2ではPPEはお払い箱になってARMに変わるのは決定済みだよ。
ttp://blog.esuteru.com/archives/2510625.html

ARMはIBMと共同開発しているから、IBMにとっては技術の横展だね。
IBMにとってCellでの用途開発で苦しんだのは黄犬Linuxが絶滅種寸前だった
からで、ARMでWindows8が走ると用途が広がるからね。SPE自体のコンパイラは
IBM謹製でお手の物だし、ARM/SPEのマルチCPUはすごい事になりそう…
あと、CPUチップ内でのARMのバスとIBMのバスは接続技術を開発済みだよ。
ARM/SPEの構成ならARM用とIBM用の各周辺回路のどちらでも使えるみたい。

おお、そうなのか。

>>57
乞食クズブログのURL貼るなボケ

その内容だとcell2じゃなくて
armの何かだろ

ARM+SPEだけど・・・読めない人はどう読んでんだ？

>>60
医療とか防衛とかスパコン用にはPPEは全然役に立ってなくて、SPEの命令役
だったからね。ARMもその位置だが、Cellの時はPPEの動かし方がうまくいかず、
intelチップでWindowsを動かし、そこからPPEに命令を出し、PPEがSPEに命令
する形だったし。
面倒くさいからMercuryもCellをやめたみたいだけど…
http://www.mc.com/cell/

非力すぎて使えないPPEをもっと非力なARMで置き換えるのか

もうPS3除いてCell事業は終息してるし、ゲーム機も2014年まで先延ばしなら
ゼロベースで考えたほうが良い。少なくともSPEは互換のためだけで拡張すべきではない。

どこにARM+SPEってかいてる？

ARM+SPUとか意味ねーから。
ゲハは自分の無知をまず認識しろ

Cortex-A7　こっちが面白そうだ
ttp://pc.watch.impress.co.jp/docs/column/kaigai/20111028_487030.html

64bitの新命令セットARMv8きたがな

ARMv8は2012、3年頃にチップが登場して
2013、4年頃には搭載された製品か

新市場開拓なら名称もCortexから変わりそうだな

これか。もう最初のモデルとコンパイラが出回っているのか。
http://www.electronista.com/articles/11/10/27/arm.explains.armv8.chip.architecture/

そろそろメモリが4GB超えるから移行しただけじゃね
ARMで変わるならOpenSPARCで変わってただろ

ARM始まったな。

PowerコアはWiiUで終わりなのか　さびしいのう

http://www.arm.com/files/downloads/ARMv8_Architecture.pdf
命令長は32bit固定で、レジスタフィールドは5bitか

へーレジスタ増やすんだ
普通のRISCになったな

NEONは従来の128bitx16 or 64bitx32ではなくて
下位ビットのみ共有して128bit or 64bit x32になるということね

☆ARMの次世代core, SoCについて語るスレ #001☆
http://hibari.2ch.net/test/read.cgi/jisaku/1319938708/

とりあえず建てといた。

ARMv8
ttp://pc.watch.impress.co.jp/docs/news/event/20111031_487621.html

命令長32Bitとな

別に普通じゃね
PPCもMIPSもSPARCも命令長32bitだ

条件実行フィールド削る分でレジスタフィールド拡大するんだろうな

>>78
>AMCCの発表によると、「X-Gene」の最大動作周波数は3GHz、待機時消費電力は300mW未満。
300mW未満に笑った。これはプロセッサコアのIdle powerを単純にコア数倍してるだけだね。
サーバープロセッサのIdle powerはほとんどがコア以外の成分だからこんなに減らせない。
1コアのIdle powerを約10mWとすると32コアくらい積んでくる予定かな？

理研と富士通のスパコン「京」、10ペタフロップスを達成
http://www.rbbtoday.com/article/2011/11/02/82634.html

>>82
http://pr.fujitsu.com/jp/news/2011/11/2-1.html

CPUが増えて速度が上がっているのに実行時間が前回よりも長いということは、
前回よりもサイズの大きい計算をしたんだな。

紆余曲折有ったけどよくやったな
次の世代はどうなるのかな

ありません

スーパースカラとマルチコアは、どっちもパイプラインを複数用意してますが
「パイプライン」≠「コア」ならコアは具体的にどの部分を指してるんですか？
制御部のことかなって思いましたが、スーパースカラも各々のパイプラインを制御する
制御部は必要だと思うので違う気がしました。

>>86
一番簡単な考え方はこんなもんか？

スーパースカラー …… ステージを分割しユニットを複数実装することで「１つのスレッド」を並列実行するための技術
マルチコア …… 入力から出力までの１単位であるコアを複数実装し「複数のスレッド」を独立して並列実行するための技術
SMT（HTT） …… スーパースカラーを拡張することで「複数のスレッド」を並列実行しているかのように見せる技術

パイプラインとコアの違いは直列か並列かと処理できる能力の違いだね。
パイプラインはベルトコンベアで作業する人間１人で、コアはそのコンベア１本って感じ。

>>87
なるほど、スレッドの数の違いですか。
並列処理のハザード検出とか大変だろうな（多少は必要でしょうけど）
と思ってたのですが、別々のスレッドならそれほど心配しなくてもよさそうですね。
とてもわかりやすい説明有難うございますm(_ _)m

AMD、大規模なリストラを実施

http://pc.watch.impress.co.jp/docs/news/20111104_488639.html

さようならAMD

うわぁ･･･

一つの時代が終わったな。今後はIntel対ARMが本格化するのだろうか。
生産に関してはどうか。AMDを主要顧客としていたGFはどうするのだろうか。

>>91
逆に危機感を持って本気出して来るってことは考えられないかな?頑張って欲しいな

求人する>有能さを見極める>リストラする　というサイクルを
回して有能な人間の濃度を高めているだけなのでは

>>93
社会に出てみるのをオススメしておく

日本企業と米国企業でリストラの意味がだいぶ違うことを社会人なら知っておくべきｗ

リストラは首切りを意味する和製語なんだよ！！なんだｔｔ

またの名は構造改革

業績好調なのに大量首切りやった会社は例外なく落ちぶれてる。

え、今は落ちぶれてないの？

大量首切りなんて業績好調な大企業なんて普通にやってんだろ。
新卒3000人採用、数ヶ月後2000人削減

例外なく落ちぶれるｗｗ
Intelだってリストラやったことあるけどね

新CEOが就任して注力する部分が決まったからそれ以外の贅肉はそぎ落とすということでしょ
そぎ落とす部分が本当にいらないのかどうかは分からんけどね
2月のAnalyst Dayで方向性は見えてくるんじゃない

インテルが1万人レイオフを行ったときは
Core2で挽回し始めていて、その裏でNehalemアーキ開発も進んでいた

今のAMDは……

空っぽだな

10%って何人なんだろうね

10年度の時点で16000人か。ということは1600人。
何か撤退する分野があってそこを切るのか？

centaurが16社できるぞ

AMDの製品ラインの中で、現在から将来に渡ってダメなのは
どうみてもBulldozerなんだが、
ここ手放すと終焉が見える。

>>102
Intelのリストラが話として出てきたのは2004年じゃないか？ちょっと記憶が怪しいが。C2Dの前なのは確か。
ただしエンジニア(R&D)は減らさず逆に増強されたはず。
あの頃はOpteronにやられてたから価格競争に耐えられるような組織作りを迫られてたんだよな。
リストラの実施とPentiumDの価格改定が重なった2006年の第2四半期は大きく業績を落とした。
ただリーマンショックの時には既に組織改革が粗方終わってたので上手く乗り切れたね。

http://www.computerworld.jp/news/trd/48230.html

ごめん、2004年は大嘘。
Intelが2006年の第1四半期に前年同期比で4割ほど減益だったのが始まりっぽい。
ttp://www.intel.co.jp/jp/intel/pr/press2006/060420a.htm

決算の発表から一週間後に投資家へリストラによる経営体質の改善を約束。
ttp://news.cnet.com/Intel-to-get-widespread-restructuring/2100-1014_3-6065708.html
>The comprehensive project, which will look at ways to cut costs per unit and improve employee productivity, will take place over the next 90 days, he said.
(略)
>In an effort to overcome its loss of market share amid a slower-growing overall market, Intel plans to launch its largest product refresh in years.
>
>"New products based on the Core microarchitecture for power and performance will be launched this summer and refresh the Intel product line in all segments," Otellini said.
>
>Three new chips, one for each of the Core market segments, will be part of the rollout: Woodcrest for servers in June, Conroe for desktops in July, and Merom for notebooks in August.

文脈的にはCMAを採用した製品を6〜8月に前倒しで投入するというのもリストラクチャリングの一環。

6月にはMarvellへXScaleを売却。
ttp://news.cnet.com/Intel-sells-off-communications-chip-unit/2100-1006_3-6088305.html

2006年第2四半期の、前四半期より更に低調な決算を発表した翌日(7/20)には役員人事。
ttp://pc.watch.impress.co.jp/docs/2006/0721/hot438.htm

世の中には最高益出したと同時に開発者を大量リストラしたスクエニって企業もあるのよ。

あそこは開発を自社で抱えたくないんでしょ

結局どこに事業ドメインをおくかでしょ。

AMDは半導体を外に出しちゃったしATIも一定の成果あげちゃったし
営業にいたってはIntelのパワーゲームに勝てるわけないし

理論設計だけでやってけるか謎だけど、Intel一社になったらx86はマイナー転落だろうな。

スクエニは確かクビ切ったのと同時に新入社員も大量に入れてるな
社長がイエスマン欲しいのか、若手7割にしたら問題解決とか言ってたし

AMDは厳しそうだな・・・ATI買収しといて良かったね
ってくらいか
単体ならまず死んでる

>>114
スクエニは組織を新しくしたいのか。
毛色の違う会社になるのかも。

コンピュータの高性能化が終わったら科学技術の進歩はどうなるんだ？

AMDが終わっても、アーキテクチャ間の競争は終わらない。

AMDの存在はコンピュータの歴史全体から見ると
あってもなくてもたいしてかわらん程度の影響度でしかない。
ARMの方がはるかにでかいよね。

>>118
結局はx86互換メーカーの1つでしかないから、AMD
ところで、未だに？オクでSUNのSparc機が出たりしてるが、買った人いる？
俺は、Blade150買ったけど、、たいして役にたってない。

SpecCPU2000辺りだとUltaraSparc3の1.2GhzがPen4-2Ghzぐらいの性能だけど
実際のアプリでの性能差だとどうなんだろ？

コンピュータの歴史全体という視点からなら、AMDがないとIntelは成り立たなかった。

Intelは単なる半導体メモリの製造技術しかなく、一方AMDはCPU周辺回路設計技術があり、
AMDからの技術供与でIntelCPUが成り立った。　ともにフェアチャイルドからの独立組みな。

SUNのSparcが登場したころは、x86は行き詰まり死滅するはずだったが、、
現に、性能では386/486より上で俺は「いつかはSUNやHPのUNIX機を買うぞ」
と思い、十数年、、いざ買ってみると「なんだ、この程度か。」と拍子抜け。
何か普通のPCとは違う世界を味わえるかと思ったが的ハズレだった。

うお、フェアチャイルドがもとだったのか！？
これは目から鱗。

486/Pentium時代は、IntelはRISC勢にぼろ負けしてた
ただしその後、Intelはチップ内部にRISC的な設計思想をかなり取り入れ、
従来のCISCの命令セットの互換を保ったままCPU内部をRISCとCISCのいいとこどりみたいなのに進化させて、
RISCの利点がなくなったけどな

>122
90年代ならAlphaあたりはx86と格の違いを見せ付けてたんだけどな

日本語で一番詳しいのはando さんのところか。他のサイトはもっと頑張らないと
　AMCCのARMv8プロセサX-Gene
　Calxedaのサーバ用4コアARM Cortex-A9チップ
　ttp://www.geocities.jp/andosprocinfo/wadai11/20111105.htm

どちらもモバイルとはインターフェイスのリッチさが違うしECC使えたりで
なんちゃってサバ仕様ではなく本気だなって印象

Andoさんは別格。

andoさんは確か富士通のSPARCアーキテクトで、仕事やめてからも、
大学で非常勤かなんかで講師やってるんじゃなかったっけ？

SPARCに絡んでたのは聞いてたが、アーキテクトだったのか。
すげぇｗ

>>121
なんでこういうデタラメを平気で書く人がAMD周辺からはあとを絶たないんだろうか。
Intelは自社のメモリを拡販するためにプロセッサを作ったのが事の始まり。
AMDはプロセッサは後発参入なんだが。

intelのセカンドソ−スでは

>>125
一つ上の記事が気になった。MIPS系だろうか。

>>129
だよな。AMDはx86の生産委託を受けたって企業ってイメージしか無いわ。

元DECのエンジニアが多いんだったっけ？

>>133
とりあえず今話題にしているAMDプロセッサの黎明期って意味では
DECのエンジニアは関係ない。AM2900の顧客がDECだったとかは関係あるかもしれないが。

ダーク・メイヤーが元DECだったのが印象深くてね。
黎明期はまだDEC色はなかったんだね。

>>129
なんでこういう無知を平気書く人がIntel周辺からは後を絶たないんだろうか。
「プロセッサ」「CPU」ってぇのを半導体で集積回路を起こした「マイクロプロセッサ」だけしか知らないからだろうなｗ

Intelがプロセッサを作ったのは日本のビジコン社から電卓用チップの製造委託を受けたのが事の始まり。
結局Intelだけでは設計できず、ビジコンから嶋さんが設計に入ってようやく完成したのがi4004。
電卓用ではなく汎用にしたらいいんじゃね？的な発想はIntel側から出たが、結局理論設計やったのは嶋さん。

i4004で味をしめたIntelはその後i8008開発したけど失敗、さらにi8080開発しようとしてテンでだめだったから
結局嶋さんをヘッドハントしてようやく完成にこぎつけた。

そもそもIntelが世界で始めて開発したのは「マイクロ」コンピュータであって、おもちゃに毛が生えたものでしかない。
当時は汎用機のCPUが中心で、コアメモリや磁気メモリ中心だったところに半導体メモリに目をつけたのがIntel。
一方のAMDは汎用機のCPUの周辺回路をマイクロチップ化することで事業をスタートした。

AMDは周辺回路のほかに不揮発性メモリの技術もあって、Intelはこれらの技術もライセンス供与を受けている。

>>136
日本人すげーｗ

嶋正利
http://ja.wikipedia.org/wiki/%E5%B6%8B%E6%AD%A3%E5%88%A9

こんなすごい人がいたなんて知らなかった！
CPUなんてものは最初から欧米の人間が設計の中心だと思ってた。

＞嶋は「欧米の人たちと比べても、自分が劣るなどと決して思ったことはありません。
＞機会さえあれば日本人も創造的開発はできます」[7]と述べている。

勇気付けられるね。

×日本人がすごい
○嶋さんがすごい

あと池田敏雄とか
エンジニアリングに国境はない

いやいやいや、日本人も結構スゴイんですよ？

半導体も真空管もリレーも使わずにフェライトコアだけで論理回路を構成するパラメトロンとか日本人の発明ですぜ。
パラメトロン計算機とか上野の博物館で隅に追いやられて忘れ去られてるけど…。

>>136
このスレならそれくらい常識。
ネットで検索して多少はまともなレスができたようだが、
Intel的にはビジコンの件もDRAMを売りたいからむしろマイクロプロセッサがメモリの周辺ICの感覚だったのよ。
で、AMDがなければIntelがなかったという論拠はなんなんだろうか?
セカンドソースって米国と日本のメーカーを含めて何社もあった中のAMDは一つにしかすぎんのだが。

ちなみにIntelの創業者のノイスは世界初の集積回路の発明者で、
マイクロプロセッサ、SRAM、DRAMの発明はTIと並んでIntelが最初。
4004は嶋さん自身も言っているとおり、メインフレームのアーキテクチャの影響は受けてない。

>>139
俺が最初に嶋正利について知ったとき感じたのはこの人のすごさよりも
日本企業のビジネス感覚、人材活用ののしょぼさ、間抜けっぷりへの失望だった。

>>141
> Intel的にはビジコンの件もDRAMを売りたい
i4002はDRAMではない。嘘の上塗り恥ずかしいよ。

>>142
で、どこのだれがi4004がメインフレームのアーキテクチャだなどと主張を？

>>144
横から失礼
それはおまえの認識不足か読み違ってるだけ

AMDの設立って1969年でセカンドソースはじめたのってi8088の1979年くらいからだろ
製品がでる10年も前からセカンドソースの一つってどんだけオーパーツ？

4002
The RAM chip stored four 80-b numbers and additionally the chip had an output port.
The use of three-transistor dynamic memory cells made the RAM chip feasible.

three-transistor dynamic memory cells
誰とはいわないけど。嘘の上塗りってほんとに恥ずかしいですね。わらい。

>>147
セカンドソースはi8085からなのと、i8080のデッドコピーをAMDも作っているから、
その意味ではAMDは1975年くらいから互換プロセッサメーカだった。
ただその当時からAMDはオリジナルCPUだしてるけどね。

で。
i8080はおろかi8085にいたるまでIntelはDRAMコントローラを出すことができなかったし、
i8085に至ってはメモリを接続するのにアドレスとバスを分離するのに自社外のバスコントローラを必要とした。
半導体メモリの拡販のためのプロセッサ開発なんていうのは相当苦しい後付の理由だね。
事実だとしても、Intelは自力じゃ自社のマイクロプロセッサに自社のメモリをつけることができないという
間抜けっぷりをさらしたことになる。

AMD（というかその他の半導体メーカ）はマイクロプロセッサ開発においてはIntelに水を開けられていたのは事実。
嶋さんがZilogに移ってZ80出したおかげでひっくり返されて、IBMが8088/80286採用するまで沈んでたけど。

AMDはバスコントローラやFPU、時代が下ってからは不揮発性メモリなどの技術を押さえ、
この部分でIntelに対しライセンス供与を行っている。

>>148
あら失礼。

4004はテッドホフ=アーキ担当、嶋=実装担当
みたいなイメージなのかな。

もともとコンピュータ史に興味があれば、
IBM > CRAY, Intel, DEC, UNIVAC > Sun, Motorola > AMD
としか思わないはずなので、
ネット見ながら応戦しているのがばればれである。

つうか70年代当時に販売担当上級副社長だったエド・ゲルバッハが「我々は
マイクロプロセッサをメモリ製品の拡販の手段と考えていた」と語っているんで、
そこら辺は常識の範囲だろ。

>>149
そんなに堅く考える必要性ないだろ。
今みたいにIntelに自社の支配力がない時代には、他社と補完路線で商売やってたってだけのような。
セカンドソースは自社で製品安定供給できる製造体制ととのえば、利益ないからやめたくなるんじゃないの?

>>151
> 4004はテッドホフ=アーキ担当、嶋=実装担当
それはさすがに嶋さん怒るな。

> ネット見ながら応戦しているのがばればれである。
というレッテル貼りしたいのがミエミエなわけだけが、
コンセプトメーカしか並べられず半導体メーカを出せていないあたりでニワカってレッテル貼りかえせばいいのかな ;-)

>>153
実際その状況になったのは i80286が安定してからだよね。

Intelはセカンドソーサを何度かつぶしにかかってるけど、AMDはそのたびにしぶとく生き残ってる。
背景の一つにクロスライセンスがあるわけだけど、前に更新したのが2001年だからそろそろ切れるのかもね。

携帯電話が地球シミュレータと同等の演算能力を持つというのか｡
ARM恐るべし

Core 2 Duo はキビキビしすぎて少しでもプログラムが
遅れてタイミングがズレるとにエラーになる事が多い。
WMPみたいに、しぶといプログラムはエラーにならず、
開始するのに時間がかかる。P4の、もっさりの方が快適
なんだが、熱に弱いのがネック。

えるえるって前にトンデモ理論振りかざして
ボコボコにされてたやつじゃねえか・・・

まあ言ってることは間違ってはいない

>>153
×Intelに自社の支配力がない時代
○Intelに自社の開発力がない時代
そう言えばMotoは自社で6800の周辺チップ一通り揃えてたけど
性能や価格面ではダメダメだったのを思い出した

リファレンスを提示するとかが主で、性能や価格を頑張らない
ものってのが昔はあった気がする。
どこもかしこも世知辛い今はもうなさそうだが。
モトローラが該当するかどうかは知らない

富士通、最大23.2PFLOPSを実現するスパコンを発売〜京で用いた技術をさらに発展
http://pc.watch.impress.co.jp/docs/news/20111107_489081.html

40nmで16コアで1.848GHzで110W

IXfx のダイサイズはかなり大きい

IIIVfx 45nm 8Core 513mm2
http://journal.mycom.co.jp/photo/articles/2011/09/05/kei_supercomputer/images/003l.jpg

IXfx 40nm 16Core
http://pc.watch.impress.co.jp/img/pcw/docs/489/081/html/04.jpg.html

消費電力倍かよ。
フル構成時のシステム消費電力凄い
事になりそうだな。

同じ1PFLOPSのシステム同士で比べたら
VIIIfxからIXfxでノード数が半分近くに減るから
インターコネクトチップやらなんやらの分だけ電力は減るだろう

IXfxのダイサイズがかなり恐ろしいことになってそうなのが気になる。
Tukwila も超えて最大級なんじゃないのかな

POEWR7 567mm2
POWER6 341mm2
SPARC64 VIIIfx 513mm2
SPARC64 VII 445mm2
Tukwila 699mm2
Montecito 596mm2
Westmere-EX 513mm2
Nehalem-EX 684mm2
Magny-Cours 346mm2x2 MCM
GTX580 520mm2
Radeon HD6970 389mm2

コピペ情報

SPARC64 IXfx
TMSC 40nm
ダイサイズ 21.9 mm × 22.1 mm
トランジスタ数 約 18 億 7000 万個

SPARC64 VIIIfx
富士通45nm
ダイサイズ 22.7 mm × 22.6 mm
トランジスタ数 約 7 億 6000 万個

富士通先端プロセスェ……

>>154
フェデリコ・ファジンを忘れてもらっては困るでござるよ。彼も嶋さんとザイログ行っちゃったけどね。
ピーナッツでIBMが出した2ndソース要求が元々だけど、MILスペックを取ってたのはAMDだけだったからアタマ一つ飛び抜けてた。

ここで IBM fab club について一言↓

>>158
そんなことあったか?

妄想垂れ流してた漢字コテハンのやつが使ってた
もう一つの名前がえるえるだとおもってたけど違うのか

このあたりかな。1年前の。結構いまみると他のレスよりまともだと思うが。
http://www.varusu.com/thread/jisaku/1274809074/

日本発のCPUアーキテクチャを開発してほしい。
ARMに対抗するようなヤツ。

あるだろw SHとか。

M2090(GF110) 40nm 520mm 177GB/s 6GB TDP225W
　LINPACK 346? GFLOPS/理論値 665GFLOPS = 0.52?
SPARC64 IXfx 40nm 484mm 85GB/s 64GB 110W
　LINPACK 220? GFLOPS/理論値 236.5GFLOPS = 0.93?

GPUもTufuみたいなインターコネクトでつなげば実効効率あがるのかな。
しかしそうするとコスト差が小さくなるはず

震災でルネサスから出荷とまって自動車産業に大打撃与えたのってSHだっけ？

>>164
ワットパフォーマンスは上がるだろ
だから実質的に消費電力が減る

TSMCのプロセスでも1.8GHzぐらいなら出せるんだ

>>178
TSMCと富士通でどっちがクロック出しやすいかはしらないが、
TSMCは40nmで倍のコア数（トランジスタは2倍弱？）の模様。

上の方に書いてあったか。二倍強だ。
28nm移行も、みたいに書いてあったけど28nmはみんなが
TSMCに委託するからバックオーダー抱えまくりじゃん。

SPARC64はハイエンド側に追いやられてどんづまりだと思っていたが、
まさかHPCで生きのこるとは。

IXfx は特化CPU、T4も特化CPU、もし両方生き残れれば
汎用ではないことが生き残りの理由ってことになるのかな

メインストリームから外れた以上、ニッチに特化するのは必要条件、
って当たり前すぎて面白くないけど。
全ては(チップアーキテクチャの優劣とは無関係に)強力なユーザーを捕まえられるかどうか、
そのユーザーが生き残れるかどうか、にかかっていると思う。AlphaはDECとともに倒れた。
RISCのもう一つの雄、ハイエンドには行けなかったMIPSはどうなるかな。

Bladeワークステｰションを買って、Solaris使えばスパコン気分が味わえるはず。

豆腐もつけないと……

>>181
元からハイエンド向けに作られたのがSparc64じゃないの？
端から、PCや携帯なんて考慮してない。

そういやItaniumってまだ息してたっけ？

来年、32nmのが出るので、まだ息はしている。
hpが採用している限り、やめられないだけな気もするけど。

>>183
中国のスマートフォンやHPCはMIPSベースだべ

MACオタが消えると本当に誰も口上に載せないな＞POWER

http://news.mynavi.jp/news/2011/11/08/020/index.html

なお、同社ではGPUコンピューティングやIntelのMICアーキ
テクチャなどについても、

「IntelのKnightシリーズは8SIMD、GPGPUは16SIMDだと思っており、
単に演算器を増やすほうがコアを増やすよりも確かに増やす
トランジスタ数の問題では楽になる。
しかし、もう1つの問題として、超並列演算を低消費電力で
実現するためにはインタコネクトをCPUに内蔵する必要がある。
我々はTofuで、その第一歩を築けた。
我々のほか、こうしたアプローチが現在出来ているのは
IBMがBlue Geneで実現しているだけであることを考えれば、
我々が一番Exaスケールの実現に近いと思っている」

と、2018-2020年ころが目標とされているExaスケールを20MW
程度で実現するのに、最も近いのは富士通であることを強調した。

富士通研、CPUの廃熱を用いた冷却用冷水製造技術を開発
http://news.mynavi.jp/news/2011/11/08/021/index.html

富士通ノリノリですね

理研の建物が既にそうなんじゃないのかという気がする（プレスリリース日がFXと同じだし）んだけど、実際はどうなんだろう。

富士通すげぇな。

富士通はいいから早くJapanistの製品版と64bitドライバをリリースしろ

関係ないけど，大学時代富士通のスパコンでOAKが使えたのには笑った｡

本当に全く関係ないな。

>>178
SPARC T4 は 3GHz だよ

シンプル・低クロック・ローパワー・メニーコアだったNiagaraが
どんどん普通のパフォーマンスコアに近づいていく一方で
またARMで同じ歴史をもう一回繰り返そうとしている件

つまりARMがハイパフォーマンス指向で行き詰まった後RXマイコンの時代が来るというわけだな。

RXのARMに対する優位性がよくわからない。
ルネサスの全面サポートがあるからマイコンにはいいんだろうけど、
それはD/Aコンバータ買ったらおまけで付いてきたコアがたまたまRXだった、みたいな話で、
別におまけはARMでも構わないだろう、と。

Niagaraの失敗を見てもAMDは何も学ばなかったようだな。

>>196
大型コンピューター用のOAKはJEFっていうんだぜ。

Niagaraは失敗じゃないyo!

http://livedoor.blogimg.jp/netamichelin/imgs/3/8/38c2405b.jpg

糞なコアをたくさん積んでも糞は糞でしかない。

>>205
流石のビッグブルー。

>>201
ARMはでかすぎるだろｗｗｗ
携帯電話にPentium 4を載せようって言ってるようなもの。

RXはM16Cの系譜で十分な実績がある。ボタン電池で動くような機器にも使われてるぜ。
とはいっても三菱を中心とした国内家電メーカーのガラパゴスプラットフォームが主戦場なんだけどね。

ARMv8でレジスタ倍増して、コンディションビットが削られて、
なんか普通のRISCになってきた件
実はMIPSで良くね?

MIPSってARMが台頭してから斜陽って印象あるけどいまだに時価総額ではIntelの倍もあるんだよな。

んな馬鹿な

http://finance.yahoo.com/q?s=MIPS
Market Cap: 273.30M

http://finance.yahoo.com/q?s=INTC
Market Cap: 122.51B


MとB読み間違えてた

だんごも人間だなｗ

えっ

lol

http://news.mynavi.jp/articles/2011/10/31/arm8/001.html
> オペコードは32bitで、レジスタ指定ビットは5bitとなる。命令によってはこれに32bitまたは64bitのオペランドが続く。
32/64/96bit可変長? 相変わらずRISCらしくない。Thumb-2もそうだけど。

>>75の資料にはそんなこは書かれていない
ライターの勘違いだろ

x86フォーマットの利点を部分的に取り入れた形だね。
従来のARMのようなリテラルプールからのロードはコストが大きい。
命令フェッチと同時に即値が得られるメリットは大きい。

>>217
まあ単なるリテラルプールかもしれないね

A64はThumbなしでx86のオブジェクトコードサイズに対抗出来るのか?

レジスタフィールドに各5bit使っちゃうとさすがに16bit化はできなそうだよな

ThumbもコンディションビットもARMの差別化要因だったのに、
それを捨てての32レジスタ化はやや疑問

汎用レジスタは31本じゃね？
32本目はゼロレジスタなのか、あるいは特別な意味（たとえば11111＝即値参照）を持つのか
どっちやろね？

ゼロレジスタはあるようだが32本目として実装されてるのかは分からんな。

知らなかったがNECのV800シリーズはリテラルがあるときだけ32bitで通常命令は16bitだったのな
http://www.cqpub.co.jp/dwm/column/mpi/dwm0038mpi7.htm

31か32かは問題ではない

問題あるよ。11111Bがレジスタではない別のオペランドを表現できる可能性があるからね。

いやそれもちょっとは問題だけど、レジスタ指定が4bitか5bitかに比べれば些細な問題だろう

Knights*のSIMDは5ビットになるけどね

IEE７５４形式の単精度型で表現できる数の最大の正の数
正規化された数で最小の正の数、最小の正の数がわかりません
おしえてくださいｍｍ

逆にベクトル演算は32本じゃ足りないのでは?

16x16単精度の行列積でギリギリ足りる程度。

512bit*32本ってSPEの128bit*128本と同じサイズなのか。

更に4つのスレッドごとにあるから4倍だね。
SIMDレジスタだけで1コアあたり8KB。
冷静に考えると凄い量だよな。

多い分だけL1キャッシュ並のレイテンシなんじゃないの?

IPFは未だにL1$のレーテンシが1だが

クロックいくつの話だろう

>>235
L1キャッシュのアクセスはタグ引きがあるから番号と物理位置がすぐに求まるレジスタファイルには勝てない。
レジスタリネーミングとかやりだすとまた話は別だけどね。

GPUでは数十KBあるけどやはりレイテンシは大きいらしいね。
使いやすくするために次世代Teslaではレジスタファイルの階層化やるって話だから
キャッシュとあんまり変わらなくなるかも。

Knights Cornerを安価にばらまいてくれたら
いろいろやってみる機会ができて面白いだろうになあ
一般向けでバーゲン価格はありえないかもしれないけど

>>239
＞GPUでは数十KBあるけどやはりレイテンシは大きいらしいね。
シェアードメモリのことかな？
やっぱいくつかで共有するとアービトレーションでレイテンシかかるのかな。

いや、レジスタファイルそのものがでかい。
単精度×32768本って何バイト？

えっ、レジスタなのにレイテンシ大きいの？
最悪じゃん。

それを隠蔽するのがGPUの真骨頂だからなぁ　＞レイテンシを最適化するCPUとスループットを最適化するGPU

数百クロックのメモリレイテンシを隠蔽するために長大なパイプラインと膨大なレジスタが必要になるわけで。
そして膨大なレジスタの搭載でレイテンシが長くてもパイプラインである程度は隠蔽できるしね。
フルHDなら常に200万スレッドが並走しているからレイテンシよりも容量を取ってもおかしくない。

GPUは、レジスタへのアクセス（とシェアードメモリ）はレイテンシがマルチスレッドで完全に隠蔽できて、実質1クロック

>>244
200万スレッドw
1pixel1スレッドw
どんだけ無駄な設計だよw

512SPで8192スレッドくらいだったような。

>>246
シェーダープログラム書いてみ？　１ピクセル１スレッドだから。

同時処理するわけじゃないからね。

物事は様々な抽象レベルで考えるんだ

>>248
GPUってデバッガで実行過程をトレースすることもできないのに
シェーダのソースコードだけから物理的な動作を推測するのは無理があるわw

Parallel Nsight使え

なるほど。
GPUはレイテンシをうまく隠蔽してるんだね。

CPU　ヨボヨボで1つのことしかこなせない老人
GPU　いろんな人から多くの仕事を任せられる若者

って感じか

CPU　少数だけど頭が柔らかい人
GPU　いっぱいいるけど頭が硬い人

こんな感じだろ

CPU … 数個の複雑な仕事をこなせる職人
GPU … 数千単位の単純な仕事をこなす工場

ってカンジだと。
生産性では大量生産な工場に敵わないが、
オーダーメイドでいろいろな仕事を熟せるCPUさん。

CPUは老練な感じがするね。

何か指示をしたら全員同じ動きをする人々

日本人みたいだな。

>>238
タグ引きはL1では並列に行うからレイテンシは増やさないよ
レジスタファイルはポート数大きいしレイテンシで特に有利ということはない

レジスタの見かけのレイテンシが小さく見えるのは
実行ユニット間でのフォワーディングがあるからだよ

>>239
NVIDIAがレジスタキャッシュを導入するのは消費電力を減らすのが主な目的らしい
CPUもレジスタキャッシュを持ったものはあるけど
これはポート数を増やすのがしんどいから見かけのポート数を増やすのが目的

AMDのVLIWはフォワーディングでレジスタのレイテンシを隠蔽している

>>248
GPUで言うところのスレッドは複数スレッドでPCを共有しているから
CPUのスレッドとは数え方が違う
言うまでもないかもしれないが

D.E Shaw研究所はAntonと呼ぶ分子動力学(Molecular Dynamics:MD)計算専用のスパコンを開発し、その最初のシステムでのシミュレーション結果を発表した。

タンパク質のフォールディングではミリ秒程度のシミュレーションを
行わないとどのように折りたたまれて行くかが分からないのであるが、
汎用スパコンでのシミュレーションでは1日掛かって100ns程度に
相当するシミュレーションしか出来ず、msのシミュレーションには
何万日も掛かってしまうので、実用的ではない。
これを専用アーキテクチャで100倍程度加速すれば、実行可能な範囲に
入るというのがAnton開発の狙いである。

D.E.Shaw氏が創立したD.E.Shaw & Coは運用資産2.5兆円の
世界最大規模のヘッジファンドであるが、現在は、Shaw氏は
ヘッジファンドの日常のマネジメントには携わらず、
D.E.Shaw Researchのチーフサイエンティストとして、
MDのアルゴリズムやAntonシステムの開発を行っているという。
そして、同研究所の運用費用はShaw氏のポケットマネーで賄われていると
言われている。

このAntonの512ノードシステムの最初の2台が完成し、それを用いて、
2万3,558原子のDHFR(5DFR)では10.4μs/day、11万6,650原子の
T7Lig(1AOI)では3.06μs/dayの性能を達成した。
http://news.mynavi.jp/articles/2009/12/01/sc09_gordonbell/001.html

>>260
論理レジスタと物理レジスタのマッピングが一致してる場合においてはレジスタ番号から
レジスタファイル上の位置の算出は低コストでできるでしょ。

キャッシュはヒットを確認してからはじめて転送できるので、確実にデータの存在が保証される
レジスタと同等のレイテンシってことはないはず（あくまで同等の容量と仮定した場合の話）

バフェット氏のバークシャー、ＩＢＭ株を107億ドルで購入−ＣＮＢＣ
http://www.bloomberg.co.jp/apps/news?pid=90920013&sid=aZZ5tMhrWX1Q

>>262
レジスタファイルはアドレッシングは簡単でもポート数が多いのでレイテンシが大きくなるという話だよ

それはL1のRead/Writeポート数を増やしても同じことだ

まぁ、DRAMのレイテンシに比べたらかわいいもんだ。

日本の家電メーカーはこぞってARMに向かっているのだね。

東芝「レグザ」，パナソニック「ビエラ」など，最新テレビの映像エンジンを支えるARMのCPUコア
http://www.4gamer.net/games/143/G014356/20111114064/

>>265
L1はせいぜい2ポートとかだけど
レジスタファイルはSNBのPRFなら多分7ポートとかそれくらい

そもそもレジスタファイルのレイテンシはほとんどの場合隠蔽される

ついでに、ARM Technical Symposia 2011 Japanの他の記事
http://www.4gamer.net/games/032/G003263/20111111036/
http://www.4gamer.net/games/143/G014356/20111114046/
http://www.4gamer.net/games/137/G013737/20111110002/

このｽﾚはKnights Cornerの話が
あまり出てきてなさそうだね


将来、京を負かすかもしれないぞ?

じゃあ、お前がネタ振りすればいいだろ
最近なんかトピックあったっけ？

こないだIntelが複数のペタ級スパコンに採用されたよ！！って発表して以来特になんもない

機密保持契約破ってまで話したがるベンダーもユーザーもいないでしょ。

米国国策事業に組み込まれたからどうでもええわ

東大の次期スパコン、中国の大手IT企業浪潮と提携とか、おまいらがスルーしてただけで、
今年の7月以降大きな話題だらけだったしな。
あとは次のIDFあたりを待つくらいか。

個人向けに売ってくれることを祈るだけｗ

>「Intel Federalは世界最高のスパコンを作り上げることを目的として
>米国政府と協力して立ち上げた」と米国政府との緊密性をアピール

大学研究機関が主要顧客なんだし
Knightsはもっと情報出してもいいとおもうんだけどな

こないだCERNが出した発表でも使ったのKnightsFerryだったしパートナーのとこにもまだCornerは届いてないとか？

現状、Larrabee 1の倍精度強化版である以上の何かだとは思ってないんだけどな。

【スパコン世界一「京」の全貌】
「世界最速」を実現したアーキテクチャ
http://itpro.nikkeibp.co.jp/article/COLUMN/20111104/372504/
新機能満載のCPUとTofuインターコネクト
http://itpro.nikkeibp.co.jp/article/COLUMN/20111104/372508/
プログラム実行とMPI通信を高速化
http://itpro.nikkeibp.co.jp/article/COLUMN/20111104/372509/

東大の次期スパコンってこれじゃないの？

東京大学情報基盤センター、スパコンシステム刷新--PRIMEHPC FX10を4800ノード
http://japan.zdnet.com/datacenter/case-study/35010521/

>>279
Cornerは22nmノードだから、今作ってるところ

のはず

64bit後発組は、先発組にくらべてデコーダ負荷が軽くなる命令セット採用しやすくなるから有利じゃね？
先発組は、互換性維持したまま性能揚げないといけないので、デコーダがどんどん複雑になるが、
後発組はデコーダがシンプルになる命令セットにできるからな

PRIMERGY RX300のほうならいけるかなと思ったけどはPCIeボード刺さりそうに無いな。
RICCの入れ替えには使えそう。

MICが東大のスパコンで使われるって何処情報なん？
研究開発には使用してるみたいだけど

研究開発だけして使わない手は無いでしょ
まあ、東大のアカポス受け入れ先の国研あたりならいくらでも入る余地はあると思ってるが。

Opteronはなくなったとは思ったがVenusは意外だった。

KnightsCorner来たよ
http://www.xbitlabs.com/news/cpu/display/20111115163857_Intel_Shows_Off_Knights_Corner_MIC_Compute_Accelerator.html

何だルーマーでもなく妄想を吹聴してただけか

倍精度で1Tなら単精度だと2Tは出るのか。

>>288
> Interestingly, but the KNC accelerator is not just a PCI Express accelerator like its predecessor,
> the Knights Ferry compute accelerator for software developers,
> but looks like CPU that plugs into a socket or a special adapter.
何気にすごい事書いてあるんだけど

QPI版ktkrってこと？

京は早くも国会版事業仕分けで予算削減対象に祭り上げられてるがMICの影響もあるんだろうな。
日本主導の技術ってなんでこうもガラパゴス化するんだろうな。

WiMAX2がdocomoのLTE帯域増加より先行するとか。

あれ？ひょっとしてWestmere-EXと同じLGA1567か？
http://img.club.pchome.net/upload/club/other/2010/3/8/pics_tianzhon_1268060498.jpg

Itaniumとか見てると、システムベンダもIntelの非主流チップの舟には乗りにくいんじゃないか

http://www.xbitlabs.com/images/news/2011-11/intel_knights_corner_big.jpg
これじゃメモリ帯域足りなすぎで実効性能出ないっしょ

DRAM混載前提だな

Intelは、新アーキテクチャで技術的に優れてるけれど互換性が無い新CPUを作るも商業的に成功せず、
自社の互換性があるCPUが商業的に成功してきた

IA64でも、過去のインテルのCPUの法則とおなじようになった

いまや、PA-RISCの後継機として、HP-UX専用CPU化してるな

メニーコアにソフトウェアの対応は追いつくのかな?
多少ワットパフォーマンスが落ちる程度なら、従来通りのリッチコアの方が
ソフトウェアは数段書きやすいような。

Itaniumって技術的に優れてるの?
最初から全然ダメにしか見えなかったが。

TSVか

>297 宛な

まあ来る来る言ってなかなか来ない技術の一つですがね……

http://202.218.219.41/news/3637
> 450mmウエハー、EUV、TSV、半導体製造の最新技術は実用化のめども立たず

短波長のEUVへ移行せずに16nmを製造するって？　マジか
おじさんは頭が古いからびっくりだ

ttp://news.mynavi.jp/news/2011/11/16/009/index.html
Wide IO Mobile RAMは約1200の端子だからTSV

これはTSVの実用化には該当しないの？

サンプル出荷は出来た。予定通り2012年中に量産も開始できるかもしれない。
しかし離陸できるかどうかは、なんともわからんのですよ。

http://pc.watch.impress.co.jp/docs/column/kaigai/20111107_488696.html
> TSVの量産準備ができているかどうかについては、JEDEC内部でも見解がわかれている。
> 今回のカンファレンスでBill Gervas氏はTSVは少なくとも2016年まではスピードイー
> ルドの面から準備が整わないと発言。それに対して、メモリの部会を束ねるDesi Rhoden
> (デジー・ローデン)氏(Chairman, JEDEC JC-42: Solid State Memories)が、「JEDECの
> 見解は、TSVは現在すでに準備ができているというものだ」と反駁する一幕があった。

メモリ側の方という意味では該当しますよ。ただこれはあくまで容量・速度を稼ぐためのメモリ内部のTSVであって、この後ロジックと接続するという工程があり、
そこに関してはまだこれから開発するという段階です。メモリ内部のTSVの応用ではサーバー向け大容量モジュール(32〜64GB)が開発され既にサンプル出荷されています。
兎にも角にも問題はロジックとメモリとの積層で、ここでは後工程メーカー（パッケージング、ダイ加工・接続など）、半導体ファブなどとの連携が必要ですし、
デバグ・テストも相当な苦労が要ります。それと当然ですが加工自体が相当な歩留まりを落とす要因でありますから、メリットがそれを上回るかできる限り不良品を出さないかの
努力がまだ追いついていませんでしょうね。下手に加工失敗すればウェハでは良品でも不良品になっちゃいますから。

マジでDRAM混載しないかな。
セットでイイじゃん、もう。
レイテンシ劇減りでみんなハッピー。

熱（はあと）
積層接続間の経年劣化も結構気になるところではあります。

フォン・ノイマンが現代を生きていたら、プロセッサの性能は違っていただろうか･･･

熱問題が出るような用途は
積層でなくてシリコンインターポーザ使うんでないの？

TSVじゃないけどTSVと同じように使える積層チップはすでにソニーが実用化して使用してるな
原理上２層までしか無理で３層以上には使えないけどMCLってやつ

2004年にはこんなこと言ってたのにな

>米Intel社は2009年の32nm世代半導体製造技術量産に向けて，波長が
>13.4nmの光源を使うEUV(extreme ultraviolet：極紫外線)リソグラフィ技術を
>研究してきたが，それが実用化に向けた開発段階になったことを明らかにした。
ttp://techon.nikkeibp.co.jp/article/NEWS/20040802/60624/

EUVは光源出力が量産レベルには足りない
数年前はEUVマスクの欠陥を検査する方法が無いとかいう笑えない話もあったが解決したのかな

KLAが開発したじゃなかったっけ？
後はレジストと一番最大な問題光源だな。

未だに平均30Wで15WPHとか話しにならん

印刷以外の方法でトランジスタ形成できないものか。

電子ビーム直描

ちょｗ量産でｗｗｗ

印刷以外の方法で　同じくらい安く　トランジスタ形成

タンパク質の勝手に整列する性質を利用して云々というのを
いつぞや新聞か何かで見たような。

DNAコンピュータの原理を改良して配線づくりか。新しいな。

新聞でたまに◯◯技術を開発みたいなのがでるが、
ああいったのの９割以上は実用化せずにお蔵入りだからな

価格を下げたり利益を出したりするのはもっと難しい
レアメタルみたいに痛い目を見ないとｗ

http://cybergarden.cocolog-nifty.com/blog/2011/10/amd32nmintel-f9.html

AMDの32nmは歩留まりで苦戦しているが、Intelよりトランジスタが小さい。なんで20億トランジスタが300平方mmなんだ?
GLOBALFOUNDERIESは凄いことをしている。最高だぜ!

>>324
The Interlagos chip has a total of 2.4 billion transitions, which means the Valencia chip has 1.2 billion.
http://www.theregister.co.uk/2011/11/14/amd_opteron_4200_6200_launch/

実は12億トランジスタでした
最初20億とでたのは間違い

モジュールx4とL3だけで12億超えそうだけどな

間違いというかてきとーに見積もっただけですかね。にしてもかなりスカスカな感じです。まあダイ写真見ても明らかですけど。
ノースブリッジは既存のK10からかなり流用したというらしいので、そこら辺のレイアウトが甘いんでしょうかね。
といっても1Module+L2で213MいくのでL3とあわせるとどう考えても足りんような気がします。

一応GPUにトランジスタを使えばかなりの密度には詰め込めるようなので、GFの32nmSOIは性能より密度重視なのでしょう。
（Llano 4Coreは1450Mに対して228mm^2で1mm^2あたり6.36M、Bulldozerを2Bとしたときの1mm^2あたりの密度はほぼ同じ6.35M）

どっちでもいいじゃん。
トランジスタの量は結果を得るためのコストであって、消費者が求める結果（性能）そのものではない。
本当に20億も使ってこんな程度のものしか作れないならx86から逃げてもまともなもの作れないぜ。

>>327
低クロック動作だと密度あげられるからね。
CPUでもL3キャッシュのクロックをコアより落とし密度をあげて容量増やすのは常套手段だし
（キャッシュの場合クロックだけじゃなくて平均アクセス頻度も少ないけど）

俺のスレストぶりは半端ない

おまえってセコンドガレッジやってるほう？
たまには更新しろよ

レンタル料3年分纏め払いしてそれ以降払ってない。
故に今月いっぱいで閉鎖。

だんごさん、AVXやってる？
あれ速い？
SSE2系の延長で考えていい？

なぜここで
ム板の汗スレじゃいかんのか

インデックス修飾はどのような目的で作られたアドレッシングモードなのか
教えてください

x = ar[3];

ソフトウェアトランザクショナルメモリのハードウェア支援は
Rockと共に消失?

64バイトのキャッシュラインを単位に、複数のラインを同時に書き換え監視したり
atomicに更新できたりすると、夢がひろがりんぐ。

>>337
BG/Qで復活

http://news.mynavi.jp/photo/articles/2011/09/08/hot_chips23_ibm/images/005l.jpg
これだ! 素晴らしい。

tbbのcache_aligned_allocatorとatomic使えばよくね？

>>341
TBBのatomicってよく知らないけどただのクリティカルセクションじゃないの？
だとすると複数のクリティカルセクションを合成したときにデッドロックが発生する可能性がある
STMはそれをプログラマが特に考慮する必要がない

ただ、純粋にソフトウェアで実装するとマジで重いので
バリアとかをハードウェアで実装して高速化する

変な書き方をしてしまった
クリティカルセクション -> ロックを使ったクリティカルセクション

ロックを使った排他制御は、メニーコアにスケールさせたときに性能劣化が激しいのも問題。
クアッドコアで1コアが共有資源をロックして、他3コアを待たせるのは許容範囲でも、
メニーコアで他の15コアとか63コアとかを待たせると、結果として待ちだらけになってしまうからね。

ロックとかスヌープとかないようにできないんかな。
コア増えるほど頭打ちになってくじゃん。

BG/Qのmulti-versioned cacheは他アーキテクチャに広まればかなり有望かと。

Itaniumにも似たような機能なかったっけ

無いと思う。
> BG/Qが実用化されると、トランザクションメモリのハードウェアサポートを
> 持つ初めてのプロセサとなる。
と本文にもある。

>>344-345
parallel_reduceを使えばロックは結構な割合で削減できるしパフォーマンスもコア数に比例して上がる事が多い

>>349
ここでやりたいのは並列処理じゃなくて、
たとえば一つの連結リスト(同等の機能を提供する構造であれば何でもいいが)という共有資源に対して
どう効率よく並行アクセスを許すか、という話なのだ。

>>344
待たなかったら正常動作しないんだからしょうがない
４個と１６個じゃプログラム設計から変えないとならんがメモリは一本だからヤル気出ねぇ

よく最適化された同期ルーチンは
ほぼmfenceのコスト
つまりロード・ストアキューのフラッシュのコスト
なんでSTMだろうがロックだろうがあんまりかわらん

まぁOpenMPですら多くの場合ろくに最適化されてない
最適化されたロックは自作するほかないという現状は問題ではあるが

この場合に着目している排他制御のコストは
ロック方式の場合、実際にロックが衝突してスピンで待たされる事象かと。
STMというロックのない同期(代わりにリトライはあるが)をいかに低コストで実装するかを考えたときに
IBMの回答がマルチバージョン化L2キャッシュによるハードウェア支援。
RockはL1だけだったので一歩踏み込んでいる。

しかし、トランザクション中、プロセスコンテキストスイッチとかL2をフラッシュするような事象に
対応できるのだろうか……?
ひょっとしてHPC限定なのだろうか。

結局、マルチバージョンとか楽観的並行制御とか
トランザクション処理で研究されてきた手法になるのか……？

マルチスレッドや同期の説明が詳しいアーキテクチャの本ってないの?

これかな
http://www.amazon.co.jp/dp/4798014621

STMでもコア間通信をメモリシステムを介しておこなう以上
衝突がなくてもメモリオーダリングを保証する必要がある
現代のx86CPUではここにコストがかかってしまう

>>357
x86を駆逐すると言われているARMだと低コストなの？

>>355
まずはTanenbaum先生から学ぶのを強くおすすめしておく。
http://www.amazon.co.jp/dp/4894715376
> モダン オペレーティング システム 原書 第2版 [単行本]

>>358
誰がそんな寝言を?

>>356, >>359
thx。今度買って読んでみるなり。最近めっきりソフト事情わからんので。

>>360
そういえばAMDスレの気違いが言ってたな。

スーパーファミコンについて質問だけど、
スーパーファミコンのCPUは16bitで、
メモリ容量は64KBまでしか扱えないはずだけど、
メインRAMだけで128KBも搭載しているのはどうして？

セグメント方式を採用してるのかな？

>>363
SFC/SNESのCPUは65816互換の16bitチップで24bit(16MB)のメモリ空間を持つ。
命令カウンタやアドレスレジスタは16bit長なんでバンクアクセスだけど。

>>363
http://ja.wikipedia.org/wiki/65816_(%e3%82%b3%e3%83%b3%e3%83%94%e3%83%a5%e3%83%bc%e3%82%bf)
アドレスは24bit。

なるほど。
残りの8Mbitはどうやってメモリ空間を確保しているんですか？

でもCPUが16bitだから、一度に扱えるプログラムの最大量は64KBが限度ですか？

君のパソコンにも付いているx86の元祖16bit CPUのi8086だって16bit CPUで1MBも扱えたよ。

>>367
基本は16bitアドレス＋8bitのバンクレジスタ値＝24bitアドレスだが、24bitダイレクトアドレスを
扱う命令も持ってる

ttp://hp.vector.co.jp/authors/VA042397/snes/65816.html

つまり、16MBのメモリ空間を256個に分割し、
16bitCPUから64KBのメモリ256個にアクセスできるように見せているんですか？

>>357
え？
キャッシュ経由、あるいは内部バス経由で届かなかったっけ？

>>371
チップ内バス経由でもコストがかかるということ
大体だけどロードストア片方なら50cycle両方なら100cycleくらいかかる

>>372
把握

しかしFXのインターコアレイテンシでかいな・・・
昨日Sandraで計ったが棒グラフが飛び出してやがる

いつもメモリアクセスが足を引っ張る。

ここにはSFCのCPUは64KB×256バンクと書いてある

http://www.d-colors.net/game/sfc.html

65816は24ビットアドレッシングに対応してるんだよね?
64180みたいに、64KB空間内に別のアドレス領域を呼び出す形じゃないと
バンク「切り替え」とは呼びづらい印象

65816は一部のアドレッシングモードで24ビットリニアアドレスに対応している
>>369のリンク先が正確

かなり嫌なCPUだった

マルチコアから高性能コアで進化を目指すインテルのCPU
http://plusd.itmedia.co.jp/pcuser/articles/1111/29/news008.html

でもないな
スタック相対アドレッシングが二つ抜けている

>>378
うん
やっぱこの企業アホだわ・・・

と、中卒ひきこもりが申しております

ID:s/l3GAGD

Socket AM3/AM3+マザー総合 Part4
596 ：Socket774[sage]：2011/11/29(火) 01:18:48.37 ID:s/l3GAGD
>>595
オンボならソレくらい大目に見てやれよ・・・
価格から言えばC/P最強なだけある

それでもBulldozerを買った漏れは豪傑
588 ：Socket774[sage]：2011/11/29(火) 01:21:01.38 ID:s/l3GAGD
>>586
俺貴族か
なら貴族らしく憐れな民をAMDへと導いていかねばならぬな

【AM3+】AMD FX総合 2台目【Bulldozer】
481 ：Socket774[sage]：2011/11/29(火) 11:23:00.18 ID:s/l3GAGD
k15statはよ

【AM3+】AMD FX総合 2台目【Bulldozer】
489 ：Socket774[sage]：2011/11/29(火) 17:46:39.65 ID:s/l3GAGD
>>486
実際はCPUとかの場合色々と要素があるから単純にはいかないけど
まぁ大まかにはそうだね

それでもBulldozerを買った漏れは豪傑
603 ：Socket774[sage]：2011/11/29(火) 19:06:50.68 ID:s/l3GAGD
>>601
同感

マジな話、自身で使ってみるまでわかんねぇ

CPUは1Gヘルツぐらいにクロック周波数を抑え、
コアを16コアぐらいにした方がいいんじゃないの？

つ「シングルスレッド性能」

処理にはほぼ必ず並列化できない部分があり、アムダールの法則により、
シングルスレッド性能は依然として重要。
メニーコアCPUの代表・SPARC T1は1.4GHzの低クロックコアで始まったが、
最新のT4では3.0GHzの「普通の」コアになっている。

EPIC+OoOEでも1GHzじゃC2Dに負けるな

>>384-385
だよね。
OSやソフトが必ずしもマルチコアに対応しているとは限らないから。

PGの立場からすると性能を上げるためのマルチスレッドって難しいし面倒なんだよね
排他処理だとか同期だとか何だとか
GPGPUが何だとか騒がれててもなかなか一般用途に降りてこないのはそのせい

GPGPUを本気で普及させたいなら、勝手に並列化してくれるコンパイラが必須だと思うわ
何も考えなくても勝手にMMXやSSE使ってくれるIntelコンパイラみたいにさ

ICCはそんなに賢くないよ。使ったことあるの？
SIMD化できるのは単純なループ位
まともにSIMDを活用するにはintrinsicsを使わざるを得ないのが現状

GPUを使った自動アクセラレーションとか実用には程遠い
OpenMP程度のセマンティクスすらGPUコードの自動生成とかできない
そもそもGPUでまともな性能を出すためにはアルゴリズムから調整しなおす必要がある
GPUにポートしたのにCPUよりワットパフォーマンスが悪化するなんてことは簡単に起きる

どうせ人力が必要ならせめて書きやすくしたいよねってことでC++AMPとかが提案されている

>>381
残念ながら高卒だ
まぁアホなのは自他ともに認める

先日のIDFでIntelはCilk Plusをアピールしてたな
Xeon用のコードを書いておけばMICへの対応はリコンパイルだけで良いと

>>390
正直でいいなｗ
まあ統計では高卒以下って決して少数派じゃないんだけどね。

>>378
Intelすげぇな･･･
わくわくしてきたぞ。

スマートフォンや組み込み向けでGPUを積極的に利用する動きが盛んだから
そこから逆輸入される展開もありじゃね

ゲームにしか使われてないじゃん

米クレイ、京大からスパコン受注　富士通「京」に競り勝つ
スーパーコンピューター専業の米クレイ（ワシントン州）が、京都大学の次期スパコンを受注した。
学術情報メディアセンターに納入、2012年５月に稼働させる。旧帝大７校が海外製スパコンを主要機種として採用するのは初めて。
京大は1969年以来、富士通の牙城だった。受注額は外部記憶装置などを含め40億円未満。クレイは今回の受注を機に、国立大学や公共研究機関への販売を強化する。

>>388
ソフト屋さんでもマルチスレッドってそんなに難しいの?
俺はBASICやC、Javaの基礎しか知らないタコなんだけど。

マシンを会社組織になぞらえて、この処理は山田さん（山田スレッド）、この処理は鈴木さん（鈴木スレッド）
忙しいときにはみんなで手分けする、呼び出し（メッセージ）をやり取りして。
単純だけど大量の処理は下請けの爺費有(GPU)さんに外注する。

そんな素人の考えじゃだめなのかな

>>397
山田さんの仕事の結果次第で鈴木さんの仕事が変わるような処理が多い

>>395
んなこたぁない
普通の操作の画面遷移にGPU支援使うのはもう当たり前になって来てる
GPGPUもどんどん使っちゃおうぜって流れも

>>397
「アムダールの法則」
www.ne.jp/asahi/comp/tarusan/AMDAHAL.jpg

間違えて画像だけのそれも不完全URL張ってしまった…

古いがわかりやすいブログ記事
http://www.ne.jp/asahi/comp/tarusan/main72.htm
同トランジスタ数でコア数を変えた場合の性能グラフ
http://www.ne.jp/asahi/comp/tarusan/AMDAHAL.jpg
HTやBulldozerのような手法が有効な理由のグラフ
http://www.ne.jp/asahi/comp/tarusan/SMT-CMT.jpg

進捗報告会議・対応再検討スレッドも必要になるのか
動的にコードを書き換えて再コンパイル・リンクみたいで訳わからなくなるわ

>>396
クレイってことは、これOpteronなのか？

>>397
> 忙しいときにはみんなで手分けする、呼び出し（メッセージ）をやり取りして。
手分けする処理を予め決めておかないといけない
呼び出しあってﾃﾞｯﾄﾞﾛｯｸが発生するとｱｳﾄ

とはいえ、ﾏに任される現状のままではﾏﾙﾁｽﾚｯﾄﾞ化は進まないね。
ｺﾝﾊﾟｲﾗやﾊｰﾄﾞの支援も欲しい。
依存関係がなくて空きコアがあれば、自動でｽﾚｯﾄﾞを分ける、
くらいのｺﾝﾊﾟｲﾗとﾊｰﾄﾞは作れるはず。

仮想化サーバのように、無関係な処理を持ってこない限り、
依存関係がない、ということは無い。

>>403
Xeonもあるからなぁ。
Magny-Coursからのアップグレードならともかく、Opteronを今選ぶ意味ってあんま無い気がするんだが。

>>404
C言語の仕様で依存関係の有無を判定するのは無理だろ
ポインタで指された先の領域がどこかでオーバーラップしてるかもしれないんよ

>>406
XE6らしいよ
http://dreammakerk.blog92.fc2.com/blog-entry-5773.html

2位じゃダメですね、入札も

>>397
マルチスレッド自体は別に難しくないぞ
山田さんが営業して、鈴木さんが電話番して、佐藤さんが会計処理するみたいな感じなら

難しいのは3人で分担して会計処理をして早く仕事を終わらせろって言われた場合
分担をきちんと決めておかないと作業が重複して無駄になるし、
二人以上同時に同じ書類を見られないから、誰かが使ってたら使い終わるまで待たなきゃいけなかったり
Aを処理するためにはBとCの情報が必要で、Bを処理するためにはDを…なんて場合もあるし

そういった諸々を勘案してプログラムを作るのが面倒くさくて難しいってお話

64kBの頃にはメモリーを確保するのに少しの量、少しの期間の占有も
無駄は省かなければ、みたいな感じがあったが、
今、メモリーを少し余分な期間や分量を確保してもあまり気にしていない
プログラマは多いだろう。保守性の高さとか、メモリー最適化よりも
優先したいことことがいくつか考えられる。

今はせいぜい1ソケット20スレッドくらいだから、どのスレッドも常に
フル稼働するのがハードを生かすよいソース、と考えている。
もしも使えるスレッド数が数桁ほど増えたら、立ち上げたスレッドに
暇そうにしてる時間があってもあまり気にしなくなるかもしれない

リッチコアはコスト高いが、
メニーコアのインターコネクトはもっとコスト高い。

>>403
12年のはOpteronだな。予定通りに14年に追加があるならそっちは
インターコネクトがPCI-EのCascade だから、その時点で性能のいい方になるだろう

ﾌﾞﾙの評価が、意外と悪くない
ttp://news.mynavi.jp/special/2011/zambezi2/index.html
大原評

・サーバ用のCPUとして使う限りはSandyに匹敵する性能
・これをデスクトップPC向けに流用したことが論外、暴挙。
みたいな感想が書かれている。
デスクトップPC用のCPUとして使う限り、PhenomIIと比べても少し劣る性能しか出ない。とね。

大原自身は最初のころより随分発言が変わってるけどなｗ

http://ascii.jp/elem/000/000/489/489200/index-2.html

＞独立した3つのALU命令と3つのLoad命令であれば、実質1.5サイクルで処理できることになる。
つまり、単純に「IPCが減った」と言い切れない構成に変わったわけだ。
Load命令＋ALU命令であっても、実質的なスループットはむしろK10よりも向上する可能性が高い。

それが

＞本来ならIPCが3→2に下がっているのだから、これを補うためには動作周波数を50%引き上げる必要がある。

庇おうとして庇いきれなかった
最低限現行アーキテクチャと同等の性能はあるだろうという低めの予想をも下回った

1年くらい前はAMD自身がK10→BullはIPCも向上するって言ってたから

実行ユニットが減ったから2命令でぴったり張り付いてるグラフはある意味笑えた

相変わらず長い

噂: 3GHzCPU、768MBRAM…国内開発者がWii Uの具体的なスペックをリーク
http://gs.inside-games.jp/news/comment.php?id=20883&page=2

G3系と970系で若干違うとはいえ
Broadwayの拡張がXenon風PowerPCのクアッドというのはわかりやすいが、
DRAM内蔵等で差異化できないと
本当にXbox360を遅れて出しただけになってしまうな。

PCの派生品で作るようになってからまるで面白くなくなったなゲームコンソールも
OSも順調に重くなってるようだし

2Gbitチップを3枚か4枚重ねたら768MBか1GBだし
噂が本当ならダイスタックなんだろうな。
でも45nmなら熱が多いし、スタックはDRAMだけでCPUとはMCMかも

そういえば、Broadway製造元のこんな話を読んだばかりだった。

http://www.geocities.jp/andosprocinfo/wadai11/20111203.htm
>　2011年12月1日にIBMとMicronは，IBMがMicronのHybrid Memory Cubeを製造すると
> 発表しました。製造プロセスは32nmのHigh-K Metal gateで，IBMのEast Fishkill
> 工場で製造されます。

任天堂は必ず変なメモリを積んでくるが、まさかなあ……

いままで1T-RAMとかeDARMとか実績たっぷりすぎるし容量より速度取るとか2012年に出すにはメモリ少なくねとかほんとにやりそうで怖い

チョニーと任天堂は変なメモリを積む上に容量を少なくするから、
PCでのゲーム製作技術が応用できないし、
少ないメモリ容量をやりくりする事に終始するので最悪。

PCで主流となっている汎用メモリをたくさん積むのが一番良いのに何故それをやらないのか？

容量より帯域

>>426
たぶん、PCとは比較にならんほどにコスト削減圧力が強いからだろう。

と思うのだが、PS3とかの値段を考えれば、もうちょっとメモリ増やせって思うのが普通だよな。
出現当初はともかく、今もこの値段っていったい... とついつい考えてしまうレベル。

PC用メモリが今のように格安で売られる時期には特に強く思う。

発売時期も勘定にいれなよ

ヘテロジニアスだとか新CPUをギリギリまでコストかけて頑張っても
そのしわ寄せコストの折り合いでメモリサイズまでギリギリじゃ
開発者にいったい何をやらせたいのか
片手落ちもいいところ

やっぱ帯域のために容量は絞り込んでると思うな

PCでメインメモリが遅いのに見栄えのいいゲームができるのはGPU-VRAM帯域が
広いからと、CPUが多くのキャッシュを積んでメインメモリの遅さを
隠蔽しているから。キャッシュのふんだんなCPUはダイが大きくなって
高くつくし、VRAM専用帯域を設けるハードもチップ数が増えて高くつく。
PS3を企画した頃のようなコストのかけ方は今は難しいだろう

変なメモリを使うのはDDR3とかだと帯域稼ぐのにビット幅を増やさないといけないからだよ
ビット幅を増やすとボードのコストにそのまま跳ね返るから

コンシューマゲーム機は長い期間で大量の部品を調達するから
変な部品を使う方がまだコスト削減できる

PS3や箱は良い線いってたと思うけどな
まだPS2時のHL2みたいなソフトがPCで出てきてないし
新ハードは何処も厳しそう
頓挫した物理演算チップとか変化球で載せてこないか期待してるけど
それなら部品数削ってGPUに金かけた方がよさそうだし

>>432
初期の箱のGDDR3配線はぐちゃぐちゃだったな
PS3のGDDR3はGPU上に載せてたけど、メモリクロック下げたんだっけ

ゲハは無知なんだから黙ってろ

ゲハすぎるわ

そもそもPCじゃないんだからメモリ容量そんなにいらない。

>>436
少ないだろバカ

特にPS2とPS3は酷すぎる

RING基板は1GBらしいから少ないけど全然ダメという少なさじゃない。
とはいえ、アップグレードせずに数年使い回すのだから1GB越えるくらいじゃないと。

PSPも初期設計どおりeDRAM 8MBのみだったらいまごろ楽しかっただろうな

PC-FXにはメインメモリの増設スロットがあったなそういえば

>>417
IPCが向上するなんて言ってないぞ。シングルスレッド性能が向上するとは言ってたが。
（もちろん「XOPやFMA4などの新命令を使わずにできる」なんてことは言ってない）

コンソールはハード決め打ちなこともあって
メモリが足りないのは工夫すればなんとかなるんだけど
帯域とかレイテンシはわりと工夫の余地がなく、致命的に表現を制約するんですよ。
5年同じハードを使い回す≒工夫に費やす時間の猶予はある、という観点で
容量よりも性能が優先されがちです。

K10をFMA4やXOP、C6ステートに対応させりゃ良かったんじゃねというのは禁句なんでしょうか（´･ω･｀）

>>442
TimnaのためにP6の要素を分解して再構成したチップをつくり、
さらにBaniasへと進化させたイスラエルチームのような別チームをAMDが持つ余裕があれば、
並行してそういうのを作ることもできたんじゃないの？

鯖用とPC用に異なるアーキテクチャのCPUを並行開発できないAMDの弱点が、
Athlon64では逆に有効手になってたけど、
今回のﾌﾞﾙでは順当にデメリットが大噴出した。

ということだよね?

>>442
Llanoが未だにSSSE3すら対応してない（Core 2登場から5年も経ってるにもかかわらず）。
あのデコーダ改良できる人いないんじゃないの？

作った本人以外でも改良できるような骨太の開発体制の構築って難しいよな
中小企業はどこも苦労していると思う

COBOLが思い浮かんだ俺。

>>440
IPCが上がると言ってるぞ
ttp://www.xtremesystems.org/forums/showthread.php?257927-AMD-s-Bobcat-and-Bulldozer&p=4531199&viewfull=1#post4531199

モジュールあたりのIPCだったんだよ！！！１！

な、なんだｔｔ(ry

>>446
ファブレスになった以上最早R&D部隊の確立無くしてAMDの存続は成しえないから頑張ってほしいなぁ

まぁあの取締役会だからこれからもお馬鹿な決定をいっぱい寄越してくれそうだけどさ・・・

>>441
でもPS3でXDRAMを採用した事は評価できない。
当時からDDR3SDRAMは存在していたし、
今でもDDR3SDRAMが現役。

>>452
当時のDDR3じゃPS3のXDR RAMの帯域出せないだろ

黄石。

>>453
メモリは帯域よりも量が重要だよ。
PS3はメモリの量の少なさが足枷となり、
ライバルのXBOX360やPCゲームに勝てないし、
少ないメモリをやりくりする為にソフト開発費が高騰している。

1チップの帯域とシステムの帯域。ゲーム機はコストがタイトで
チップ数を減らしたいから、同じ容量、同じシステム帯域でもチップ数が
少なくなる速いインターフェイスを選ぶ。

バカが沸いてるな

少なくとも、456の言うような考え方でハードを作ってる会社があるのは事実だと思うんだ。
その方向性が妥当かどうかとは別問題として。

その奇抜な発想が突き抜けていたのがPS2のローカルメモリのビット幅の広さ。

結局、後継ハードで互換性を確保できなくなった原因でもあるんだろ?
それに、時間が経つと製造コストが下がる、はずがなぜか下がらなくて赤字を出しやすかったり。

PCを超えるゲーム機は出ないってことになる
ま、アーケードで唯一がんばてるtypeXがPCだしな

戦いは数だよ

PCは金かけただけ良いグラフィックスで楽しめるのがイイなぁ。
この拡張性は魅力だよ。
選択肢は多いに越したことない。

登場時点でハイエンドPCより描画性能が高いというのはPS2が最後だったからね

PS3/XBox360以降のコンシューマゲーム機のアドバンテージは
１）同一性能であれば低コストであることと
２）PCでは最低限遊べる環境を低めに設定する必要があるがその必要がないこと

今後数年でIntel内蔵GPUが十分な性能を持つようになれば
ゲームを遊べるレベルのＰＣが普及することになるので
これらのアドバンテージは消失する

となるとあとは さらに高性能に逃げるか 特殊なUIで差別化するしかない
でもMSはKinectをPCに開放してるしあまりゲーム機本体に囲い込む気はなさそう

３）電源とゲームメディアを入れるだけでゲームが出来る

これ、大きいぞ。子供でもお年寄りでも簡単にできるからな。

しょぼい考察聞かされる身にもなれよ
2＋1個しか挙げられないってどんだけ低能だよw
ゲハはおとなしくロムってろ

取り敢えずPCあればゲーム機イラネ

>>465
ゲーム機用のソフトの大半がPCでもプレイ可能な状況じゃなけりゃ
そもそも二択が成立しないんだが

そうなった今ゲーム業界側はどういうハードを構想するべきなのかね。
PCのGPUが高速化しちゃった今ゲーム向きに差別化できるCPU・GPUは何か。

まあやりようがないってのが答のような気もする。

>>462
VRAM4MBのゴミのどこがハイエンドなんだよｗ
一年以上前に発売されたドリームキャスト以下のメモリ容量。

>>463
＞３）電源とゲームメディアを入れるだけでゲームが出来る

PS3と箱○のソフトは、電源とゲームメディアを入れるだけでは遊べないから糞
家庭用ゲーム機のアドバンテージを自ら放棄している

まあ、GSはシェーダ以前の古典的なハードで
フィルレート=帯域命の設計だからな

DirectX7の世代の範囲で、
速度を優先して機能を削減したような構造だよね。

テクスチャを張ると速度半減ってのも大きな制限の一つだけど、
VRAM容量が小さすぎるからテクスチャを利用すること自体が困難だから、
速度半減という弱点は実質的にはあまり関係ないか。

カタログスペック通りの高性能を発揮させるためにはすさまじく労力が必要な厳しい構造だったんだよな?

>>462
そもそも性能の要らない2DゲームみたいなものだってPCでやる人は少ないわけで
コスト云々以前に市場がない気が…
ハイエンドなんて志向する客はさらにほんの一部なんだから、高い金出してグラボ買ってね！で棲み分け出来てると思う

PS2の糞仕様の所為で、どれだけ多くの日本のソフトハウスが潰れ、
どれだけ多くの日本のソフトハウスが開発能力や競争力を失ったか知れない。

>>471
廃スペックゲーム機が生き残る道は、
アーケード筐体と同じアーキテクチャを採用し、
業務用のソフトがそのまま家庭用でも動くみたいにしないと厳しいね。

でも、今だともうネオジオみたいなやり方は利益を出せないだろうな。

いつからここはPS2を叩くスレになったんだ

>>473
アーケードってx86のCPUかつNvやAtiのGPUなどPCのシステムそのものか、それに近い仕様で動いてるやつ多いみたいだぞ。
しかもハイスペックでも何でもない感じで

OSもWindows系を使ってたり

アーケードは全部Winだよ
コスと考えたらあたりまえだけど

eX-BOARDはC7とCN700（UniChrome）

久夛良木健氏が語る、PlayStation 3とCellの正体
http://pc.watch.impress.co.jp/docs/2003/0901/kaigai015.htm

＞[久夛良木氏] 　次は面白い。(PS3は)ただ垂直(ネットワークしない状態)で見て、
＞単なるゲーム機だと思ってやってもすごいと思う。

＞だから、(ソフトウェア開発が)ナイトメアにならないようにしないと……。

ナイトメアになっちゃったね。

今のアーケードマシンって随分化石染みたスペックの物使ってるんだな｡
ハイエンドでも。まあ組込み系だから当然だけど｡

アーケードは一台あたりにかけられるお金が違うし、逆に台数は出ないから
ハイスペックな汎用PCそのもの方がいいに決まってるだろ。

PCとは違って連続稼動が求められるから多少はPCよりは周回遅れの「枯れた」パーツ使うことになるね。

といっても組み込み向けとして売られてるCPU・チップセットって現状、型落ち品を
高く売りつけるための手段になっている気はする。
（最新プロセスのCPUは連続稼動に耐えられるほど安定してないなんて言っちゃったら
Xeonは誰も買いません）

組み込みマザーボードメーカが
ASUSみたいなメーカみたいに
神速で作れないだけだろうと思う

劣悪環境前提ってのも考慮に入れてな

PCゲーや家庭用ゲームがこれ程発達した現代では、
既にアーケードゲームの存在意義は無くなったと言っても過言じゃない。

大型筐体ゲームを家に置きたいとは思わんがな。

しかも一台で自動車が買える程の値段がする
問題はアーケード筐体の方で、家庭用ゲーム機である程度代替できてしまう

>>483
そこだよな、なるたけ消耗系部品点数を削りつつ必要なレベルを維持できないといけない
その上原価も安く・・・となると最新は・・・

かなり以前からゲーセンの主役はプライズやメダルや体感筐体機で
ビデオ表示性能を誇示する時代じゃなくなってるし。

あとは特殊な機材が必要なヤツとか。
三国志大戦とかWCCFとかガンダムカードビルダーのようなカードゲームや
戦場の絆みたいな体感ゲームとか。

見れば見るほど特殊なCPUやらアーキテクチャーは必要ないな。

Teslaとか載せて家庭用PCとは一線を画するハイエンドスペックを実現して、
それで高いインカムが確実に望めるならそうするだろうけど、
あんまり期待できないよね……
客にアピールするのは、幸か不幸かそこじゃない。

京を繋いでゲームを作ったら良いんじゃね？

15年位前にゲーム雑誌で読んだけど北米じゃ一番近いゲーセンまで10kmなんてことも珍しくないそうな
（人口密度の高い日本ですらかなり潰れてるし今はもっと酷いんじゃないのか？）

巨大冷蔵庫に食料大量に詰め込むのと同じ感覚でゲームに金かけるのがゲーム大国アメリカ

もっとも、その消費志向も変わりつつあるけどね。
丁度日本のコンビニみたいな品揃えの小型店舗が増えてるらしい。

へぇ〜、たしかにアメリカでゲーセンってイメージないなぁ。

映画のTRON見てよ

>>485
格闘ゲーやシューティングゲーで使われるような筐体なら重さ100Kg(家庭用400L冷蔵庫と
同じぐらいの重量)だから、工夫すれば家に置けないこともない
(ただし幅が70cmはあるから、分解しないとだめだな)http://
>>492
海外でゲーセンあると、ストリートギャングや麻薬売人の類がたむろして
治安的にもよくないからゲーセンがあまりないと聞いたが？

後、今はx86CPUでコプロのx87など使わなく、FPU性能もSpecCPUベンチを
見る限りじゃ他アーキと遜色ないのに、「x86=FPU遅い」の扱いをされてるのは
何故？

レジスタ8-16本しかないからじゃない?

>>495
固定観念て奴ぢゃね？

日頃の行いだよ
必要な命令を載せるよりクロック上げる方を優先すんな

浮動小数点演算が主用途と割り切って128bit×128本とか載せてるやつに比べれば
そりゃ遅いよね。しかし汎用CPUである限りはレジスタをむやみに増やすわけにもいかず。

>>496
Pen4以降は物理「レジスタ増えてる
>>498
x86はCISCだから命令の数は多い
>>499
おそらくCELLのことを言ってるのかな？
しかし、CELLのSPE1つの浮動少数性能はいくつかのサイトを見ると実効で
23Gflopsでこの数値はCore2 1コア分のFPU実効値22Gflopsとあまり変わらない

そうか、CPU関連のサイト製作者は何気にアンチx86RISCマンセーみたいな人が
多いから、叩きたいだけのかも。

なに勝手に結論出してるの、ダイサイズ考えろよ

>>499の考えで問題ないだろ

DreamcastのSH4のSIMD
PS2のVU
PS3のCell
とゲーム機向けのCPUは当時としてはFPUにリソースを割いたものが多かったからな

いっそ中国の新型CPUを使ったゲーム機とかでたら面白そうだが。
GPUどうすりゃいいのかわからんけど。

>>499
別に遅かないよ。
i7-2600あたりでDGEMM 100GFLOPS出せるし実効性能はかなり高い。
SIMDの物理レジスタは百数十本とかあって、リネーミングして並列動作させてるから
FPの稼働率を高められる。
むしろ論理レジスタが少ない方が動的スケジューリングしやすいんじゃなかったかな。
（いまやC++ネイティブと遜色ないパフォーマンスを得たJavaVMなんか1レジスタのスタックマシンだし）
安藤さんとかは故意にこのあたりをミスリードしていると思う。

>>504
団子のそのレスも故意にいろいろミスリードしてません?

>>503
爆発するから気を付けないといけないな

>>506
そっちでも面白いけど、ゲーム機になってない主要RISCってAlphaとSPARCだろう。
SPARC独自実装してる富士通かAlphaパクった中国に新ゲーム機を期待したい。

>>505
レジスタリネームを備えたアウトオブオーダ実行型のアーキテクチャだと
論理レジスタ本数の多い少ないはそれほど性能に影響しないね。

インオーダのAtomとかなら確かにレジスタ16本じゃ性能出すの辛いって思うけど。
でもそれこそどうにでもなるんじゃね？
巨大論理レジスタを表現するためのオペランドフィールドを増やすとか可変長のx86のほうが柔軟に出来ると思うけど

SPARCのISAは1オペランドあたり5ビットしか指定フィールドがないからさ、
京に採用されたHPC-ACEでは、前置命令に拡張フィールドの3ビット（×3フィールド×2命令分）を
収めることで、強引に256本のレジスタを表現してるわけで。

そういう手を使うならx86でも（プリフィックス新設すれば）可能だと思うんだよね。
実際MICはSIMDの論理レジスタを32本に増やしてるし。

HPCで使われてgreen500で京より上にも入っているXeonは2GHz台、
デスクトップのパフォーマンスクラスは3GHｚ台、
他のプロセッサよりも電力的に有利な製造プロセスにも関わらず
デスクトップ並みのシングルスレッド性能の高い版では
greenで上位に入れないのがx86の限界

詭弁だな。
それを言うなら京のVenusも2GHzでインオーダ実行だからデスクトップPCの
シングルスレッド性能には程遠い。

x86なみにシングルスレッド性能の高いCPUを例示してみてよ。

fmaddが無いだけ

>>509
POWER6さんの悪口はそこまでだ

BlueWatersって事実上x86（MIC）に負けたんだよな

>>512
でもPOWER7 は自身の最高クロックのままgreenで100以内に
いくつもランクインしていて、ある意味男らしい

SPECpower_ssjのほうには登録しないのがIBMクオリティ

,,・´∀｀・,,）っ-○○○ )´Д`；) Oh...

ワットパフォーマンス重視が頭打ちになったらどうするんだろうね…
現在のスパコン並のマシンがコモディティ化するだけかい?

シュリンクや回路の最適化など製造面での進歩がメーカーを問わず全ファブまで行き渡ったら、最も効率的なアーキテクチャ以外の演算装置は淘汰されるだろうか？

>シュリンクや回路の最適化など製造面での進歩がメーカーを問わず全ファブまで行き渡ったら
その前に非シリコン半導体が出てくるんじゃね
量子コンピュータはどうなんだろうな……

>>514
IBM「電力効率が悪いからPOWER7はPOWER6よりクロック下げます」
という経緯も知らないニワカは黙ってろ

>>510
え？普通にアウトオブオーダ実行だろ？

ああ、レジスタリネームが無いだけでOoOE自体はあるのね

いや、例のプレフィックス命令の作用考えれば広義の「リネーム」はあるか

1995年　SPARC64（無印）　out of order
1995年　PentiumPro　out of order

普通に論理/物理レジスタ 32/64、OoO、SMTだ

>>508
ARMさんもA64で増やしたし
論理レジスタは32本がミニマムじゃないかな?

>>505
シッタカの団子にそんな芸当はできないよ

論理レジスタが少ないとレジスタの使いまわしや早いフェッチの機会が少なくなるため、
物理レジスタがいくらあっても性能向上の余地は限られる。

整数演算ではあまり差はつかないが、きっちりスケジューリングされた浮動小数点演算では差が大きい。

団子の書き込みの半分くらいはデタラメだと思えばいいね。

「団子氏」って「団子虫」に似てるね
「団子厨」って団子虫からきたのか？

団子虫
団子無視

物理レジスタが多ければ大丈夫っていうのは
あくまで論理レジスタだけでspllingなしでプログラムが組める場合だよね

あとRSのエントリ数はCore2で32・SandyBridgeでも54で
これはレイテンシの大きいFPU命令やＬ２アクセスを隠蔽するには不十分
まだまだソフトウェアレベルのスケジューリングの比重は大きい

Haswellでもその辺の拡張は行ってくるだろうね
Core2→Nehalem→Sandyと各世代ごとで必ず強化されてる部分だしな

>>529
実際7割はデタラメだな

ソフトウェアパイプラインなんかは論理レジスタがたくさん必要だしね
あるいはIA-64みたいな支援が

OoOが優れているのはMemory Disambiguation等の投機的動作が可能なところで
静的には不可能ななアグレッシブなスケジューリングが可能になる

> 論理レジスタが少ないとレジスタの使いまわしや早いフェッチの機会が少なくなるため、

うーん、それこそデタラメだな。
君はその一言をもって、俺の指摘してるレジスタリネームの存在を全く理解してない
無知蒙昧なちんけな存在だと自分で証明してしまった。

たとえばAVXにおける倍精度4x4行列積のループの内側はこうだ。

vbroadcastsd ymm0, [rcx]
vmulpd ymm0, ymm4
vaddpd ymm8, ymm0
vbroadcastsd ymm0, [rcx+256]
vmulpd ymm0, ymm5
vaddpd ymm9, ymm0
vbroadcastsd ymm0, [rcx+512]
vmulpd ymm0, ymm6
vaddpd ymm10, ymm0
vbroadcastsd ymm0, [rcx+768]
vmulpd ymm0, ymm7
vaddpd ymm11, ymm0

なぜymm0を使いまわしてるのか君には理解できないだろうけどこれはこれでいいんだよ。
この場合ymm0はload(vbroadcast)によって依存関係を断ち切ることができるので
別の物理レジスタを割り当てて、後続のvmulも含めてパイプラインで実行可能になる。
もちろんvaddは反復するのでレジスタリネームによる並列化がきかないので、
FP加算器のレイテンシはなるべく小さく（この場合4以下）デザインされてなければならない。

つまりレジスタリネームは万能じゃないってことでしょ？
デタラメじゃねーじゃんw

CPUのアーキテクチャがわかるレベルの人が読める本で
GPUのアーキテクチャがよくわかるおすすめの本ってないですか?
ハードの本でもプログラミングの本でもよいのだが。

>>537
全然内容理解してないのな。

> 早いフェッチの機会が少なくなるため、

これがデタラメだって言ってるの。スケジューラのリソースのある限りいくらでも
レジスタ(この場合ymm0)を読み替えて先読みが可能。

ロード・ストアの帯域さえ十分なら、加算ユニットのレイテンシ×2＋α程度のレジスタ本数があれば
実用上問題ないね。Sandy Bridgeはストアが狭い（Bulldozerはもっと狭い）からできるだけ
オンレジスタで処理したいが。
逆に論理レジスタが多いほどレジスタリネーム機構の実装コストは大きくなる。



単精度行列積の場合も書いておく。
AVXのYMMレジスタでは8x8単精度行列は8本のレジスタで表現できるけど、こればかりは
こればかりは論理レジスタ16本は少し苦しくなる。
加算用に8本、被乗数用に8本、乗数ロード＋乗算用に最低1本でできれば17本以上は欲しい。
まあ入れ替えて処理するしかない。
加算用に8本、被乗数に７本、ロード+乗算に1本にして被乗数を入れ替えて処理すれば
Sandy Bridgeの持つLoad帯域的にはなんとか間に合う。

団子は日本語の理解力に少々難がある上に間違いを認めないから、何を突っ込んでも無駄ｗ

なんだかよくわからんがその書き方だと、レジスタリネームとやらを廃してレジスタを倍にすれば良いんじゃねって
素人は思うよ

↑と、日本語の読解力が無い馬鹿が言っております

>>541
vbroadcastsd+vmulpdの合計レイテンシが何サイクルあるか調べておいで。
ついでにいうと論理レジスタを増やすと退避のオーバーヘッドが大きくなってマルチタスクに弱くなるよ

>>539
レジスタリネーミングではコンパイラがスタック領域に割り当てする部分は
マップできないよ。だからそこがネックになるってのが一般論。
現代のプロセッサでメモリリネーミングをサポートしているのは製品としてはないよ。
団子先生の説明はレジスターリネーミングの通常動作の説明をしているだけで
論点からははずれている。

>>542
だからトーシロだつってんだろが
まぁ団子の文もうちょっと読みやすければ真面目に読むが

読み返したら大方わかったがな
俺が思ったのはレジスタの本数よりその並列化できない処理のレイテンシとやらを必死こいて削った方が・・・

素人考えだが。

> レジスタリネーミングではコンパイラがスタック領域に割り当てする部分は
> マップできないよ。だからそこがネックになるってのが一般論。
スタックに割り当てなきゃいけないほど変数使うコードって何があるんだよ？

顔真っ赤な団子ワロス

そもそもVenusのアプローチは「逸般的」ですし。
32ビットの定数をレジスタにロードするのに2命令かかるような命令セットが
一般的なアプリケーションの実行に有用なわけがありえない。

8では足りない
16でもやりくりすれば足りるが
24ぐらいはあった方が当然楽で
コンテキストスイッチのコストについては
数値演算では問題になることは少ないかなと。

数値計算用プロセッサにおいて一番大事なのは市場で低コストで調達できること。
それ以外の用途で全く使えない代物を作っても結局高コストでは意味が無い。

論点がずれてるｗ

団子の常套手段です

ところで単発IDの奴ってなんか意見ないの？

SSEの16本に比べて多いという印象は無いけどな
むしろシフトみたいにSSEなら即値指定すればすむ命令もAltiVecではわざわざ
ビットパターンをレジスタにセットしておく必要があったり。

いまどきレジスタの数が性能の決め手だとかいう主張自体が時代錯誤。



一般論として論理レジスタが多いほどコード密度は下がる。
RISCは時間当たりの処理量を増やしてペイする設計だったが、200X年代初頭には
そのアプローチは既に破綻してた。
クライアントサイドJavaの実行パフォーマンスはハイエンドのSPARCですら
Celeron搭載のWindowsマシンに負けていた。

>>551-552
論点ってなんだ？自分の読解力のなさを棚に上げるなよ。
レジスタだけ増やしただけの頭でっかちCPUなんてHPC以外では使えないって言ってるんだよ。

HPC以外で使えないことが、結果的に最先端プロセスルールでの製造単価を押し上げ
HPCですら居場所がなくなってきたのがベクトルプロセッサ衰退の歴史。
Venusはスカラベースでそれを再現しようとしてるにすぎない。

何でファミコンやセガマーク�Vは8bitCPUで発売しちゃったの？
当時既にPC用やゲーム機用の16bitCPUが出てたでしょ。

8bitCPUなんて先が見えてるし、
同じ仕様で長く売るゲーム機の性質を考えれば、
16bitCPUを採用した方が良かったと思う。

>>496から始まってるのに、なんでコストの話になってるんだよｗ　馬鹿すぎｗ
x86のコスパの良さの話をしてるわけじゃないからｗ

> 後、今はx86CPUでコプロのx87など使わなく、FPU性能もSpecCPUベンチを
> 見る限りじゃ他アーキと遜色ないのに、「x86=FPU遅い」の扱いをされてるのは
> 何故？

これが的外れだって言ってるんだが？
理論性能あたりのGEMMの実行性能比はレジスタ128本のCell-SPUなんかよりNehalemのほうが高い。

なんで「理論性能あたりの実行性能比」を出してくるの？

いや、既に単精度・倍精度ともに絶対性能でCore i7-2500＞PowerXCell 8iだしｗ
32SPEのCellはお蔵入りになったし結局は採算性が命運を決めるんだよ。

たしかVenusよりもSandy Bridge-EPのほうがソケットあたりのFLOPS数は上だったはず（同じ8コア）

SandyEPのFLOPSが増えたのはAVXのおかげだろ？
HPC向けに特化されたプロセッサと比べればx86は余分な物にトランジスタ割きすぎで
x86がコスパで最高峰なのは賛成だが、トランジスタ効率で負けてる

だから特化させたKnights Cornerが投入されると思っているんだが

> HPC向けに特化されたプロセッサと比べればx86は余分な物にトランジスタ割きすぎで
> x86がコスパで最高峰なのは賛成だが、トランジスタ効率で負けてる

同じような負け惜しみを前世紀末のRISC衰退期にも聞いた。

>>556
カセットビジョンなんて4bitCPUだったんだぞ、あの当時では8bitCPUは必要十分だ。
究極の8bitCPUゲーム機のPCエンジンがその後に控えているし

1982〜3年頃のトラ技の通販広告だとZ80が1000円未満なのに対し6809や8086は数千円、
68000やZ8000は数万円だったと記憶してる。
ボリュームカスタマーの調達価格は上記より遥かに安いのは当然だが、それでも小売で
一万円台のコンソールに当事の16bitCPUはコスト的に荷が重い。カスタムチップ用の
マクロセル商売が行われてたものが殆ど無かったってのも理由だろうけど

ぴゅう太に採用されたTMS99xxはパーツ屋の広告で見た記憶は無いな。コンパニオンチップで
ありMSXやセガSCにもさいようされたTMS9918（VDP）は見たけど。

後は1980年前後の16bitCPU全般について（命令語長のコンパクト化に特化したISAである
8086を例外として）コードが肥大化しがちでROMカセットのコストが嵩むとか、（外部8bitバス
バージョンの石ならOKだが）周辺やメモリも16bitにする必要があってそれもコスト圧力になる。

>>556
本体赤字で売ったらダメよ
ソニーのえらいさんもこう言ってる

久多良木
基本的には我々はハードウェアから限界利益をたたき出して、それを次に投資しているわけです。ソフトは1本約5000〜6000円ですが、みんながいつも年間で4〜5本買ってくれるわけではない。

そこから利益はとれるけど、年間ではすごい数字にはならない。その点ハードウェアの利益はすごくデカイ。
3万円のハードが年間2000万台出ると6000億円でしょ。末端で。6000億円で赤字出したら会社がつぶれますよね。

ということは、そこで利益をとって次の投資をしていかなければならないわけです。
半導体や部品を全部外から買うと、残るものはアセンブリだけですから、アセンブリだけなら日本よりも中国でつくったほうが安い。

そんなことをしていたら、ハードからは利益は出ない。うっかりするとハード1台売ると赤字が出る。

セガさんがそれで失敗した。PSはハードから黒字が出たわけですよ。我々はすべて中で設計して、中で付加価値を落としているから。
セガさんは日立やヤマハから買ってきて、何ら何まで外からとってきたから、苦しかったわけです。
メディアの人はそれがわからずに、「ゲーム機はハードで損してソフトで儲ける」とよく書く。
そんなこと私は1度も言ったことがないし、任天堂さんだってそんなこと言わないと思う。

16bitCPU、16bit対応DRAM、16bitGPU、16bitSPU、24bitバス・・・
80年代に16bit機を出したら、安く抑えても販売価格が3万5000円を超えるかも。

>>566
なにこの「お前が言うな」はｗｗｗｗ



京の何が駄目なのかはおごちゃんが2年も前に的確に指摘してるね
ttp://www.nurs.or.jp/~ogochan/essay/archives/2132

つか、コメント欄のこれが的確すぎる
> ついでに、米国はスパコンに年間1千億円以上つぎ込んでいるけど1品ものに1千億円もかけないとか、
> 勝ち目のないCPU事業から撤退の機会を逃した富士通は今後の技術競争で大きな遅れを取るだろうとか、
> 代替技術が多々あるのにそれに国費を投じないから全然育たないとか、
> あたりまで書いてもらえれば完璧かと思います。
> 2010/1/29 金曜日 22:15:53 | #11

>>566
＞半導体や部品を全部外から買うと、残るものはアセンブリだけですから、アセンブリだけなら日本よりも中国でつくったほうが安い。
＞
＞そんなことをしていたら、ハードからは利益は出ない。うっかりするとハード1台売ると赤字が出る。

任天堂だって、半導体や部品は外注だし、製造も最終組み立ても他社にやらせてるだろ。
任天堂とセガの違いって何？

>>569
ゲーム機の売れる値段が大体決まって以上
高価な部品を使ったら赤字

サターンはSH-2を1基だけ搭載予定だったのにPSが3D積むことがわかってから焦って2CPUに設計変更したからね。
DreamcastのSH-4は1プロセッサに戻している。

任天堂は64まではコストアップ要因だった光学ディスクドライブ搭載を見送った。

>>570
低所得一般人は1万5000円以下、中所得層は2万5000円以下、
ゲームに理解がある家庭や平均よりも大目の所得があるところでも、
4万円以下にならないとゲーム機を購入しないが、
ゲームマニアやゲームオタクなら10万円以下なら買ってくれる。

>>572
その層は何人くらい居るの？

いまどきのゲームの主要顧客って金にルーズで頭のネジの緩い20代女だと思ってるが

>>572
コアなファンがこぞってX68000を買っていたな

>>574
どのゲームを想定してるんだ？
携帯あたりかね？

携帯に限らずだけど、戦国BASARA（笑）以降、女性ターゲットの歴史物ゲームが増えたな
いまどきのアイテム課金ゲームに金落としてるのは大半は女だぜ

おごちゃん()

官僚の天下り先のITゼネコンに金垂れ流すための詭弁に耳を傾ける必要なんてなかった

>>573
日本だけで、ゲーム機に10万円出せる人は200万人くらいかな？
海外は知らん。

今は不況が続いていて可処分所得が低下しているから、
昔よりは減っているだろうな。

>>575
ネオジオとX68000って、結局何台売れたの？

信頼できるソースではないが、
X68k 12万台
ネオジオ 100万台
ってとこらしい
ネオジオCDは知らん

>>581
ゲームに大金を出せる人口はだいたい100万ちょっと程度か。
こんな小さな市場ではサードもあまり参加してくれなさそうだしキツイね。

せめて、5万円以下に価格を落とさないと厳しいかな？

ネオジオは息が長かったが、発売は1990年とバブルの頂点なんだよな
X68kは1987年

しかもバブル当時は、ネットだの携帯だのPCだのに金を使わなくても生きていけたから、
その分ゲームに割けるお金はたくさんある。

>>580
200万人だと、ゲーム以外に浮気もする人が入っている気がする。
他にどんな面白いものがあってもゲーム機に10万出す人は10万人くらいじゃないだろうか

>>585
自宅でアーケード基盤を遊ぶ人、PCEのコア構想に最後まで付いていった人、
劣勢のセガの応援を最後までやめなかった人、
PCゲーの為にGPUを半年に一度買い替え、
PCを一年で買い換える人が居るから、
10万円のゲーム機を買う人はもっと多いだろうと思うが。

PS3はあと5年売っても累積赤字は解消しないだろうし
製造原価5万オーバーのゲームハードは未来永劫ないだろう。

なんだかんだで携帯電話ってコンテンツホルダーには事業展開しやすいと思うよ。
ポストペイの決済システムが簡単に利用できるし。

>>584
パソコン通信で電話代が月に数万円

>>586
そういうのは大体被ってるだろうな

そもそも今の若い世代のホームエンターテイメントの中心ってテレビ・ビデオ・ステレオデッキじゃないから。
情報端末はPC、録画よりネット配信、音楽はiPodみたいな。
据え置きゲーム機ってそろそろ潮時じゃね？

>>590
据え置きゲームは確かにな

pcでFF13やりてー・・・

若者はPCすら持ってないような気も
家に一台くらいはあるだろうが

NPD November 2011 Sales Results
NPD Coverage: October 30 - November 26 (4 weeks)

Overall:

Total retail sales: $3 billion (+0.4%)
Total non-PC retail sales: $2.93 billion (-0.5%)
Total software: $1.74 billion (+16%)
Non-PC hardware: $982.4 million (-9%)
Non-PC software: $1.67 billion (+15%)
Accessories: $273.8 million (-34%)


PCゲーの市場小さすぎるだろ
新箱がでればPCゲー市場はもっと小さくなるんじゃないの

2011年の世界半導体売上高ランキング、IntelがSamsungに大差を付けてトップに
http://eetimes.jp/ee/articles/1112/06/news028.html

nvもteslaやtegraに力入れるわけだ

汎用機(PCや携帯)が安く、速くなったと
ゲーム専用機ってワープロ専用機なんだよ

PCも携帯電話も、金の出所が娯楽費とは別枠なだけで、別に安くはないな

>>590
1本のゲームへ100億円かけても回収できる海外のAAAタイトルが
そう簡単に衰退するとは思えんな
NPD11月分みてもまだまだユーザーのAAAタイトルへの支持は落ちてないみたいだし
スマホと違って100W消費しても許されるコンソールビジネスはあと5年はもつだろ
MSの次期Xbox次第だが

差別化が厳しい。
例えばCPUを3コアから6コアに増やしたら、ゲームの何が変わるのか?
差別化出来ないとプラットフォームの立ち上げもできない。
立ち上げられなければ、タイトルに100億円の投資も出来ない。

そもそもIBMはPowerPCの改良と製造プロセスの微細化をどこまでやるのか

http://farm8.staticflickr.com/7010/6484070331_326e6cecb5_o.jpg
http://farm8.staticflickr.com/7143/6484011965_daeb245f63_o.png
http://farm8.staticflickr.com/7144/6484012041_de53004dd2_o.png
http://farm8.staticflickr.com/7026/6484012179_77b418b49b_o.png
http://farm8.staticflickr.com/7009/6484012229_188e8f31aa_o.png
http://farm8.staticflickr.com/7141/6484011989_493d11632b_o.png
http://farm8.staticflickr.com/7170/6484012099_2a13bbdde7_o.png

VGA 2011: Exclusive Debut Trailer
http://www.gametrailers.com/video/vga-2011-the-last-of/724687

髪の毛のさらさら感とか肌のしっとり感とかやっぱり追求しだしたら
より高性能なプラットホームに加えて低価格にして普及台数も欲しい
PCでは厳しいわな

メガドラも結構アーケードっぽい作りになっていて、その成功体験がサターンにつながったんだと思う。
セガにだってコスト意識くらいはあったろうが、他社にくらべて甘かったんだろうね、やっぱり。

PC-FXは20世紀の七不思議の一つです。

何を考えてゲーム機作ろうがCPUカスタム化からやってる相手と競争したら
ビジュアルで見劣りするのは目に見えてる。
ならマルチCPU化というのはわからん話ではないだろう。
当時セガが使えそうな組み込み向けでこれ以上高性能なのあっただろうか？

>>591
＞pcでFF13やりてー・・・
激しく同意。
10万くらいのGPU買ってもイイから、PCで超ハイクオリティなゲームを楽しみたいお。

ソニーのようにCPUに手を入れなかったのが設計思想の違い。
セガの設計思想が間違っていたというわけではないが、トータルではPSのほうが優れていたと言わざるをえない。
SSの2D性能は捨てがたいけどね。

>>604
ついでにテッセ使えるようにすればスノウのアゴヒゲのジョリジョリ感が増したり色々とメリットがありそうだ

》602
PC-FXはGPUの開発が間に合わなかったため、JPEGエンコーダとPC-EのVDP(死語)だけを積んで出荷した

>>605
どうやって玩具メーカーがCPUに手を入れられるｗ

ソニーの参入がなければセガの圧勝だったんだけどな。

ファミコンですらCPUコアに手を入れているというのに、なぜできないと思うんだろう

>>608
任天堂は64やGC（Wii）のCPUにカスタム命令追加してるけどね。
SH-4自体がDreamcastのために作られたようなもんだし、自社設計はしなくとも
設計に影響を与える程度の力は持ってる。

なんせゲーム機は同じ仕様でまとまった数が出せるし、ドリキャス撤退後も
SH-4はしばらくはアーケード基盤やパチスロなんかで使われた。
更には三菱のカーナビとか。

むしろVitaのCPUはARMのCortex-A9のIPそのまま使ってるじゃん。

今のモバイルCPUだと昔とはカスタム化の必要度が違うわな

アレはGPUとメモリ周り弄ってるらしいから
それが今時分の携帯ゲーム機の勘所なんだろうな

>>607
それについては岩崎啓眞がデタラメだと主張している
音源までPCエンジン並なので、根本的に間違えたハードと言わざるをえない。

もっと信じられないプランもあったしなあ

>>615
どんなプラン?

サターン開発時期って、Model 1か2あたりが出たばっかか開発中なくらいだろ？大雑把に言って
当時のセガは、3Dハードの試行錯誤期だったんだろうと思う

SH-4はこのあいだまで使ってたケータイに入ってたな

今は8250スマホだが

8255ならこのあいだまで使ってたパーコンに……

もう30年になるのか。

HPに封印されたAlpha、復活しないかな。
中国あたりでデッドコピーが出たら面白そう。

Alphaは元DECチームによる最新の実装に価値があるのであって
今更復活しても

>>611
SH4って4個のfloat値の加算がスループット１でできるんだよな
掛け算より簡単なのにIntelは徹底的に嫌がってるよな

alphaは実装が優れてただけでなく、コンパイラも圧倒的に良かったらしい

>>622
LNIにはあるけどね、リダクション

>>623
何がダメで終わったの？

マーケティング戦略かな

>>625
性能上の問題ではなくDEC→Compaq→HPの買収に伴う企業戦略上の都合（Itaniumへの移行）。
Compaq→HPの買収以前の時点でCompaqの判断によりAlphaの終息は決定してた。

>>625
欠点は売れなかったことくらいだね

発熱もすごかったけどね

初期のAthlonはx86版のalphaといってもいいんじゃないの

終盤のAlphaはAMDのチップセットと組み合わせた安めのモデルが売られたりしてたな
20万くらいだっけか

>>622
水平加算のhaddps、内積のdppsなどあるけど何が嫌がってるって？

技術的な詳細は頭が足りないので分からないが、ロードストアとALUがセットとか、大容量で2wayセットアソシエティブなL1キャッシュとかでAthlonはAlpha 21264的だ

DECでAlpha造ってたアーキテクトがAMDに移籍して作ったんだっけ？

インテルじゃね？
訴訟でインテルがalphaの工場買収することで和解したはず

ちなみにAMDの高速化の原動力はNexGen

AMD旧CEOはDECの出身だろ

NexGenはK6じゃないの？
K7はダークメイアとか旧DECのメンバーの力が大きいと思ってた

>>635
インテルが獲得したのは「Alpha」以外の全半導体の製造・販売の権利だべ

K7はバスがまんまEV6バス（元々Alpha21264用のものをDECからライセンス供与）
だったから>>631のように21264＋AMD751/761とかが可能だったわけだしな。

HyperThreadingもHyperTransportもDEC由来でおｋ？

>>639
ググってみたけどＡｌｐｈａも含んでたね
この訴訟は当時から不思議に思ったんだけど和解する大分前から
「DECが工場をインテルに売却して和解する」って道筋ができてるって報道されてたんだよな
何のための訴訟だったんだろう？なんで売却が和解になったんだろ？

>>638
AMDの躍進はK6から
それまではCyrixの後塵を拝する互換メーカーだったが
K6からインテルのライバルになった

>>641
HTTについてはどうだか知らんがHyper TransportはEV6バスの発展系だからDEC由来だな。

半導体の製造、設計を辞めたかったらだろ
Alphaの投資を続ける気がなかった、
Intelに工場とチップデザインを買わせるのが、訴訟の唯一の目的だったと
Alphaを本気で続けてたら、Windows NT 4.0,Windows 2000 for Alphaが出てただろう
(Windowsの非X86への、実際の移植作業はMSでなく、各CPUベンダがやってた)

>>633
21264で画期的だったクラスタが受け継がれなかった

Alphaの設計者は散らばってしまい
Itaniumをやっている人もいる

》645
クラスタじゃないの？
一つの整数レジスタファイルに3ALU,3ロード/ストアがぶら下がってんの？
だとしたら驚異的なクロック

>>647
Reservation Stationは各実行ユニットについているが、整数レジスタファイルは一つだけ
データの多くはバイパスで供給されるから、見た目ほどレジスタファイルへのプレッシャーはない
バイパスの遅延もない

21264はレジスタファイルをクラスタごとに持っているし、クラスタ間はバイパスの遅延もある

なんかアーキテクチャスレっぽくなってきた

ふむ、心地よい。

>>632
SandyBridgeのdppsってスループット1化してたのね
一方でhaddpsはスループット2だったりして不思議

haddps/dppsはCore2の頃は何のためにあるのかわからん命令だったけど
ちゃんと高速化されてるのね

うおー、水平加算のスループット高いんか！
そりゃうれしい！

けど、適用したいところの処理、メモリアクセスがネックで有難味激減（涙）

プレス子になってやっと搭載だもんな
何考えて設計してるんだろ

シャッフルユニットが強化されたのもCore2 45nm以降だし
SOAが基本で水平演算は非推奨って姿勢だったんじゃない？

haddps,dppsにしても一応あるというだけで
Latency/Throughputは使い物にならなかったし

march haddps dpps
Prescott 14/6, NA
Core2 65nm 9/3, NA
Core2 45nm 7/3, 11/3
Nehalem 5/2, 11/2
SandyBridge 5/2, 12/1

しかし着実に速くなってるね

>>642
> 何のための訴訟だったんだろう？なんで売却が和解になったんだろ？

特許侵害ではIntelに勝てることが確実だったから
DECは、莫大な設備投資にもかかわらず稼働率が低くて重荷の半導体工場を特許と一緒に売りつける目的で
特許訴訟を提起したんだよ。

大量に売れる製品ラインを持っていないことには
巨額の設備投資を必要とする最先端半導体工場を作り続けることが
不可能な時代になったということです。

AMDなんかはブルドーザーでやっとサポートしてもマイクロコードで遅いな

>>643
HTTはP4に最初から搭載されながら無効となっていたとされるが、
Xeon用かなんかで有効になる前に、CompaqからEV6バスのライセンス得て
それと抱き合わせでHTTがokになったと記憶している。

しっかし、alphaってDESの付属品にあったっけ。
PCIブリッジとNICとStrongARMはオマケで付いてきたけど、
alphaは製造Samsungで、半導体工場とは別だったような気がする。

QPIの開発も元DECの人たちが中心だったんだっけ？

元を辿れば全部ユダヤ人です

もう30年になるのか。

>>646
AlphaのチーフアーキテクトだったRich Witekは最近AMDに帰ってきた。
元々DECでPRISMプロジェクトというRISCをDave Cutlerらとやってたが、DECはMIPS採用したので、これは中止。しかしそのあと、AlphaやStrongARMの設計をやって、DECが消えてからAlchemyってMIPSの会社を起こした。
このAlchemyがAMDに買収されてRichも移って来たけど、この部門も売られちゃった。その後、Microsoftに身を寄せてたようだけど、最近AMDに復帰したみたい。
Rich先生の次回作に期待したい。

>>643
HypertransportはDECからスピンアウトしたAPI NetworksっていうHPCベンダーで開発始めて、その会社ごとAMDが買っちゃったンだよね。

DECの遺産はでか過ぎてﾜﾛｴﾅｲ
こんな偉大な会社まで退場させられちゃうんだからほんと厳しい世界だわ

PCE、MD、3DO、SS、PC-FX、DC、XBOX360、PS3、wiiと、
技術の転換期に慌てて発売したハードは必ず失敗する。

技術の転換期じゃない時期っていつよ

慌てて発売したハードがあったときだろ

なかったとき、の間違い

>>663
トップシェア取れなかったコンソールは全て失敗なんだなｗ

>>667
そういうわけじゃないよ
トップシェアを取っても失敗ハードは失敗ハード

＞XBOX360、PS3、wii
つまり今世代機はすべて失敗作、と

>>669
Yes

ゴミハードしかないときは覇権ハードも現れないし市場も縮小する

PCEとかSSとかはハード設計的には別に間違ってないだろ。
むしろSFCの方が
＞技術の転換期に慌てて発売した
には該当する。失敗してはいないけど。

>>663
GCが入ってない時点で妊娠乙としか言い様が無いな。てか、ゲハでやれ。
MDと箱○はWWでは成功したハードだと思うけどな。

メガドラが失敗作であることに異論はない。
だって色がにじむんだもの。

メガネをかけた女子高生がドラッカーを読んだら

文字が滲んで見えるよ

>>673
RGB化はデフォだろjk

PS3とXbox360は失敗っていうか、出さないと相手だけ出して自分は負けるから出さざるを得なかったんだろうな。
両方。

なんかアーキテクチャスレっぽくなくなった

>>677
PS3側が有利な立場にあったのに、cellだのRDRAMだの旧式GPUで墓穴を掘ってしまった

アーキテクチャとかなんも知らん奴が語り出したな。
特にID:FGSWq+oNの無知っぷりは酷い。

結局、話題の行き着く先はゲーム機なんだよな
PCってなんだろうねｗ

>>681
きみにはいらないものだよ。

>>680
俺はアーキテクチャの話はしてないよ
死ねクズ

くだらねースレチの話延々引っ張ってその態度とかエラでも張ってそうなくらい面の皮が厚いな

ゲーム機のCPUはその時代の最先端の技術が投入される
ハードウェアはコンソール機の10年間のライフサイクルにおいて唯一変更不可能なものだからだ
でっででーででででー
やんまーにやんまーにやんまーにやーいーやー
れ

http://pc.watch.impress.co.jp/docs/2003/0909/kaigai019.htm

＞その意味では、Cellコンピューティングは、現在のコンピュータアーキテクチャに対する挑戦とも言える。
＞Cellコンピューティングで、Wintel主流のコンピュータアーキテクチャをひっくり返そうというわけだ。
＞そう考えると、PS3のためにCellコンピューティングがあるというより、Cellコンピューティングという大きな構想があり、
＞その最大のアプリケーション(けん引車)としてPS3があると考えるのが正しいと思われる。

＞インターネット上でCellコンピューティングが実現すると、最終的には、
＞「地球シミュレータ(地球環境をシミュレートするスーパーコンピュータ)の1万倍とか10万倍」(久夛良木氏)の
＞コンピューティングパワーも実現できるようになる。

＞例えば、映画「マトリックス」の仮想世界のようなシミュレータを、いつの日か実現することも可能になるかもしれない。

>>686
現実を無視した机上の空論ｗ

久夛良木は世のプログラマの多数派を過大評価していた。
Cell くらい使いこなしてくれるだろうと思っていたら、
大量の使いこなせないやつらがけなしまくって
短所だけクローズアップし長所はシカトされた

使いこなしたらハックされまくったやん

GameOSをクラックして乗っ取るのとCPUアーキテクチャを使いこなすこととは別だろ？

当世代機の実機より速いエミュはAlphaの奇跡だったな

なんでこんなにスレ違いなん

>>692
コンソールゲーム機のハード技術を自慢したいゲハ板住人が紛れ込んでるから。

》691
21164 500MHz with FX32!はPenII 233MHzよりWin32アプリが速いということだけど、実際はそんなに速くないと思う
ちなみに今風に言うとエミュでなくCMSだな

>>688
誰も使いこなせないアーキテクチャは優れた部分も活かされないという証明になったな。
本来はCellでグラフィック処理も賄うつもりだったのにそれがまずできなかったし。
結局使いこなせたのはIBMくらいか？ 3DバリバリのゲームでもSPEは1や2しか使ってないのが多かったし。

Cellみたいな何でも集中型のプロセッサは絶対に上手くいかない
世のトレンドは分散型

Cellってアーキテクチャとして処理分散型じゃね

ゲームプログラマには超並列演算は難しかったんだろ。

Cellはちょっとエミュで触ったことあるけどC言語で開発するあたりがダメだな。
東芝が専用言語作ってたらしいが、それくらいしないと開発が死ぬ。
Itaniumと違って思想は悪くないし、開発環境を整えるとかもっとやり方はあったんだろうに。

CellのプログラミングってCUDAよりも厄介？

スパコンでの経験があるやつに言わせればGPGPUのプログラムなんて簡単らしいで。
PCとかコンソールでの経験しかないプログラマには厳しいよな。

>>695
SPEは１や２しか、ってどんなだよｗ

あれこれ小難しいことしてSPEに仕事投げなきゃならんCellよりは
普通に組んでコンパイラ任せのItaniumのほうがよほど使いやすくていい気がするけどなあ

あれこれ凝りすぎてクロック上がらないとか大規模過ぎて開発が遅延に遅延を重ねたとか
プロセッサそのものはアレだけど…

【GTC AGIA 2011レポート】
“2019年のPlayStation”の姿を紹介
http://pc.watch.impress.co.jp/docs/news/event/20111215_498851.html
Ubisoftが製作した「Assassin's Creed Revelations」の予告編映像。
この映像は、現在のスパコンを使って1フレームあたり1時間をかけてレンダリングしたもので
、そのクオリティは実写と見まがうばかりだ。先に紹介したワットあたりの性能の向上当てはめ
ると、2019年には100W、すなわちPlayStation 3クラスのシステムに数十TFLOPSの処理能力
が備わる。つまりフアン氏は、「2019年のPlayStation」ではこれがリアルタイムでゲーム画面とし
て動かせるようになると述べ、聴衆から大きな拍手をうけた。



どうです凄い時代になるんですよ

>>703
もちろんItaniumがゴミなのは開発効率じゃなくて速度の話ね。
そもそもコンパイラ任せという考えからしてゴミだし。
Cellは少なくともヘテロジニアスマルチコアというトレンドにはマッチしてる。

トレンドにマッチですか…

>>701
んなことない。ピンきりである。研究者の宣伝に騙されて、
スパコンに変な幻想抱きすぎ

>>697
CPUの中にGPUもSPUもぶち込んだプロセッサだから集中処理型でしょ。
CellはUMAを採用して爆死した任天堂64並みの失敗作。

CPUの中にメモコンもGPUもぶち込んだintelとAMDのCPUは皆失敗作ってことになるが。

>>709
それはモバイル用で、パフォーマンスよりも、
発熱や大きさ、消費電力などを優先してるんでしょ。

Cellとはちょっと分野が違うんじゃない？

完全体になり損ねたCellか･･･

>>710
デスクトップ用でも普通にGPUもメモコンも内蔵してるだろ。
お前最近のCPU知らんのか？

>>712
メモコンは入っているけど、GPUやSPUまでは内蔵されてないでしょ

GPUや動画再生まで入ってる
ちなみにCellにはGPU内蔵されて無い

>>713
Nehalem（Clarkdale）のi5以下とSandyのLGA1155はデスクトップ向けでも
メモコンとＧＰＵ内臓だしLlanoも（特に上位モデルは）モバイル専用じゃないが

Intel HD GraphicsはGPUと呼ぶに値しないって俺理論かｗ

知らない(あるいは忘れた)ことは仕方ないけど、どうしてそう偉そうに断定するんだろう

SPUってなんの事かと思ったらPSの音源チップか
CellのSPEと勘違いしてる？

Ceiiってサウンドチップも内装されてるんじゃないの？

CPUが俺の知らない間にそこまで進化しているとは知らなかった。
専用のGPUの他に、CPUにも軽めのGPUを内装する時代なのね。

>>708
CELLにGPUが搭載されているならPS3の中のRSXは何のために入っているんだろうか。

クタタンのCell構想の失敗の穴埋めの為じゃね？

>>718
軽めってアンタ……

Intelですらオンボードどころかローエンドグラボ以上の性能をCPUに内蔵済みですが。
過ぎのIvyではDX11対応に性能30%以上向上とかしてくるし。

>>721
将来はGPUが廃れますか？

８面マルチとか4k2k解像度になるから廃れることはない

ID:kcT0dC64
この子おもろい

>>723
4k2k解像度のディスプレイやスーパーハイビジョンテレビを8台並べて、
一つのマシンで表示しようとするおっさんや兄ちゃんなんてふざけている。

普通に考えて、精々多くてもGPU一機につき4面マルチまでだな
（それでも多いが）

Eyefinityという技術があってだな

おっと、Parheliaの悪口はそこまでだ。

ベクトルスパコンは、ベクトルレジスタ間接アドレッシング&多wayインターリーブがあるから、GPGPUよりはプログラム楽だろ
情報処理試験の議事言語しか読めないから知ったかだけど

で、ベクトルスパコンでも、実際に動いてるコードのベクトル化率は50〜60%程度
SIMDってのは本質的に難しい
それが簡単だったら、今頃x86もPowerもSPARCも8wayくらいのFMAC SIMDを実装してるだろう
ベクトルからMPPやRISC WSに数値計算の主流が移行したのも、コストパフォーマンスだけでなく、ベクトル化率を100%近くに持ってくのが極めて困難だってのも大きい(らしい)
SIMDでなくMIMDが並列処理の主流なのですよ

大容量ベクトルレジスタ、高byte/flopメインメモリの機種が少数派になったのは
LINPACKのFLOPS/$ が割高なことによって
ハイエンドプロジェクトの絶対価格が高くなりすぎて企画できなくなったからだよ

アカデミックなユーザーが欲しいのはMIMDじゃなかった。
しかたなくMIMDへ移行させられた。今はもうどっちでも

つーか、ベクトル化できるかどうかは、変数間の
依存関係なんだから、依存関係が原因でベクトル化できない
アルゴリズムはMIMDによる並列処理システムでも待たされる

ベクトル機ではループの直前のイテレーションに依存する計算もそこそこ性能が出る

>>728
> ベクトルスパコンは、ベクトルレジスタ間接アドレッシング&多wayインターリーブがあるから、GPGPUより
それCUDA対応以降のGeForce/Teslaで普通にサポートしてるからｗ
むしろスカラ対応のユニット・レジスタセットがないからそれしかできないけど。

>>654
努力は認めるが中途半端なCPUを何種類も出されても迷惑だよな
PowerPCのAltiVecなんてG4時代でもdpps16回分の4*4行列積が30サイクルで出来るんだから
手抜きでなかったらアホとしか言いようがない

自分以外はみんなアホ

むしろ4x4行列積にdpps使うとかアホとしか言いようが無い。

Pen4までならmulps+addpsで転置行列積を求めてshufpsでtransposeが常道です。
Core2以降なら3命令＋Load同時発行できるからbroadcast+mulps+addでもOKだけど。
むしろAltiVecとかCellでも都度内積演算×16なんてやって速くなるわけが無いだろ？
アホほど自分のアホさ加減を棚に上げる。

コイツの読解力って凄まじいな

>>737←こいつとりあえずコメントしとけば誰かから同意が得られると思う無能ぶりがにじみ出てるな
4x4行列積を求めるのになんでスカラ内積を使う必要があるんだ？

AltiVecで水平演算なんて論外レベルの遅さですし

日本語理解できないなら黙ってろよ

G4のAltiVecってレジスタリネーミングどころかアウトオブオーダ実行すらないし、なにより
FSB133MHz（笑）でPentium IIIの半分どまりだったから、いくらクロック当たり性能をアピールしようとも
実性能ではSSEに及ばない代物でした。これが現実。

MPC7450系コアで1GHz越えた頃にはFSB400MHzオーバーのPentium 4やPentium Mが出てて
足回りの性能は更に差がついてた。

>>740
お前は小学校のあいうえおからやり直せ無能

いいぞもっとやれ

>>730
えー！
ってことは、マルチコアでスケールするのなら、原理的にはGPGPUでも速度出るってことなの？

>>732
メモリの多wayインターリーブがないから、GPGPUでベクトルレジスタ間接してもたぶんあまり意味がない

> メモリの多wayインターリーブがないから、
え？

》741
レジスタリネーミングはやってる(PowerPC7450のFPUはリネーミングレジスタ16本！たしか)
FPUとAltVecは限定的OoO
詳しくはフリースケールのホワイトペーパで
あと、おれにはわからんがSSE3よりはAltVecの方が洗練されてる、とされている
PowerPC G4のコア自体はPentium IIIと同等の実力だ

製品レベルのクロックで倍の差がついてたのに同等ってのは無いだろ。
7450のほうは出るのが遅かったの一言につきる。

命令セットだけは綺麗に見えるけど実装にどこそこボトルネックがあって
使いにくいのがAltiVec

高機能なのはいいのだが、欲張りすぎて将来の性能向上の足かせになるのがモトローラの伝統

ロードマップに餅の絵を描くのも伝統だね

6809も一見直交性があるが、プリバイトなんてのがあってレジスタに差がついていたりする

AltiVecってPPCアーキ最大の害悪だろ。
クロック向上をもっとも阻害した要因。

ハードの実装コストが高すぎて180〜90nmプロセスの時期にはどう考えてもオーバーテクノロジー

別にAltiVecのせいでクロック上がらなかったとは思わないけどな。
G4+を出すのが遅すぎただけ

初代G4からしてクロック50MHzずつ下げて出荷とか最悪の出だしだったけどな。
クロックが上がらない呪いはG5にも伝染してるし。

モトローラ88000もいろいろおかしなところがあったプロセッサだが
浮動小数点演算を汎用レジスタ上で行うところが最大の謎
頭おかしいんじゃ、と言われていた
次の88110では独立した浮動小数点レジスタが増設された(80bit)

>>744
往年のベクトルスパコン　数byte/flop
GPU（M2090）　0.27byte/flop。違いすぎ

68040は25MHzで登場した。
順調にクロックを上げていったが、ある日突然33/66MHzという表記にかわった。
i486DX2の登場後だったので、モトローラも対抗して倍速版を出したのかと思ったが、
68040は最初から(一部)倍速とのことで、マーケティングの理由での変更だった。

むろん早期に倍速駆動させた技術はすばらしい。
しかし最初からトップギアだった68040はi486DX2に抜かされてしまうのであった。

以上の事情によりクロックあたりの性能の優劣はわからないのだが、
リリース当初では、68040/25のほうが80486/25より速かった。

68040は1.2M Tr、80486が1M Trと68040が多少規模が大きい。

キャッシュは68040の4+4KBの分離キャッシュに対して80486の8KBの統合キャッシュだった。
68040は分離キャッシュの上、invalidate cache命令が特権命令だったので、
命令の自己書き換えをするためにはキャッシュをinvalidateするシステムコールを呼ばなければならなかった。
(もちろんプラットフォームに依存するし、そもそもあるとは限らない)
JavaVMのJITコンパイラのkaffeのソースにも「68040はbrain damaged」と書いてあった。
インテルは今日にいたるまで命令の自己書き換えをサポートしている(はず)

68040のFPUは超越関数がごっそり削除されてしまった
インテルは今日にいたるまでx87の全機能をサポートしている(はず)

MMUについては68020+68851、68030、68040とどんどん貧弱になってしまった。
68851は5段の変換や最小1バイトのページサイズもサポートしていたのに。
NetBSD/Amigaのソースにも"68040 MMUはbrain damaged"と書いてあった。
(どこに悪態をついているのかは知らない。おそらく簡素化しすぎて面倒なことになったんだろう。)
もちろんインテルは今日にいたるまで386 MMUの全機能をサポートしている(はず)

要するに、PCやゲーム機の分野に於いては、
モトローラ、ARM、アップル、ソニー、NEC、日立、リコー、AMDのCPUは負け組みで、
インテルのCPUだけが唯一の勝ち組って事？

ARMはこの互換性保持無間地獄に耐えられるかな

>>744
ベクトル型にしてもGPU的な多スレッドにしても問題は
演算途中の実行コンテキストの総量が大きくなってしまうこと

普通のCPUであればスレッドあたりのテンポラリが数十kB程度であっても
L1か悪くてもL2は必ず入る
一方でGPUだと演算器のレイテンシを隠蔽するだけでSMあたり数十〜数百スレッドを
走らせる必要があるからそのままだとオンダイメモリには全く入らない

GPUでインフライトのスレッド数が多いというのは貴重なオンダイメモリを
寝ているスレッドの実行コンテキストの保持のために使ってしまうということ
そしてオンダイメモリに入りきらない分をDRAMに盛大に撒き散らす

ベクトル型はそれを広帯域・多ウェイインターリーブの主記憶でどうにかしようとしたが
メモリ帯域が相対的に高コストになってきたからすでに破綻している

GPUはDRAM量が小さいので比較的安価に帯域を稼げるがそれでもB/Fは非常に低い
GPGPUで速くなってるとされるプログラムの結構な数は
単純にGDDRの性能分だったりする
FPU性能を生かす事ができるのは一部のアプリケーションに限る
それもプログラマが気合で頑張る必要がある

トランジスタのメモリ帯域に対する相対的コストは年々安くなるから
(GP向けの)GPUも何でもかんでもマルチスレッドで隠蔽するんでなくて
分岐予測やHWプリフェッチを入れてく方向になってくんじゃないかな

おまえプロだろ。
自作板でもここまでのレベルのやつは久々にみた。

>>759
GPUのアーキを理解するのに一番おすすめの本教えてよ

＞トランジスタのメモリ帯域に対する相対的コストは年々安くなるから

IBMはCPUが活躍するために記憶域階層をお膳立てするのではなく
ストレージにCPUが群がっているような図を描いてるな。

ハードの設計もプログラミングも、
演算手順が主で記憶領域設定（配置・移動）が従から
データの配置、移動が主（パフォーマンスを決める）で
演算はデータが置かれるだけ、通過するだけでなされる従に
なっていかざるをえないのかもしれない

近年その発想で汎用業務アプリのSEがHPC分野をやろうとするから失敗する
プログラミングの重要性が理解できない

>>762
それが言えるのは大規模行列演算やDBだけ
確かにアーキに与える影響は大きいが
ソフト側に与える影響はそれほど大きくないのでは

>>762
データフロー・アーキテクチャって何十年も前から概念は提示されてて一部DSPなんかじゃ
実現もされてるけど商用汎用プロセッサじゃまだ実現してないよな。

>762　は略しすぎたが、エクサスケールとかそういう方面、
全てのコンピューティングがそうなるとは思っていない。

>>765
OoOが限定的なデータフローモデルの実現じゃない？
データが届いたものから計算する訳だから

>>767
昔はrestricted dataflowといってたな。
http://www.cs.clemson.edu/~mark/hps.html
> Modern superscalar processors like the HP PA 8000, IBM/Motorola PowerPC 604,
> Intel P6, and MIPS R10000 are built around a dynamically scheduled microengine.

ちなみにこの論文はCISC命令(ここではVAX)をuOPsに分解して実行することを西側で最初に提案した。
> This style of design has often been referred to as restricted data flow [PHS85]

ありゃ、引用の途中に文を入れちゃった

>>762
> データの配置、移動が主（パフォーマンスを決める）で

メモリ階層や分散メモリなどで、すでにそうなっている

もし団子が756, 759くらいのことを言ってくれたなら

結局はインテルの一人勝ちで、世界中がインテルに土下座しないといけない状況でつまらない

ARMがHPCやサーバーでも、将来的には2割程度のシェアを獲得するんじゃないかと思う
ARM V8はalphaやMIPSなみにシンプルな命令セットっぽいので、対x86で30%以上は高速化のアドバンテージがある(たぶん。楽観的予測)
最終的にはIntelの50%のTDPで50%の性能くらいはいくんじゃないか？(希望的観測)
マルチベンダーのARMが、シングルベンダーのx86に対抗できない理由はない
IBMはPowerを捨てて、ARMで行くべき

スマートフォンやタブレットPCでは逆にインテルがARMに土下座しなきゃいけない状況

>>771
少なくとも命令セットとかアセンブラの話してる時だけはまともだろ

これが他の話になると主観入りまくって言うことがコロコロ変わるか予想を外すだけで
1年ぐらい前はCUDAディスりまくってたのにいつの間にか手のひら返してるし…

Power（PPC）よりARMが優れてる理由はどこにも無いですよ。
組み込み向けの実装ではむしろPPCのほうが電力効率いいこともありますし。

あと、未来のコンピューティングでARMの他に外せないのは量子コンピュータだ
量子bitの大型化、低価格化、量子コンピューティング適用可能なアルゴリズムの発見で、数値計算カーネルの多くをオフロードするだろう
量子コンピューティングは車輪の再発名っはない、破壊的イノベーションだ
ノイマンアーキテクチャに、ひょっとしたら全面的に取って代わるかもしれない、そんな革命

酔ってるときにカキコすると気持ちいいな

コンディショナルレジスタ操作+分岐より、比較条件分岐一発の方が、たぶん性能出る
じゃなかったらMacro opsフュージョンなんかやらない(良い比較じゃないか？)

ARMベースのISAでx86並みのパワーレンジにスケールアップしたとしてPowerPC G5の二の舞だと思ってる。
デコードコストの高さは1命令のオペレーションの密度で十分ペイしてる。
オペレーション密度の低さをクロックを上げたりIPCを上げたりしてカバーするアプローチは破綻してるし。

まさかARMの64ビットISAってプレディケートビットが大幅に削られたの知らないのか？

分岐予測の強化とコンディショナルムーヴで、プリディケードのほとんどをカバーできる

一番破綻してるのは、C2Dで極みに達したのに、なおIPCを上げようとしているIntelのアプローチだ
おれは直感する
デコードコストは命令密度ではカバーできない
命令密度が問題なら、L1キャッシュを増やしてフェチのレイテンシを伸ばせばいい
この方が複雑な命令を多段デコーダで解読するよりずっと簡単なソリューションだ
命令密度がIPC向上に寄与するなんてのはIntelの詭弁だ
教科書的というかalpha的命令セットが、コード密度や速度の最適解(たぶん)
じゃx86の何が速度的に有利なのか？
L1キャッシュの効率性は、フェチ&デコードで相殺されるよ

CMOVならそれこそP6以降のx86でもサポートしてるし

オペレーション密度の問題って知らないのかな？
たとえばある値と32ビット即値(たとえば0x12345678)との論理積をとる場合
x86ならand eax, 0x12345678で一発だ。命令長もせいぜい6バイト程度ですむ。

これがRISCの場合
32ビットの上位16ビット(0x1234)をセット→下位16ビット（0x5678）とORをとる→AND命令で3命令だな。
命令長を6バイトとか8バイトにすれば32ビット即値くらいは表現できるがコード格納効率が極端に下がる。
これが固定長命令形式の限界。

メモリ間接操作まで含めると圧倒的な差がつく。
故にx86のパワーレンジでx86以上のシングルスレッド性能を発揮できるRISCなど皆無。
ARM本家はx86のメリットが生かしにくいベンチのスコアでだけx86と同等としか言わないからな。

> 命令密度が問題なら、L1キャッシュを増やしてフェチのレイテンシを伸ばせばいい
> この方が複雑な命令を多段デコーダで解読するよりずっと簡単なソリューションだ
> 命令密度がIPC向上に寄与するなんてのはIntelの詭弁だ
その方法のまずさはItaniumを推してたIntelが一番理解してる。

本題だが、プレディケートの無くなったARMってPowerPCのISAと何が違うの？

x86とRISCの命令密度比は2程度
現在のCやFortranコンパイラでね
RISCの即値が不足してる可能性はあるが、将来64bitフォーマットを導入すればいい
おそらく導入するだろう
CISCで効果のある命令、アドレッシングモードってスケールド･インデックスだけだよ(これの効果は絶大で、ColdFireが68000を超える命令密度を実現し、68020が初期のポストスクリプトプリンタに使われた要因)

内部結合で命令圧縮は出来ても
x86フェッチレベルで命令密度の高い命令を放り続けるって
IntelCPUは苦手じゃなかった？

> CISCで効果のある命令、アドレッシングモードってスケールド･インデックスだけだよ
よくわかってるじゃないか。
それをRISC命令でやると3〜4命令かかる。
クロックを上げてペイすればいい？PowerPCがどうなった？将来5GHzや6GHzのARMでも出てくるのか？

>>786
メモリオペランドをとる命令でフロントエンドのペナルティがあったのってPentium Pro時代の話で
Pentium M以降では解決してます。

>>788
レジスタスタックが絡む命令はどうなん？

>>778
分岐予測ミスのペナルティを小さくするには、比較の結果をなるべく早く確定させることが効果的だが
(つまり命令流の中で比較命令が分岐命令のなるべく遠く前に出てくるのがよい)
比較＋分岐を一命令でしてしまうと、そのチャンスがない

Alphaのように汎用レジスタと0を比較するか、POWERのようにCCを複数個持つのがよいとされている

PowerPCでx86を倒せなかったIBMがARMならできるという理由がまず無いし
そもそも半導体屋である前にSI屋なのでx86に敵対する必要自体ない。

オペレーション密度が低いならデコーダ部分で合成すればいいじゃないか。
μOPsに分解しなくていい分、x86に比べたら負荷や規模は小さくなるだろうしね。

ただx86と比較してそこまで効果があるとも思えんが。

融合するには依存関係を調べなきゃいけないのにデコーダで処理できるの？
それこそx86以上に肥大化したデコーダになるな。

IntelがMerom以降採用したcmp+jccのμOPs fusionは命令が隣り合っていないと機能しない。

>>785
x86とRISCではレジスタの本数が違うのでループアンローリングなどの段数も異なる。

スケールドインデックスは手書きの時は便利だけどね。
Luna88kのコンパイラもあんまり使っていなかった。

もっとも、スケールドインデックスはrematerializationとして考えれば興味深くはある。

そのうちL4キャッシュまで作られるんじゃないのか？ｗ

十分に検討された場合のCISCは、RISCよりも速いんじゃないかな。
開発に金かけられない場合には、手っ取り早いしRISCが手頃ではあると思うが。
アマチュアがCPUの命令セット考えようとすると普通RISCっぽくなるしね。

CISCで最適化考えるのは恐ろしいほどの検討がいるし、メンテナンスもコストがかかるけど
現代のハイエンドチップのハードウエア資源の豊富さと、
コンパイラ技術に十分に金かけられる前提を考えるならRISCよりすでに上でしょう。

rematerializationの例、だな

>>781
> 命令密度が問題なら、L1キャッシュを増やしてフェチのレイテンシを伸ばせばいい
> この方が複雑な命令を多段デコーダで解読するよりずっと簡単なソリューションだ

ライン上に分岐命令がある場合には、次は分岐先からフェッチするようにしなければならない。
つまり依存関係のサイクルがあるから、命令キャッシュのレイテンシはここに効いてくる。
レイテンシを大きくするとフェッチバンド幅が大幅にするので、受け入れられない。

ループアンローリング（笑）

そもそもループアンローリングしなきゃいけないほど>>782のコード例ではx86ではレイテンシ1サイクルだが
PPCなどのRISC実装では3命令分の3サイクルだ。

即値などのパラメータの読み込みに難があるからレジスタを増やして再利用しないといけない。
とんだマッチポンプだな。

>>797
80年代初頭は有効なアイデアだった遅延スロットやレジスタウィンドウが、今日では癌扱いされているように、
使える技術にによって最適な命令セットはことなる。
重要なのは、目先にとらわれて将来の足を引っ張ったりしないこと。

x86は命令密度高いからキャッシュのサイズ節約効果でデコーダの複雑さは殆どカバーできていると思う。
ARMのデコーダパイプのレイテンシの比率って実際調べてみるとx86とほとんど変わらんのよ。
それでいて命令密度はx86の方が上。

P5のときはデコーダの面積はダイの30%も占めていたが、
P6以降は数%にまで落ちた。アウトオブオーダー実行が前提だとあまり差がでないんじゃないかな。
P5以下の規模にまでx86抑えようとしたら、ARMと比べて明らかに不利だと思うけど。

>>793
内部であとから結合するくらいなら
最初から結合x86でいいんじゃないかと思うんだが。
でもその手のパターンはIntelよりAMDの方が得意そうなんだよな。

x86の優位性を語っても肝心のIntelCPUのデコーダーに制約が多そう。

> 最初から結合x86でいいんじゃないかと思うんだが。
> でもその手のパターンはIntelよりAMDの方が得意そうなんだよな。
つまらない思い込みや願望だけで語るなよ。現実は逆だ。
AMDのBulldozerがcmp+jccの融合に対応したのはIntelのMeromの5年遅れだ。

IntelはSandy Bridge更にadd/sub/inc/dec/and/or/xorでも使えるように拡張している。

>>801
Sandy BridgeでまたuOPsキャッシュを載せた。
まあ、デコーダがフルに動けば電力的にも不利だが、
先に書いた通り、どういう命令セットが最適か？というのは実装によるとしか言えない。

>>800
個人的には命令セットの設計に将来のことを考えすぎるのは実は最近良くないんじゃないかと思っていたり。

命令セットは命令デコードやアドレス変換のための回路規模に影響するわけだけど、
プロセッサ内の他のブロックとまったく同じで、時代と共に使えるトランジスタ数がふくれあがっていくと
結局最適点が変わっていく。命令セットの拡張を拒んだり、デコーダが複雑になるのは哲学に反するとかの信仰で
拡張しないでいると命令セットはプロセッサ全体の中でどんどんボトルネックになっていく。
だから適当な比率で拡張するのが正しいし、これは避けられない現実。
RISCもマーケティング上はあくまでもCISCをこきおろしながら、密かに命令セットの機能不足を時代ともに補って
きたわけだし。

むしろ最初から将来のためっていう考え方自体が長寿のアーキテクチャとしては実は不適切なんじゃないかな。
その結果が、IA64みたいに考えすぎて最初からなんでも盛り込もうとしちゃった命令セットだろう。

>>805
いや、だから、拡張の余地がないような最適化はしちゃだめだよって話ですよ。
古い話だと、オペコードフィールドを使い切ってはいけないとか。
遅延スロットみたいなのもダメですね。

MACオタはどうしたんだ？
もしかしてジョブズの後を追って殉死したのか?？

RISCの発想自体がファイルシステムでいう　ファイル名は　8文字.3文字　までだとか　14文字まで　だとか
そのレベルで古臭いもの

core2
ttp://news.mynavi.jp/special/2006/conroe/004.html
>>さて、次はDecode段である。先に4命令/Cycleのデコードと紹介したが、
>>実際には全ての命令をデコードできるのはDecoder 0のみ(Photo06)。
>>Decoder 1〜3はSingle μOpのみがハンドリングできるとしている。つまり
>>1つのμOpsに変換できるx863 件/x64命令ならば4命令/Cycleが維持できるが、
>>2つのμOpsに変換される命令では1命令/Cycleに落ちてしまうことになる。
>>このあたりはプレゼンテーションでも多少説明があった(Photo07)が、要するに
>>デコード段そのものというよりも、renaming / allocationの制約ということらしい。
k7-bull
ttp://pc.watch.impress.co.jp/docs/column/kaigai/20091217_336298.html
>>K7/K8/Hound(K10)では、6パイプでピークで6uOPsを1サイクルで実行できる。全てのMacroOPが
>>2個のuOPに分解されるとしたら、3個のMacroOP分に相当するオペレーション(6uOPs)を
>>1サイクルで実行できる。命令デコーダからスケジューラへは、1サイクルにピークで
>>3MacroOPsが発行されるため、命令デコード&発行の帯域と実行帯域がマッチしている。

団子が散々吠えてるのは「Fusionで結合した後」の話
「x86のコードレベル」だと本家Intelは制約だらけ。AMDのほうが
本来のCISCを発揮しやすい。

それで今これだけ性能差があるんだから
「CISCとしてのx86のメリットは後処理でなんとでもできるレベル」ということだ。

大原のその記事間違いだらけだしそんなの引用してる時点で話にならない

>>810
大原の文章を読まなくても普通に
「デコード1から3はシングル命令だけよ」
ってCore2のスライドに書いてあるんだが

IntelのPentium M以降のデコーダの強化方針は、いかに多くのx86命令を1つのuopしか生成しないようにする
(=Simple Decoderを拡張して極力命令をComplex Decoderに回さないようする)かだけどね。
uopという単位がIntelとAMDではそのまま比較できないよ。

Decoder1-3はシングル命令だけだけど、ALU+AGU操作の命令もSimpleデコーダでデコードできます。
Pentium Mからだね。


それからK10だけど
>>K7/K8/Hound(K10)では、6パイプでピークで6uOPsを1サイクルで実行できる。全てのMacroOPが
>>2個のuOPに分解されるとしたら、3個のMacroOP分に相当するオペレーション(6uOPs)を
>>1サイクルで実行できる。命令デコーダからスケジューラへは、1サイクルにピークで
>>3MacroOPsが発行されるため、命令デコード&発行の帯域と実行帯域がマッチしている。

Load/Storeユニットは2つしかないのに6オペレーションも同時にに実行？ありえないだろ。
分散RS方式は車線変更の出来ない1車線道路が3つ並んでるのと同じこと。
他の車線（実行ユニット）があいてても他の車線から乗換えができない。
レーン変更ができないからユニットを冗長に持ってるだけで、全部が同時に並列に動くわけではない。

なにより問題なのは、デコード前にディスパッチしてパイプラインを縛ってしまうことで
バックエンドパイプラインの充填率を下げてしまっていることだ。
むしろレーン縛りのせいで実効性能は低い。

その結果が4コアなのにSandy Bridgeの2コアに負けるという事態。
まあ、効率が悪かったからBulldozerで2ALU・2AGUに落として（代わりにIntelと同じ集中型スケジューラ）
を採用してもIPCが落ちなかったわけなんだが。

大原はデコード前にディスパッチするのがエレガントだとか言ってるが現実は全く逆。

まあ、このSimple Decoderの強化の件が色々調べていると、先の話と関連していて
つきつめると現代ではRISCよりもCISCの方が速いという実際の証拠の一つでもあるな

>>815
x86だけ調べてその結論とは恐れ入る

32ビット固定長のRISCで64ビット即値をレジスタにセットするのって4命令くらいかかるの？
しかもORで足し合わせて・・・だから依存関係チェインが発生する。
命令セットそのものがボトルネック。クソ過ぎる。

>>Load/Storeユニットは2つしかないのに6オペレーションも同時にに実行？ありえないだろ

え？K7からK10は3ペア構造だろ。

>>815
結論じゃなくて証拠といってるだけだが。

RISCは、数万トランジスタ時代のハードウエア技術とコンパイラ技術で
1チップにCPUの機能を収めよう的な発想でまとまっているものだよ。
それを現代でも最適解だといいはりつづけるのはRISC屋のマーケティング活動に洗脳されすぎだろう。
実際にAlpha以降のISAで、RISC命令セット採用しているプロセッサの方が少ないしね。

>>818
ちゃんと資料読んでからレスつけろ馬鹿
AGUはアドレス生成ユニットで、更にバックのLoad/Storeユニットに連なってる。
Load/Storeユニットは2基しかないから3つのAGUが全部が同時に動くことなんて現実的にはありえないの。

AMDのMacroOPというのはALUとAGUのLIWみたいなものなのか？

>>819
洗脳ですか…
アマチュアにしてもその発言はどうかと

>>818
http://www.es.ele.tue.nl/~heco/courses/et2-010/k7slides.pdf
AMDの資料ね。
5ページ目にロード・ストア・ユニットが二つだと書いてある。

RISC屋も商売だし、基本はその時に都合の良いマーケティング文句いっているだけだよ。
RISC周辺は、アカデミアの世界を抱き込んで活動している分、洗脳のたちが悪い。

パイプライン、スーバースカラ、アウトオブオーダーも
RISC起源説でマーケティングしまくってたでしょ。
80年代にアウトオブオーダー実行周辺の研究していた奴は
RISCの研究者から複雑過ぎて成功しないと馬鹿にされてたらしいが。

>>824
80年代のマイクロアーキテクチャの論文はそこそこ読みましたが、誰が誰をバカにしてたんですか？
Yale PattやGuri SohiがHennessyやPattersonにバカにされてたんでしょうか。

ちなみに、アカデミアで認められている起源は

・パイプライン IBM Stretch, ILLIAC II
・スーパースカラ CDC6600, IBM ACS
・アウトオブオーダー CDC6600, IBM S/360 model 91

RISC起源だと吹聴していた奴なんてただの一人にも会いませんでした

>>825
専門家の人ですね。
Yale PattらがRISCの研究者に、このコンセプトは現物化できないと馬鹿にされたようだが、
具体的に誰が馬鹿にしたのかはわかりません。

>>826
アカデミアでもまともな人しかあってないからじゃない?
RISCプロセッサメーカーがマーケティング用にRISC技術として利用していたのは
今ではだいぶ忘れられているが、事実だから仕方がない。
実際にはRISC以外の技術の潮流も70年代以前はもちろんのことだが、80年代以降でも多くあって、
90年代以降でそれらの研究成果が複合して今のプロセッサが成り立っているのに
RISC中心の世界観がこれだけ浸透しているのはいかがなものかと。

ｘ86 vs ARMをCISC vs RISCという風に「ARM = RISC」だと洗脳されている人が多いよね

> RISCプロセッサメーカーがマーケティング用にRISC技術として利用していたのは

CISCの80486や68040なんかもそうですね。しかしさすがにその時代は過ぎたんじゃないかと。

> 実際にはRISC以外の技術の潮流も70年代以前はもちろんのことだが、80年代以降でも多くあって、

90年代以降のOoOの実用化は、precise interruptが実装できるようになったからですし。

> RISC中心の世界観がこれだけ浸透しているのはいかがなものかと。

なるほど。ここが認識の違いかな。
自分自身はx86大好きっ子なのですが、RISCが過小評価されていると常々思っていました。

>>830
十分に評価されていると思うよ　＞RISC
今でもx86がCISCだからARMには勝てないとか言われているぐらいだぞ。

ただ個人的には時代が移ってCISC、RISCという考え方・分類方法が無意味だと思う。

スーパースカラやOoOをRISC技術って言ったのはintelじゃなかった？
自らCRISC(恥ずかしい)とか逝ってたし
intelのマーケティングコピー

言ってない
CRISCってのはRISCのロード・ストアアーキテクチャに倣って内部オペレーションレベルで
ロード・ストアとALU操作を分離することと

スーパースカラはCRISCと言われる前の初代Pentium(P5)時代から実装してるし
アウトオブオーダ（Intel用語でいうダイナミックエグゼキューション）に関しては
Intelは「RISCより先行した」と言ってる

>>830
過大評価、過小評価の問題いうより、RISC vs CISC論がいやになったんですよ。
RISC vs CISCは議論のネタとしては今でもとても面白いんが、
あまりにそればっかりになりすぎて、大半RISCがハイエンド市場から撤退してからも
何の議論をしていても二言目には"RISC"の文字がくることにだんだん
うんざりしたというのが自分の場合。

CRISCってのはP5のときだ
P6までには、この恥ずかしい用語をやめていた

ARMの良いとこの本質は命令セットでなく、多数のメーカーにライセンスされてるところ
もちろんv8からは命令セットも悪くない
で、ここから今日の流れに、、、

P5(Pentium)はμOPsに分解しないし純CISCだろ？
ついでにPentium 4は更に内部RISC化したが、結果的にはCISCのコード効率の
高さを生かす方向で進化させたPentium M系統のアーキテクチャが生き残った

> もちろんv8からは命令セットも悪くない
むしろ他の64ビット化されてるRISCと何が違うの？
1バイト・2バイト単位のロード・ストアもできなくなったから文字列操作は弱そうだし
そんなもん1から仕切り直すならわざわざ高いライセンス料払ってARM使うより
既に64ビット化しててライセンス料の安いMIPSでも使ったほうがマシだよね？

uops fusionの肝はコード効率じゃなく、一種のLIW
依存関係の明示化だろ
ただしこれはロードを大幅に先行させることができなくなるなどデメリットもある

命令セット的にはitaniumが正しい
あれの間違いは6-issue 4 L/Sにして、くそ多いレジスタポートや、クワッドポートのL1Dキャッシュとかでクロックがあげらなかったってとこだ、たぶん

> ただしこれはロードを大幅に先行させることができなくなるなどデメリットもある
Sandy BridgeやBulldozerの世代ではμOPs Fusionを辞めてその分RSの並列度上げてるけどね。

ARM v8に、重箱の隅をつつくようなことを言ってるが、まずx86 64bitとv8のコード密度は2倍以下の違いしかない
32〜64bitの即値やbyte･word L/Sもあんまいらない
命令セットってのは直感でなく、コンパイラと対で考えて決めるもの

>>838
そうしたらARMv7コードが動かないじゃないか！

>>831
境界ははっきりしないが、CISC,RISCという両極はあると思う

>>832
80486や68040でワイヤードロジックを採用して、両社は「RISC技術を取り入れた(いいところどりで最強)」と主張していた

>>841
リテラルプールってL1D側からロードするからその分性能面では不利だけどね。
Atomに毛が生えた程度の性能しか目指さないならそれでも十分だが。

Intelはどっちかっていうと486、PentiumはRISC技術とりいれたっていってたんだよね。
命令も内部形式のuopならぬmicroinstructionに変換されるしね。もちろんload/storeアーキではないけど。
P6の方がいってない。

このあたりのIntelの主張は実はかなり正しくて、
486はRISCの技術をパクろうとしたんだけど、P6は実はRISCパクろうとしたんじゃないんだよね。

P6は、4-issue ooo RISCと同期でパクりようがない
Dynamic Executionとか今日数年ぶりに見た気がするな
intelだけoooって言わなかった

>>834
なるほど。

CISCが速いといっても、80x86だから速いのか、680x0やトロンチップでも気合入れれば速いのか、ちょっと興味はあります
486〜Pentium世代ではx86が優位だったと言えそうだけど。

GPUすらVLIWを辞めてしまった。
大学教授に一人くらいはいたよなこれからはVLIWの時代とかﾄﾞﾔ顔で言ってたのが。

学者が好きそうって意味では理解できる。
効率化を極めるにはコンパイラの時点で効率化しておくしかない。
だけど、それに伴って捨てなきゃならないものの大きさを見誤るというか。

もうCISCでもRISCでもどっちでもいいというのが正直なところ。CISCには多少ロマンがあるが。

それより例えばTracing JITのサポート命令とかそういうのを入れてほしい。

もしかしたらスピルも専用命令を用意できるかも。レジスタリネームだけ変更するとか。
レジスタウィンドウの一般化的な。にゃにゃ。

RISCとCISCとが対立する概念だとして、RISCの極にMIPSか何かを置くのはいいとしても
じゃあCISCの極はx86が相当するのかと言えばちょっと違うんじゃないかという

>>852
68kでもVAXでもNSでもなんでもいいと思うよ。
さすがに432とかRekursivみたいなのは命令セット以外のところが大きくアレかと思うけど。

というか、リニアアドレス以外のプロセッサはさすがに除外していいでしょう

現存の最大勢力って意味ではx86でいいと思う。

>>846
P6の開発陣はその前はRISCのi960やっていたわけで
パクるというより自家薬籠中のものとしていたでありんす

>>843
で、P5の頃に更にスーパースカラだからCRISC(笑)と言っていたよな確か。

RISC・CISC命令セットアーキテクチャの区分で良いんじゃないの？
マイクロアーキテクチャの実装方法の良い所を取り入れるのは当然だし

>>728
アムダールの法則からして、ベクトル化率60%だと話にならない。さらにSX系だとスカラー演算がすごく遅いから。

メモリアクセスが遅いの、どうにかなんないんスかね？

CPUにメモリを混載すればいいじゃない

intelなんて15MBも積んでるからなあ

TSVが低価格化&普及すればGBレベルのL4キャッシュが内蔵されるだろうから改善されるよ！

TSVでDRAM混載すれば広帯域かつ低消費電力にはなるけど、レイテンシはあまり変わらないかもなあ
つまりマルチコアやGPUにはいいけど、シングルスレッド性能にはそれほどはインパクトないかも

あれほどRDRAMにしろと・・・・
値段が高すぎてダメだった事を除けば悪くないメモリーだった
RIMMに移行するべきだったんじゃないかなあの時（Pen4）に
DDRはそろそろ限界が見えてきたしDDR4はなんかグダグダだしさ
ハイエンドだけでいいからXDRDRAM2しないものかね？

メモリーだけが高速性能から取り残されている。DDRにもうあまり伸びしろは無い。例え
DDR4が出てもその次に今の技術の延長でDDR5が出るとは到底思えない。
業界のラムバス嫌いはしょうがないけど、ここらでRIMM移行を見据える時だと思う

メモリ遅いぞって最初に言われたのは486で中だけ倍速になった頃かな

メモリが遅いったってそれを意識させるだけのプログラムが殆どないだろ
自分で書けるならば別だけど

まずXDR2がGPU向けで量産されるみたいだし
そっちに期待

メモリセルにDRAM使ってる限り大して変わらないって。

XDR2来てほしいね

XDR2って次のNVIDIA向け？
AMDに乗るって噂は否定されたらしい

あなたは高速なメインメモリのために数倍の値段を払えますか？

サーバ用途でサポートしてもビジネス・ホビー用途ではサポートしそうにないよね。
奇跡的に市販PCに載るくらい普及・量産化されてもDDR3と比べて倍近くは高く付くわけで。

XDR2が実際に出るのはDDR4やWild I/Oよりも後
世界的に釣りネタとして流行ってるから良く目にするだけ

チップ単価は同容量のGDDR5よりほんの少し高いだけで帯域当たり単価なら大幅に安くなるだろ
ミドルやローならともかくハイエンドクラスのGPUになら使える値段

ゲーム機はどうだろね？

高くてもイイから速いのが欲しい！！

>>876
メインメモリとVARM共有する箱後継機でなら採用の目はあるんじゃね
チップ数削減できるWideIOとかもありそうだけど速度の伸びが限界に来てて消費電力削減もできそうもないGDDR5よりはアリじゃね

>>873
今の相場なら３倍でもおｋ

グレイ共がホモサピエンス・サピエンスの改良をDNAレベルで未だに進めているのも納得が逝くわ。
つまりヒトの脳自体が

選別落ち品程増殖するみたいだがな
だから時々戦争して選別落ちを処分してるんだろう

戦争は優秀な人間が死んで無能が生き残るから選別にならない

またそうやって…
どっちも死ぬだろ、アインシュタインが相対性理論発表した後
戦時下の塹壕でその特定条件における方程式の解を発見したという(これは寓話だと思うw)
シュワルツシルトは戦死した

XDR系はチップ数と電力減らしたいモバイルで使われるのではないかな、使われるとしたら。
GPUの場合、ハイエンドならピン増やしても許されるわけで、微妙なのではないか。

しかし標準規格の次世代メモリも見えているのでRambusは売りにくいだろう。どうするのかな。

モバイル向けはWideIOからTSVにでも向かった方がいいような気もするが、
ノート用だとどうかな。

メモコン増やしてXDR2も採用するのが真のハイエンド

Rambus自身もDDRやSDRAMが使えないせいで失敗したDRDRAMで反省したから
GDDR3とGDDR5にも対応したXDR2メモリコントローラライセンスしてんだよな
コレ採用された話は聞かないけどAMDは使おうと思えば使えるハズ

さっき初代MIPSのパイプラインの図を見てたんだが
http://upload.wikimedia.org/wikipedia/commons/9/9e/Pipeline_MIPS.png
こいつのデータパスを74シリーズで置き換えると7,80個でできそうなんだよな。
配線は死ぬけどな。

ちなみにこの絵にはバイパスが抜けている。
バイパスは太古の昔から今日にいたるまでずっとクリティカルパスの一つなのでこれはいくない。

32ビットバレルシフタは論外に大きい。80386のフロアプランでもかなりの領域を占めていた。
32+32ビットから任意の32ビットを取り出すためには、16,8,4,2,1ビットシフトを組み合わせるわけだが、
74シリーズの2対1セレクタは4ビットしかないので、ICは
12+10+9+9+8=48個必要
これに加えてバッファもいる。

ちなみに、有名なALUの74181は1960年代の登場

6800はミニコンライクです。
こいつが似ているのはHP2100のようなアキュームレータマシンの初期のミニコン。
初期のミニコンはだいたいトランジスタ以降だけど、素子が高いので汎用レジスタはあっても少なかった。

68000はPDP-11やVAXのような後期ミニコンに似ている。
これらは汎用レジスタマシンで、命令セット的にはS/360か、それより前にさきのぼる。

http://www.st.rim.or.jp/~nkomatsu/mc680x/MC6800.html
> MC6800は、PDP-11のようなミニコンピュータを徹底的に簡略化して1個のICの中につめ込んだという面が強く、
> インデックス修飾などのアドレッシングモードが考慮された命令体系になっていました。

この人なんかはそのあたりを混同している典型的な半可通ですね。

日本語でおｋ

>>894
verilogならわかる？

ビッグエンディアンが命取り

16032は、命令バイトはビッグエンディアンでデータがリトルエンディアンの変態だった

変態レベルの話になってきてうれしい。

>>765
GPUだと〜NV40あたりがデータフロー・アーキテクチャだよね
特許でかなり詳細まで出てるよ
http://www.google.com/patents/about/6724394_Programmable_pixel_shading_archi.html?id=J-4RAAAAEBAJ
NV30のパフォーマンス悪化の原因の一つは物理レジスタの不足(float4で2本！)だったけど
これはまさにデータフロー・アーキテクチャの弱点が露呈したもの
スレッドコンテキストをパイプライン中全部持って回らないといけないからね
NV30では入りきらない分はFIFOに預けられるが
ここがボトルネックになった

テクスチャフェッチが主体で計算はおまけ程度の時代では
コンテキスト切り替えのコストが０なデータフローアーキテクチャが有利だったけど
シェーダの高機能化が進むにつれて不利な点の方が多くなってしまった

>>893
1960年代半ばだとICですね。DTLとかも。
1960年のPDP-1とかはトランジスタだけど、あんまりミニコンって気がしないんだよな。

来年はAlphaの20周年だな。
たとえ生きていてもあと5年の寿命か。

>>888
XDR2が採用されるといいな。
メモリーの進化が止まっている現状を打破して欲しいものだ
なぜ初期Pen4はDDRと共用できるようにしなかったのか？していれば
ハイエンド限定として今も残っていたかもしれないのに。
せっかくPS2のおかげで製造原価が下がって激安になった時にはインテルは撤退した後だったのが
悔やまれる

1980年、1990年のCPUのキャッシュメモリーの容量は？

90年代、PentiumはL2外付けだったな
EV5の外付けはL3だっけ

1980年 キャッシュなし(メインフレームで128kBくらい？根拠なし)
1990年 L1 8kB L2 128kB
くらいだ

>>905
キャッシュ無しって・・・
まさかメインのDRAMを今で言うキャッシュみたいに扱ってたの？

CPUが遅かったからキャッシュなしでも良かったんだろ。

3090VFのキャッシュは64KBとあるな…

>>906
命令フェッチが遅いので、一命令の高機能化->お化けみたいなCISCになった

>>908
しかしCPUクロックの増加でそのCISC路線が間違っていると気付いて、
RISCにしようとしたがとき既にお寿司って事で今のCPUの基礎になったんだな。

＞とき既にお寿司
ﾜﾛﾀｗ

>>906
DRAMでもノーウエイトって宣伝してた時代だしな

2バンクのインターリーブ・アクセスでもメインメモリのノーウェイト動作が困難になったのが
386時代の中盤くらいからで、ハイエンドマシンにはM/B上にSRAMキャッシュを搭載
するようになった。
486時代になるとAT互換機では安物M/Bでもキャッシュ（L1がCPU内蔵になったのでL2扱い）
積むのが当たり前になりP5時代でも同様だったが。P6時代になるとL2もCPU内蔵になり
M/B上のキャッシュは廃れた。

マジレスだけど、お寿司っつ〜かグローブ曰くコンパックの社長から過去資産が駄目になるから
riscにするなっつ〜ことだったはず

メインメモリがCCDだったコンピュータもありました

キャッシュは60年代の末期から既に使われてる
CISCの複雑な命令はフェチ帯域のためじゃない
セマンティックギャップ解決
人間がアセンブラを読みやすくするため
VAXの初代、VAX 780/11は複雑な命令セットだけど8kBキャッシュを積んでた

VAXといえば学校新聞や町内会ご用達のパーソナル編集長のイメージが・・・

キャッシュはウィルクスの発明なのでもっと古いんじゃないの。
日立もやってたし。

セマンティックギャップは普通はプログラミング言語と命令セットのギャップのことを言うと思う。
セマンティックギャップを埋めることこそ高性能化の鍵みたいな言われ方をしていた。
その結果、高級言語マシンがたくさん作られたが、そのアセンブラは必ずしも人間が読みやすいというわけではなかった。

で、なぜセマンティックギャップを埋めると速くなると思われていたかというと、
一命令でたくさんの処理ができるから。

ないわ

x86はSSEやAVXなど強力なSIMD命令があり実装でもその複雑なSIMD命令を1クロックなど高速に実行できるけど
逆に言えばSIMD命令を多用しなければただの宝の持ち腐れの部分が多いということかな

むしろx86以外の方がシングルスレッド-スカラ性能が低い分
SIMDだのCMPだのに大きく依存してる印象が強いが

レジスタ32本・3オペランド(5*3=15bit)に相応しい長さということで
3バイト単位の変態可変長命令ISAを妄想してみた。
3バイトのうちの先頭2bitで3/6/9バイト長を識別する。
1オペランドで済む単純な命令なら3バイトの中に2命令をパックできるようにすると尚よい。
32bit即値は6バイト命令で、
任意の64bit即値も9バイト命令でレジスタロードできる(若干苦しい)。
単純化のために1命令が64バイトアライメントを跨がない規約とすると、
命令を63バイト並べて、余る末尾1バイトで何かユニークな仕掛けができる……

VHDLで頼むお

将来はララビーとGPUを両方内蔵して
高負荷処理はララビーが
低負荷処理はGPUがそれぞれ担当するように内部で切り替えしてくれるといいな
省電力にも繋がりそうだしさ

DRAMは構造上アドレスラインアサートしてから電荷出るまでのレイテンシが避けられないから、いっそSRAMを安価にするほうがいいんじゃね？

>>921
アーキテクト認定。

3バイト単位は駄目だろｗ
x86だってセグメント境界は2のべき乗だぜ？

頭固いなあ

というかARMの64ビットモードは「Thumb64」的なものだと思ってたんだけどな。
Thumb2を更に拡張し、4バイト命令（PC相対アドレッシング）の後続ワードに32ビット・64ビットの
即値を埋め込んで8バイト・12バイト命令を表現するというものだ。
なんだかんだで命令ストリーム側から値をロード出来るx86の即値モードのメリットはでかい。

>>923
それに似た話は（多分）後藤氏の記事にあった気がする

もし、CPU、ララビ、GMAの3構成なら
GPGPU部分はララビ（MIC）が
純粋なグラフィック部分はGMAが担当することで
それぞれの絶対性能を上げやすくできる
とか何とか書いてあったような

Dango Micro Architecture はどんなものになるんだろう

>>924
DELLは80286の時代にSRAMをメインメモリにしたPCを造ってたな。

>>931
現代でもSRAMをメインメモリにすることは技術的に可能？
金はいくらでも払う。

>>926
63バイトだけ命令を並べたら
1バイトのパディングを置く

変態だ

>>930
学生時代に考えた「ぼくのかんがえたさいきょうしーぴーゆー」は
基本4バイト命令（＋０・４・８バイト即値）で、1ワードは2オペランド演算を2操作パックしたLIWあるいは
3〜４オペランドの1操作で構成。汎用レジスタは16本。

>>932
てか昔のメインフレームが数十GBのSRAM＋バッテリバックアップだったでしょ。
SRAMをストレージにするくらいだから当然メインメモリもだな。

>>934
おお、さすが団子氏、理想があるんすね。
IPCの向上に重点を置いた思想ですか。
そういえばTransmetaってどうなったんだろう･･･

＞てか昔のメインフレームが数十GBのSRAM＋バッテリバックアップだったでしょ。
ひょぇ〜、メインメモリなんて余裕だｗ
極限の低レイテンシで、デスクトップコンピューティングはどんな変貌を遂げるんだろう･･･興味津々

DRAMとSRAMの集積度の比は数倍程度なんだから、一定量の需要があれば
DRAMの数倍の価格で同容量とか同価格で数分の１の容量とかは可能になるんだよな。

ソフトの要求により年を経る毎にどんどんメモリの実装要求量が増して行くって状況に
ぼちぼち翳りが見えてきたから、SRAMメインメモリに現実性が出るかも知れない。

レジスタ16本では少ないのじゃ

intel様に喧嘩売ってんのか

ぼくのかんがえたさいきょうしーぴーゆーは
スタックトップから数KBをゼロウェイトのCPU内蔵メモリ（レジスタバンク）に置く
スタックマシンだった。

SRAMがメインメモリになったら最高だな

>>937
別に少なくないよ。
RISCは定数をL1Dから読んだり組み立てたりしてレジスタに溜めておくから足りなくなる。
ぶっちゃけPPCの汎用レジスタ32本よりx64の16本の方がよっぽど余裕があるよ。

>>936
DRAMはキャパシタの容量がもう限界だから微細化だけがこのまま進んでいけばありうる。
実質的なメモリセルの面積でSRAMが逆転すればDRAM使う理由はないからな。

ああ、バカだったが有用な情報は提供してくれたMACオタが懐かしい

Z-RAMをDRAMに含めるなら戦えるかもよ

64bitの即値は8バイト
64bitの即値を多用したら命令フェッチの16byteの半分も
その即値のデータに取られてしまうから速度落ちるんじゃないか？

x86 CPUの弱点が浮き彫りになったNehalemマイクロアーキテクチャ
ttp://pc.watch.impress.co.jp/docs/2008/0428/kaigai438.htm

多用すればね。
その記事、別に後藤さんはx86に比べてRISCが優位だとは言ってない。
32ビット固定長のRISCでは即値フィールドはせいぜい2バイトだから、その16ビットを4回重ねて
ロードする方法だと、4命令＝16バイト食う、あるいはリテラルプールから読むことになる。

>>934のアイディアは命令境界が必ず4バイト単位になるようにすることで命令の切り出しを容易にする
目的がある。根本の思想はRISCとCISCのいいとこ取り。

>>946
即値なんてコンパイラがよく使うのはベースアドレスの読み込みだろうし
アウトオブオーダーに対応してるCPUならあらかじめリテラルプールから読み込んでおく方法もあるんじゃない？
RISC CPUはレジスタが多いしそれならそれほど速度おちないでしょう

> RISC CPUはレジスタが多いしそれならそれほど速度おちないでしょう
オペランドのフィールドが大きくなるので表現できるオペレーションを縛り、結果オペレーション密度が下がる。

ちなみにメモリアクセス時のインデックス値の指定だと
PowerPCでは16bit、ARMでは12bit(シフト演算も可能)だから
通常のメモリアクセスに困ることは少ない
x86の場合このインデックス値が8bitもしくは32bitのどちらかしかない

> x86の場合このインデックス値が8bitもしくは32bitのどちらかしかない
かえって性能落ちるからあんまり使わないけど16ビット即値も可能

即値の読み込みではなくアドレッシングモードで即値でインデックスを指定する方法のこと
コンパイラが吐き出すコードのうち即値を良く使うのはアドレス指定だから

なんにせよ固定長命令に可能性を感じないね
よく使うオペレーションは1〜2バイト＋αで十分だ。大半のケースで3オペランドも必要ない。

即値がつくときだけ命令長が伸びるのはNECのV800がやってるよね
あれは2Byte単位だけど

>>950
今時のコードを考えると正直disp32にするよりdisp16のまま方が有利だったと思う

>>932
技術的には可能だと思うが、
意味のある実装は困難だと思う。

CPUに内蔵のメモリコントローラがDDR3SDRAM用という理由で、
SRAMコントローラはCPU外部に設置する必要があるわけで、
メモリバスより帯域の狭いDMIやらPCIexやらHTなどを経由してアクセスする必要があるから。

即値の98%は13ビットに収まると指摘したのがご存知タンネンバウム
むろん即値の使われ方は時代とともに変化する
しかし64ビット即値の高速化が性能にクリティカルな影響を与えるのは未来永劫団子の妄想の中だけだ

別に16ビット即値で収まるのが32ビット使ってもそれほど無駄とは思わないけどな
SuperHの開発者いわく「Cの関数のほとんどは変数が14個以内で収まるからレジスタ16本で十分」
この割り切った設計によりコードサイズをコンパクトに保つことができARMのThumbモードにも
影響を与えた。

一般的なコードでレジスタが16本で足りなくなるって根本的に設計がおかしいと思うんだ。

>>955
別にx64でも殆どの命令は8/32ビット即値で足りるけどな。
むしろ1回しか使わない値に対してもわざわざ論理レジスタにロードすることを強いるRISCの設計が
ハード的に無駄。

> ご存知タンネンバウム

「Linuxは時代遅れだ」とか言ってメーリングリストを荒らした厨房教授ですね

キングオブ無知の団子の言いそうなことだ
今日びインライン展開やループアンローリングのコストが下がり、ライブな値はますます増える一方だ
ISAは何十年と使われるものなので、将来を見越して設計しなければならない(見込みが外れることはある)
今この時の生を謳歌する団子には縁のないことだがな

いっそのこと、即値を全面禁止にして、
ベースアドレスレジスタによる相対アドレシングで、
オペランドテーブルから読み込むことに決めてしまってはどうなんだろうか。
これなら命令サイズの肥大は防げる。

テーブルサイズが4kB程度ならdisp12でカバーできるし、
4kBで足りなかったらテーブルを複数個使えばいい。

と書いたら、なんかSHあたりを思い出した、ような気がした。

> 今日びインライン展開やループアンローリングのコストが下がり、ライブな値はますます増える一方だ

また妄言をｗｗ
Sandy Bridgeよりクロック当たり性能の高いRISCでも出てくるなら見てみたいものだが
5IPC以上になると依存関係追うのがきつくなるんだよね。

過去との互換性を一切考慮せず、まっったく新しいISAを作れるなら、どんなものになるだろう。
団子さんが強調する、コード密度を上げるアプローチだろうか。
よく使われる命令のビット長を短くするって、エントロピー圧縮みたいで良さげだね。

>>961
IA64がコケたのはIPCの限界が5くらいだから？？

x86だけでなくPowerまでもがわざわざ命令同士を内部的に融合してオペレーション密度を上げる
アプローチを取ってることから考えても最初から高密度設計にしといたほうがいいね。
とっくに定年迎えて退役の恩師の言ってた「これからはVLIWの時代」は半分は当たってると思う。

Sandy Bridgeは気持ち悪いくらいよくできているが、
ISAの評価を「特定の」実装でしか考えられない団子は抽象的なものの考え方ができないんだな
それはそれで幸せかもしれん

>>963
Itaniumの何が駄目って、1ワード128ビットだぜ。Itanium 2の2バンドルで1サイクルあたり256ビットフェッチ。
L1I帯域食いすぎ。
L1Iのレイテンシを小さくするためにL2までIとDに分けて・・・とにかくいろいろおかしい。

itaniumの問題は4 lord/storeとかOoOがないとかで、次期itaniumはそのへん改善される

> 特定の実装
SPARC（笑）の実装で当たりなんてありませんでしたが？
いずれにせよ4バイト固定長に将来はない。

ARMはThumb命令セットを実装してから当たった。

L1が小さいのはQuad Portだからだろ
帯域とレイテンシはたぶん関係ない

どういうISAが最適なのかは、その時代そのテクノロジによって異なる
あるときは優勢にみえたISAがその後落ちぶれることもあるのは皆さんご存知のとおり
団子は80386がクソSPARCにすら圧倒的に負けていたことを見ないふりをしているね

勉強になった！
ってか次期Itaniumって出るのか。
Itaniumがこの先生きのこるには。

俺には理解できないのだが、
特定の実装にばかり目がいくと非難されて

> SPARC（笑）の実装で当たりなんてありませんでしたが？

と、特定の実装を引き合いに出して反論した気になっているのは、やっぱり知恵遅れか何かなのか？

thumbの前からARMは売れてる
あと、速度が重要な携帯じゃthumb使ってるわけないだろ
ARMはv8で普通のRISC ISAにした
ああいうISAが、かなりの範囲で最適解なわけだ

>>968
Thumbは性能を犠牲にしてまでコードをコンパクトにするための命令セットだから
パフォーマンス優先な用途にはつかわれないんじゃない？

> 団子は80386がクソSPARCにすら圧倒的に負けていたことを見ないふりをしているね
それは1コアに使えるトランジスタに制約があった時代だからだな。

今はこれ以上クロックもIPCも頭打ちになってる今できる高速化のアプローチは
1命令のオペレーション密度を高めて専用回路を追加すること。
だから今はCISCでないといけない。幸いにも1コアに使えるトランジスタはふんだんにある。

おまいさんがRISCの時代の再来を夢見てる老害だとわかったよ。
ループアンローリング（嘲笑和良

>>974
ARMステートとの切替にオーバーヘッドがあるからだよ。
ARMの性能の要であるバレルシフタやプレディケートビットのフィールドもないしね。

人生最大のプログラムが4x4の行列演算ならループアンローリングの必要はないが…

x86が性能が向上したのは億単位出荷がそれを支えてるからでしょうね
それだけ開発費を投入できるから。
結局ISAよりもマイクロアーキテクチャの問題の方が大きい
今、ARMが注目されているのもスマホやタブレット用途で億単位で出荷されてるし
今後しばらく需要が伸び続けると予想されるからでしょう

ゲームに使うのは単精度4x4で十分だけどな。
世のプログラムの99%は整数演算主体だ。

え？マジだったの？

>>978
省電力が要求されるスマホ向けのIPとハイパフォーマンスPC向けのIPは共通化できない。
PC向けは別にARMである必要が無い。

命令を追加し、そのための専用回路を積むのは正しいがCISCは間違ってる
だからuopsキャッシュに効果がある

ちなみにSPARCはMMXライクなSIMDを採用した最初のCPUだ(i960は無視)
SUNはSIMDと3D RAMでポリゴンをやり、GPUを積まないグラフィックスWSを出してた

今成功しているアーキテクチャを見てしたり顔で持ち上げるだけなら簡単なんだけどな
アーキテクトは将来を予測して設計しないといけないから大変だ

> Cの関数のほとんどは変数が14個以内で収まるからレジスタ16本で十分
たいてい関数は関数を呼び出すので、caller-save registerは使いづらい。
OSとかシステムもなんだかんだでレジスタを何本か持っていく。
仮に使用するのが14個なら、全本数が16本ではちと足りない気がする。
おそらくスイートスポットは24本あたりではないだろうか。
そこでやや足りないのを我慢して16本側に振るのが組み込み、
32本側に振るのがサーバの発想だと思う。
http://japan.renesas.com/products/mpumcu/rx/child_folder/feature.jsp

うん、アーキテクトは未来を設計してるよね。

>>980
お前こそマジで言ってるのか？ｗｗｗ

ちなみにテンプレートメタプログラミングはよく使うよ。
それでもレジスタが足りなくて性能が下がるケースなんて遭遇したことが無い。
無闇なループアンローリングはL1キャッシュヒット率を下げる害悪だと思え。
メインストリームのCPUにおけるL1キャッシュのサイズなんて20年近くも変わってない。

>>984
いまそういうのあるんだ。
SuperHのページって消されたのかな？

>>974
ThumbとThumb-2は違う。2の方はかなりいけてる子なので、使わない理由はない。

命令フェチアドレスを予測してL1からでなく、L2から命令を読めばいい
無闇にサイズがでかいループアンローリング(笑)なら、分岐もあまりないから問題ないだろう

2はThumb-ARMのステート切替がないからね

まあでも事実アセンブリを書いてみるとx86-64の16本は、ARMの16本と比べるとかなり余裕を感じる。

> 命令フェチアドレスを予測してL1からでなく、L2から命令を読めばいい

ItaniumがL2を2つに分けたのってなぜか知ってる？
分けないとデータの分の帯域を食っちゃうからだ。

>>992
キャッシュ容量や階層は実装の問題でISAの問題じゃない

>>981
今後、企業でワープロなどのビジネスソフトを使う情報端末がモバイル化していくと想われる
今でさえクアッドコアのCPUを搭載したPCは市場に流通するPCの10%未満らしいし
一部の用途を除いてCPU性能は満足のいく性能に達しているからね

>>993
1ワード128ビットでどうしろと？なんだかんだでISAは実装を縛る。

>>982
> ちなみにSPARCはMMXライクなSIMDを採用した最初のCPUだ(i960は無視)

i960じゃなくてi860
で、SPARC V9の前は88110のグラフィックスユニット

>>994
スマホの小さい画面で事務作業できるか？
ウィルス等の対策のためにソフトの配布元を制限してるiPhoneみたいな端末が
ビジネスプラットフォームとしてPCを置き換えるというのは苦しいな。
そもそもAppleやGoogle自身がPCが別にある事を想定している。

>>995
x86の可変長デコードど比べると些細な問題だと思うのだけど。。。
固定長RISC比3割増しのコードに何か問題でもあるの？
ちょっとコードサイズがでかくなるだけだ

>>997
デスクトップ仮想化の流れも進んでいる
アプリの実行はサーバ上で実行した仮想PC上で動かす
そうなると端末はx86である必要性はない

三菱東京UFJ、海外支店にデスクトップ仮想化ソリューションを導入
http://www.itmedia.co.jp/enterprise/articles/1107/26/news060.html

三菱東京UFJ銀行、3000台の仮想デスクトップを配備
http://www.itmedia.co.jp/enterprise/articles/1005/31/news066.html

1000なら次スレが立つ

1台のマシンが組み上がりました。。。
新しい筐体を用意してくださいです。。。。

　　　　　　　　　自作PC板＠2ch http://anago.2ch.net/jisaku/