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

ヘネシー&パターソン
あるいは河童の屁

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

【過去スレ】

Part 1 http://pc5.2ch.net/test/read.cgi/jisaku/1082357989/
Part 2 http://pc7.2ch.net/test/read.cgi/jisaku/1101041110/
Part 3 http://pc7.2ch.net/test/read.cgi/jisaku/1139046363/
Part 4 http://pc7.2ch.net/test/read.cgi/jisaku/1151732227/
Part 5 http://pc9.2ch.net/test/read.cgi/jisaku/1159238563/
Part 6 http://pc9.2ch.net/test/read.cgi/jisaku/1169393906/
Part 7 http://pc11.2ch.net/test/read.cgi/jisaku/1172923824/
Part 8 http://pc11.2ch.net/test/read.cgi/jisaku/1178140550/
Part 9 http://pc11.2ch.net/test/read.cgi/jisaku/1186887760/
Part10 http://pc11.2ch.net/test/read.cgi/jisaku/1202913839/
Part11 http://pc11.2ch.net/test/read.cgi/jisaku/1214999146/
Part12 http://pc11.2ch.net/test/read.cgi/jisaku/1219884494/
Part13 http://pc11.2ch.net/test/read.cgi/jisaku/1223189876/
Part14 http://pc11.2ch.net/test/read.cgi/jisaku/1231064800/
Part15 http://pc11.2ch.net/test/read.cgi/jisaku/1235699613/
Part16 http://pc11.2ch.net/test/read.cgi/jisaku/1253517890/
Part17 http://hibari.2ch.net/test/read.cgi/jisaku/1274809074/
Part18 http://hibari.2ch.net/test/read.cgi/jisaku/1290758715/
Part19 http://hibari.2ch.net/test/read.cgi/jisaku/1305200489/

>>1
ヘネパタ信者は氏ね。

>> 前スレ999
そういうの前からあるじゃん。古くはSunの提唱してたNCとかか？
むしろUNIXより更にもっと前からあるマルチユーザーシステムか。

クラウド（笑）って結局クライアントの処理性能が必要なくなったわけじゃなくてネットワークの向こうに
性能要求を押し付けてるだけなんだよね。
スマホが急激に普及したけど3G回線を圧迫して無線LANスポットだWiMAXだと言ってる。
Webサービスはサーバがパンク状態。

おかげでIntelはXeonが売れて万々歳だし、AndroidもOSの全ビルドにメモリ16GB以上のx64マシン推奨。
アプリ開発環境の要求も決して低スペックではない。
なんやかんやでパワーバランスは維持されるんだよな。

>>1
激しく乙です

ヘネパタもパタヘネも読んだことがない。。。
たぶん死ぬまで読まないだろう

前のPS3がどうとかよりはマシだと思うｗ
（そろそろ古いし）

>>4
読む必要なし。

KnuthもHacker's Delightsも読む必要なし。
大概の使いそうなビット操作はIntelの新命令対応リストに入ってるしｗ
（パズル的プログラミングすら楽しめなくなって個人的には面白くないが）

TAOCPは面白いのに

ところでさ、団子ってアーキテクチャの教科書的なもの、なんでもいいけど一冊でも読んだことあるの？

>>3
端末はシンクライアントで十分
サーバ1台あたり80台の仮想PCを動かせるそうだ
PCサーバ向けCPUがPC向けCPUと比べて80倍の利益稼げるのかな？


［VMworld 2010］三菱東京UFJ銀行が「デスクトップ仮想化」事例を講演
ttp://itpro.nikkeibp.co.jp/article/NEWS/20100902/351679/
テスト結果から見ると1サーバー当たり仮想マシンを100台動かせると分かったが、
障害対策の観点から80台に抑えた。「物理サーバーは5台を一組としてグループ化してある。
もし1台のサーバーに障害が発生しても、他の4台に仮想マシンを20台づつフェールオーバーすれば、
業務が継続できる計算だ」。徳永 上席調査役はこう理由を説明した

こうも書かれてる
NCはほとんど普及せずに絵に描いた餅だったがこの件は実際に導入されたケース


「最新サーバーであれば、1台当たりの仮想マシンを120台ぐらいまで増やせそうだ。
メモリーは96Gバイトから72Gバイトに減らす」。徳永 上席調査役は今後の方針をこう話す。
2010年度末までに、仮想デスクトップを1万6000台まで増やす計画である。

>>8
常識がなさすぎるお前にこそ問いたいわｗｗｗ

なにを言い出すかと思えばループアンローリングだのなんだのｗｗｗ
ソニーがCellで一時的に先祖がえり刺せようとしたけど結局一般に受け入れられずに終わったじゃないか。

>>10
この1サーバのスペック次第だな。Xeonも1ソケット30万以上で最大8ソケットまで対応している。
1台あたり240万なら1クライアント当たり3万。

これより一桁安くとも企業クライアントによく使われるCeleronなんて1個5000円程度だぜ。

>>11
団子の性格だと読んだことがあるなら超偉そうに報告するはずだが、やはり…

と思ったがスライドにHS22っておもっきし書いてあった
http://www-06.ibm.com/systems/jp/bladecenter/hardware/hs22/

少なくともたとえばCADとかCGとか使うような事業部に適用できるソリューションではないし
こういう事例を一般化するのは難しい。

CPUよりメモリは遅く、ネットワークIOは輪をかけて遅い
歴史的にこの乖離は悪化する一方っぽいので
いわゆるシンクライアントはあんまり筋が良いとは思わない

まあ集中管理できる事を利用して
運用コストを下げて元を取ろうって発想は分かるんだが

どっちにしろ、シンクライアントのシンってのは
サーバ機より性能が悪いって程度の意味しかないからな…
クライアントにさ、メモリ1Gでデュアルコア1GHzとかで動画や暗号化のアクセラレータもってんじゃ、
それこそ旧PCでも再利用した方が安上がりというか
わざわざarmとかで再設計するのもアレだよな…

>>13
お前の性格分析なんて下らないな。
K&RもStroustrup当然のことながらLoki本、More Effective C++は当然のことながら
HDも輸入した原書持ちだがハードカバーがよれよれになってコード丸暗記するくらい読んだわ
個人的に役に立ったのはMSの人の書いたassert本とATL Internalかな。

「Linuxは時代遅れだ」の迷言を残した教授さんの本も大学生協で買った訳書を何冊か
持ってたけどとっくに捨てた。

>>17
読んだことがあるなら超偉そうに報告するはずだが、やはり…

お前は俺の例示した本のタイトル半分も理解できなかったな。無理するな低スペックｗ
Knuthは一冊も買わなかったけど図書館で読んだわ。

>>19
読んだことがあるなら超偉そうに報告するはずだが、やはり…

シンクライアントにスマホ使う必要なんてないわな

>>13, >>18, >>19
なるほど、これがループアンロール（笑）か

冗長なコードは害悪だぞ

しばらく前のスレでも書いたんだが、最近シンクライアントの導入が進んでるのは
鯖と端末との計算機資源の綱引きの結果じゃなくて端末毎にソフトをインスコしたり
ウイルス対策したり情報流出制限したりとかの手間かけるより鯖側で集中管理した方が
端末ユーザが余計なことを出来ないようにする方が楽で安上がりだから。

団子の引き出しがつきたようだ。

俺は
>>8
> ところでさ、団子ってアーキテクチャの教科書的なもの、なんでもいいけど一冊でも読んだことあるの？
と聞いたわけ。

団子の返答は
>>11
> 常識がなさすぎるお前にこそ問いたいわｗｗｗ
>
> なにを言い出すかと思えばループアンローリングだのなんだのｗｗｗ
> ソニーがCellで一時的に先祖がえり刺せようとしたけど結局一般に受け入れられずに終わったじゃないか。
と、はぐらかしに始まり、

こんなスレでさえ粘着が付くとは
団子も一人前のコテだな

規制で書けんのう

>>17
(本文長すぎ規制により省略)
と、アーキテクチャとは関係のないプログラミングの本の自慢ばかりをし、

P&Hとか以外に教科書的なものなんてあるか？あれも古臭いけどな。
ちなみに1年のときに使ってた教科書の巻末にはSPARCの命令フォーマットのリファレンスが載ってたｗ

ていうかループアンロールがナウいなんてどこの世界の事象だよ20年時間軸がずれてんぞｗｗ

>>19
> お前は俺の例示した本のタイトル半分も理解できなかったな。無理するな低スペックｗ
> Knuthは一冊も買わなかったけど図書館で読んだわ。
ふたたび、アーキテクチャの教科書「以外」の本を読んだことを自慢し、

>>22
> なるほど、これがループアンロール（笑）か
>
> 冗長なコードは害悪だぞ
読書ネタが尽きた模様。

MMIX本も教科書っていえるのかなあれｗ
あんな玩具みたいな架空のCPUをテキストに使うくらいなら
基本情報試験のCASL-II/COMET-IIの試験対策本のほうがまだマシだが

>>29
> P&Hとか以外に教科書的なものなんてあるか？あれも古臭いけどな。
> ちなみに1年のときに使ってた教科書の巻末にはSPARCの命令フォーマットのリファレンスが載ってたｗ
ここまで、関係のないプログラミングの本ばかり挙げた挙句、ようやくこれだ。

もちろん団子がどちらもまともに読んだ素振りはない。(読んだなら偉そうに読んだと真っ先に報告するはずだ)
そしてまた>>32でトンチンカン。
俺はアーキテクチャの教科書は読んだのかと聞いたんだけどね…

関係が無い？

ループアンロール君がソフトウェアアーキテクチャなのかハードウェアアーキテクチャなのかすら示さずに
「アーキテクチャ」っていうから俺わけがわかんなかったんだよ、素で。

ループアンロールがナウいなんて時代錯誤の人間が「教科書」と思ってるような本なら少なくとも必要ないな。

> ループアンロール君がソフトウェアアーキテクチャなのかハードウェアアーキテクチャなのかすら示さずに
> 「アーキテクチャ」っていうから俺わけがわかんなかったんだよ、素で。
そいつぁかわいそうにな。手帳と年金もらいな。

http://e-words.jp/w/E382A2E383BCE382ADE38386E382AFE38381E383A3.html

> ハードウェア、OS、ネットワーク、アプリケーションソフトなどの基本設計や設計思想のこと。
> 元来、建築学における設計術あるいは建築様式を表していたのが、転じて、コンピュータ
> 用語として用いられるようになった。

ITに限定してもCPUに限定した用語ではないね「アーキテクチャ」は。

> 今日びインライン展開やループアンローリングのコストが下がり、ライブな値はますます増える一方だ

今日びレジスタ大量でインオーダのCPUなんてソニーすら放棄したし
どこの異次元の話なんだろうこれは？謎過ぎるｗｗｗ

CPUアーキテクチャのスレで
> ITに限定してもCPUに限定した用語ではないね「アーキテクチャ」は。
こんな居直りをする厚顔無恥は、教師生活25年初めてみた。

じゃあ、知恵遅れのためにもう一回聞くよ。
団子は計算機アーキテクチャの教科書的な本は、何を読んだんだい？

俺が真の意味で教科書だと思ってるのは「Intelアーキテクチャ最適化マニュアル」だけだよ

> じゃあ、知恵遅れのためにもう一回聞くよ。
ああ、お前自身のためか

とうとう一冊も読んでいないことを白状したな。
嘘をつかなかったことだけは褒めてもいい。

何この気持ち悪い教師…、団子以下だよ

大学の教科書そのものでディレイスロットとか分岐予測とかそのへんまで解説してたけどな。
いわゆる「Adapted from Computer Organization and Design」は副読本というか暇なら読んどけ
ってポジションだったけど教授も古臭くて実用性がないって言ってたしな。

今のところ口汚く団子罵る事しかしていないしな。
教師にしては教養がなさすぎるｗ

最後にこれだけ聞いて寝るか
> 今日びインライン展開やループアンローリングのコストが下がり、ライブな値はますます増える一方だ

こんなCPUどこにあるの？ｗｗｗ
むしろコンパイラやCPUのアウトオブオーダ実行機構の進化で
コードレベルの明示的なループアンロールの必要なんてほとんどなくなったし
最近どころかPentium IIとかIIIとかのあたりで既にアンロールの効果なんて実感できなくなってたよ。

>>46
教師だとしたらとんでもないロートルだな

NOP命令を12000個以上アンロールしたらPentium 4で速度1/3になった

>>47
> 最近どころかPentium IIとかIIIとかのあたりで既にアンロールの効果なんて実感できなくなってたよ。
レジスタが8個しかなければ無理にアンロールしても意味がないのは当然。
どうして、「x86では」アンロールはさほど効かないということが、「あらゆるアーキテクチャでも」効かないと短絡できるんだよ。

>>44>>46
俺は好き嫌いで判断するやつも嫌いでね
有益な情報はなるべく書く

マジで頭が悪いんだな。

もともとeax,ecx,edxの3つだけ使ってたのがesi,ediも使うようになっただけで
実行時間は誤差の範囲でしか変化しなかったオチ（むしろ若干落ちた）
同じコードをx86からx64に変えても大して変わらなかったね。

レジスタリネームもあるんだし、論理レジスタが増えさえすれば性能が伸びるとかいう辺りが
既に痴呆老人の思考パターンですよ。
ロートルはさっさと寝ろよ

>>51
じゃあ、ev7SLT8gの言う「計算機アーキテクチャの教科書的な本」で
まともな物って何があるの?

気持ち悪い教師から嫌われても特にw
あんたの書き込みのどこが有益なの?

>>49
> NOP命令を12000個以上アンロールしたらPentium 4で速度1/3になった
意味のない例をムキになってあげるのは、普通の社会では軽蔑の的になるから。
このスレは毒されてるかもしらんね。

>普通の社会では軽蔑の的になるから
ブーメランブーメラン♪

ID:ev7SLT8g ほど無益な人間は他に居ないな

>>54
団子叩き以外の全部と、「団子のどこが悪いか」の指摘全部が有益

自分にとっての間違いだろ>有益
公開オナニーショーもそういう趣味の人間には有益、と完全に一致

> 普通の社会では軽蔑の的になるから。
お前の「普通の社会」ではそうなんだろうな
お前の中だけではなｗ

>>59
好き嫌いでしか物事を考えられない奴は、ちょっと不快感を覚えると、すぐに自ら煽りはじるのが常

>すぐに自ら煽りはじるのが常
なんでこんなにブーメランが好きなの?

> 好き嫌いでしか物事を考えられない奴は、ちょっと不快感を覚えると、すぐに自ら煽りはじるのが常

その典型がこれか→　>>13>>18>>20

>>62
君自身に煽っている自覚はないのか？

> はじるのが常
恥じるのが常

>>64　←見事なまでのブーメラン発言

自分が来る前から団子煽りまくりの人間の言う事じゃないってだけさ>君自身に煽っている自覚
気持ち悪い教師にはそれ相応の対応だと思うね、残念ながら

ああ、俺はもちろん自覚して煽っているよ。前で宣言したつもりだったが忘れてたか。すまんね。

ループアンローリングなんて近代ソフトウェア工学では廃れた最適化手法などは恥じるのが常

急に団子擁護が沸いてきて気持ち悪い

本当に気持ちの悪い教師
教師とか言い出したあたりその気持ち悪さにでスルー出来なくなったｗｗｗ
前スレから延々と自称有益情報とやらを書き込んでるつもりらしいが
こんなキチガイの講義受けてる生徒もかわいそうだね
気に入らない生徒いびりとか、それこそ自覚を持って行ってるんだろうね、陰湿だね

ev7SLT8gはどうでもいい煽りあいをしていないで、

>有益な情報はなるべく書く
って書いたんだから、
「計算機アーキテクチャの教科書的な本」で、まともな物をはやく教えてよ。

団子擁護に見えるのもどうかと思うよｗ

擁護とか以前にID:ev7SLT8gが色々とメチャクチャ

いまどきのCPUでループアンローリング（笑）なんてincrement+branchの命令がちょっと減る程度の
実用性しかないんですけどね
内側でたとえばロード・ストアのスループットがネックになってる場合は効果が無い

Intelアーキテクチャマニュアル以上の教科書は無いよ。
東大出の某○oogle社員も言ってた

どーせ3流大学出の専門学校講師だろ

>>72
ごめん
俺の好きなのはこれ
MODERN PROCESSOR DESIGN: Fundamentals of Superscalar Processors, Beta Edition by John P. Shen, Mikko Lipasti and John Shen (Jul 22, 2002)
LipastiはValue Predictionの発明者。

もうひとつ。1999だからちょっと古い。
The Microarchitecture of Pipelined and Superscalar Computers by Amos R. Omondi
この辺を読んでおけばあとで論文読むときに困らない。

どちらも、たくさん読んだ中のベストじゃなくて、たまたま読んでみて悪くなかったやつだ。

日本語のだと中澤先生のが定評あるようだ。

ちなみにMODERN PROCESSOR DESIGNのほうは、NexGenのRISC86がそこそこ載ってるから物好きにもいいぞ

ループアンローリングがどうとか言ってる時点で知識が無いのは明白。
こいつググった程度の知識しか無いから絡むだけ無駄だよ。

L1Iの容量が増えない理由がただしく理解できてればあんなトンデモ発言できねーしｗ

まさに、恥じるのが常

>>75
いつの時代の認識だよ。
今日日のループアンローリングは演算やメモリアクセスの遅延を隠蔽できるよう
スケジューリングの対象領域を広くするためのものだ。
前スレで俺以外の落ち着いた人に指摘されたのを忘れたのか。
というか、都合の悪いことは意図的に聞かなかったフリをするのが団子だったな。

はいご老人がまた蒙昧な発言を反復し始めました。

ループアンローリングはほとんど無意味なんてこと最適化マニュアルにも普通に書いてあることなんだけどね
別にレジスタ本数の話じゃないんだけどね。レジスタ本数のせいにするあたりが既に痴呆。

これでも読んどけ　http://www.cs.iastate.edu/~prabhu/Tutorial/PIPELINE/loopUnrolling.html

団子は痛いところをつかれると
> はいご老人がまた蒙昧な発言を反復し始めました。
と人格攻撃に走るのでわかりやすいですね。

これ前提とするアーキがインオーダっぽいなｗ
テキトーにググってごまかしても知識の無さを露呈するだけなのに。

> for (i=1; i<=1000; i++)
> x[i] = x[i] + s;

こんなコードはリネーミング機構さえあればx87のスタックレジスタ1本＋ecxだけで十分だろｗｗｗ
SSEサポート不要、Pentium Proで十分ｗｗｗｗ
直感でレジスタリネーミングきくかどうかなんてわかるぞ。

ID:ev7SLT8gが同じセリフを延々繰り返す人工無能なのはわかった

こんなレジスタリネーミングが効くケースの判別すらできない無能の知識なんて薄っぺら過ぎる

おいいいいいいいいいいい

ごばーく

>>87
原理を学ぶための例を特定の実装を基準に考えてどうするよ…

>>88
やる気か？w

ちなみにMODERN〜読んだならレジスタリネーミングについては詳しく載ってたはずだけどな
おそらく目を通しただけで頭に入って無いんだろうな

SSE2スカラで処理した場合

　　movsd xmm0, qword ptr [s]
　　mov ecx, 1000
lp1:
　　movsd xmm0, [esi+ecx*8]
　　addsd xmm0, xmm1
　　movsd [esi+ecx*8], xmm0
　　dec ecx
　　jnz lp1

Sandy Bridgeならこんなコード1000サイクル＋αで処理できるよ。
アンロール？いらねーよﾊﾞｰｶｗｗｗ

Sandy Bridgeなら、と断ったのはこれ未満のアーキでは勿論同時命令発行数の縛りがあるから。
3issue以下なら【dec+jnzの回数を削る目的でのみ】アンロールは有効。

アンロールすべきループとそうでないループの区別がつかない(あるいはそういう区別があるということすら知らない)から
こんなクソみたいな例をあげて喜んでいられるんだよな。
自分の無知に気づかずにいられるのは決して幸せなことじゃないぞ、団子。

お前がそのクソみたいな例を出したんだが？
少ない論理レジスタでも十分性能が出せる、リネームが効く典型をなｗｗ

団子は数行の、ほとんど意味のないコード片がx86ではこれだけ速いとご満悦だが
もしかして、プロセッサの性能評価の方法論があることすら知らないのかもしれないという気がしてきた。

もう涙吹けよｗｗｗ
知識レベルが低すぎて話にならないｗｗｗｗ

>>96
俺が出した例は、例題プログラムと例題プロセッサが組になっているわけだがな…

x86に限定しなくてもこの程度でアンローリングが必要なのはかなりレトロなCPUだぞ
お前はMODERN〜を本当に読んだのか？内容をまったく理解してない人間にしか見えない。

というかアンローリング同等のことをハード的にやってくれるのがレジスタリネーミングの目的ですし。
（IPFにはレジスタローテーションという機能があるしね）
こんなこともMODERN〜には書いてあった気がするが、読んでない人に説明しても無駄か。

しょせんID:ev7SLT8g の必死でググった知識なんてこんなもんだよ

>>99　←愚者は忙しいな。言い訳を考えるのに忙しいな。

賢者は間違ったときには「私が間違っていた」と言う。
愚者は「私のせいではない」と言う。
賢者は勝因は「運が良かった」と言う。例え運ではなかったとしても。
愚者は敗因を「運が悪かった」と言う。でも、運が原因ではない。
賢者は愚者よりも勤勉に働く。しかも時間は愚者より多い。
愚者はいつでも忙しい。文句を言うのに忙しい。
賢者は問題を真っ直ぐ通り抜ける。
愚者は問題の周りをグルグル回る。
賢者は償いによって謝意を示す。
愚者は謝罪をするが同じ間違いを繰り返す。
賢者は戦うべきところと妥協すべきところを心得ている。
愚者は妥協すべきでないところで妥協し、戦う価値がない所で戦う。
賢者は「自分はまだまだです」と言う。
愚者は自分より劣るものを見下す。
賢者は自分より勝るものに敬意を払い学び取ろうとする。
愚者は自分より勝るものを不快に思い、アラ捜しをする。
賢者は職務に誇りを持っている。
愚者は「雇われているだけです」と言う。
賢者は「もっと良い方法があるはずだ」と言う。
愚者は「何故変える必要があるんだ？今までうまくいっていたじゃないか」と言う。


ID:ev7SLT8g ＝愚者の典型だな

>>85
> ループアンローリングはほとんど無意味なんてこと最適化マニュアルにも普通に書いてあることなんだけどね
こんなことは書いていたがな

> 例 13-5c は、命令レベルの並列性を高め、乗算と加算におけるレイテンシーの発生をさら
> に抑える手法を示している。

> アンロールを 4 回行うことにより、各 ADDPS 命令を依存関
> 係がある更新命令の MULPS から離して配置できる。
> また、インターリーブ手法を使用することにより、
> 依存関係がない ADDPS と MULPS を近くに配置できる。

> MULPS と ADDPS
> を実行するハードウェアはパイプライン化されているので、この手法では、例 13-5b と比
> べてはるかに効果的にレイテンシーを隠すことができる。

この例題は乗算なんて全くつかわねーよボケ
知ったかぶり必死だな

>>100
団子> というかアンローリング同等のことをハード的にやってくれるのがレジスタリネーミングの目的ですし。
教師生活25年、こんな斬新な理解は初めてだ(号泣)
世界中さがしても唯一無二じゃないか。おめでとう。

ぶっちゃけ>>86は極論をいえば1000並列のベクトル演算器があれば1サイクルのスループットで処理できる問題ですし。
もしSSE単精度ベクトルなら250サイクル＋αだね。

>>86
そんな薄っぺらい理解力でよく自称教師なんてやってられるなｗｗｗ
馬鹿の典型

>>106
>>103は、インテル？ 64 アーキテクチャーおよび IA-32 アーキテクチャー最適化リファレンス・マニュアル
http://download.intel.com/jp/developer/jpdoc/248966-024JA.pdf
の13-16ページだな。

俺はフレックス使うけどあんた授業大丈夫か？ｗｗｗ
脳内教師の生保だから問題ないかｗｗｗ

>>110
アホか全然別の問題じゃねーか（真に依存関係がある場合の並列化）

団子> というかアンローリング同等のことをハード的にやってくれるのがレジスタリネーミングの目的ですし。
これは本当にひどい誤解ですが、君が自分で調べて訂正してここに報告すればこれ以上は叩きません。

> の13-16ページだな。
目次ですが？ｗｗｗ
あたまおかしすぎるｗｗｗ

> 13 インテル? Atom? マイクロアーキテクチャーとソフトウェアの最適化
ここならまだわかるがｗ

お前らいつ寝てるんだよ・・・

>>113
恥の上塗りにしかならないからやめとけ低脳ｗｗｗ
残念ですがお前の完全敗北ですｗｗｗ

>>115
電車の中かな

>>112
インテルのマニュアルに、アンロールがレイテンシの改善に役立つと書いてある例を出しました。
団子は> ループアンローリングはほとんど無意味なんてこと最適化マニュアルにも普通に書いてあることなんだけどね
これを立証できていません。

>>86とその移植版の>>93のケースで明示的なアンロールは無意味だ。
ロード命令をヒントにレジスタリネーミングで前後の依存関係が断ち切れて別々の物理レジスタが割り振れるからな

団子は「無意味な場合がある」と「あらゆる場合に無意味だ」の区別がつかないかわいそうな子のようです。

お前が出してきた例だろ
話すり替えんなアホ

Core2以降ループが安くなりすぎてるしSandyBridgeは長いループが不利なのはわかるけど
Bulldozerは結構アンロール効くよ
マイクロアーキテクチャ依存だろう

x86が使いにくいなと思うのは x16のアドレッシングモードがない事かな

団子> というかアンローリング同等のことをハード的にやってくれるのがレジスタリネーミングの目的ですし。
団子> というかアンローリング同等のことをハード的にやってくれるのがレジスタリネーミングの目的ですし。
団子> というかアンローリング同等のことをハード的にやってくれるのがレジスタリネーミングの目的ですし。
おやすみ

> アンロールを 4 回行うことにより、各 ADDPS 命令を依存関
> 係がある更新命令の MULPS から離して配置できる。
> また、インターリーブ手法を使用することにより、
> 依存関係がない ADDPS と MULPS を近くに配置できる。

て書いてあるとおり、これは依存関係がある例の並列化。
NehalemはMULPSのレイテンシが4なので4並列化で十分ってことだろう

>>86のようなループの場合値の依存関係がないのでレジスタリネーミングだけで自動アンロール可能

>>123
ばいばい負け犬

disp32もCore2の時はフェッチ帯域を消費するから
disp8になるように書き換えたりしたけど
uOPキャッシュができてからはほぼタダで使えるようになったし

>>122
>>86のケースはBulldozerでもそれほど必要ないと思うよ。
dec+jccとかはfusion効かなかったと思うからその分だけはアンロールでの命令削減が有効だけど

>>86のケースは問題ないのかもしれないが
BulldozerはALUが少ないから
SSEのコードのadd 16とかも地味に効いてくる

レジスタリネーミングがどういう場合に聞くのかこれはわかりやすいな
http://ocw.u-tokyo.ac.jp/wp-content/uploads/lecture-notes/IS_02/aca_04.pdf

「偽のデータ依存」のパターンなら同じ論理レジスタを読み替えて実行できる。
これは論理レジスタを無駄遣いしないための基本的なテクニックなんだけどな。


オッサンは　＼x86はレジスタが足りないからクソ／　ばっかし言ってるけど本当に足りてないのはこいつの脳味噌
本当にこんな馬鹿が教師なら生徒が気の毒すぎる。まあありえないが。

五島先生のアドバンストコンピュータアーキテクチャは
ここの住人なら必修にしていいレベル

>>129
おはよ
それを読んで、どうして
団子> というかアンローリング同等のことをハード的にやってくれるのがレジスタリネーミングの目的ですし。
こういう理解になるのか…

レジスタリネーミングというかOoOが、アンローリング＋スケジューリングと同じようなことを動的にやってくれる「場合もある」
しかしOoOはアンローリングだけでない、もっとずっと一般的な技術だわな。

それがなぜ団子にかかると
> というかアンローリング同等のことをハード的にやってくれるのがレジスタリネーミングの目的ですし。
こうなってしまうのだ。

団子> オッサンは　＼x86はレジスタが足りないからクソ／　ばっかし言ってるけど本当に足りてないのはこいつの脳味噌

団子はバカなだけならまだしも、他人が言ってもないことを言ったと主張するから困る。
俺は「一般論として」整数レジスタは16個あればまあ問題はなく、逆に浮動小数点レジスタはいくらでも欲しい、と言ったのだ。

団子> オッサンは　＼x86はレジスタが足りないからクソ／　ばっかし言ってるけど本当に足りてないのはこいつの脳味噌

「x86は」とも言ってないし、「足りないから」とも言ってないし、「クソ」とも言ってない。
言ったのは「レジスタ」だけだ。(言ったのも一回だけだ。「ばっかし言ってる」わけではない)
どうよ、この捏造ぶり。

なんか団子さんが少し太った気がするｗ

レイテンシがある命令を順次に実行する命令列ならアンロールした方がスループットがあがる
というだけで終わる話ではないのかな?

>>136
上にでてる例はAtomのインオーダパイプライン向けの最適化だから
レジスタリネーミング付きのOoOのマイクロアーキテクチャのほとんどでは
アンロールしてもmulapsのレイテンシの隠ぺいという意味はない

アンロールすると
add esi, 16/add edi, 16/sub ecx, 1/jnz top
はアンロールした分でまとめられるから
フェッチ帯域・デコード帯域・Int ALUの実行帯域がボトルネックの場合は有利になる

ただこの例では
SNB/BDの場合addpsのループ間の依存関係が支配的だから
アンロールしなくても変わんないと思う

例13-5 a〜cの話ね

なんにしろ、
> 今日びインライン展開やループアンローリングのコストが下がり、ライブな値はますます増える一方だ
これは無いわ。時代の推移を含めて一般論を言うならともかく、「今日び」で限定して
これは無いわー。日本の組み込み屋で自分の廻りが世界の全てな人なら、こういうこと言いそうだけど。

>>135
元々焼け太りの豚ですよ

13-5cみたいに加算の順序を変えていいならいろいろできるね
SandyBridgeはaddpsのレイテンシが3だから

top:
movaps xmm3, [esi]
movaps xmm4, [esi+16]
movaps xmm5, [esi+32]
mulps xmm3, [edi]
mulps xmm4, [edi+16]
mulps xmm5, [edi+32]
addps xmm0, xmm3
addps xmm1, xmm4
addps xmm2, xmm5
add esi, 48
add edi, 48
sub ecx, 3
jnz top

ただこれだと ALUボトルネックだから
ループ2回をアンロールして

top:
movaps xmm3, [esi]
movaps xmm4, [esi+16]
movaps xmm5, [esi+32]
mulps xmm3, [edi]
mulps xmm4, [edi+16]
mulps xmm5, [edi+32]
addps xmm0, xmm3
addps xmm1, xmm4
addps xmm2, xmm5
movaps xmm3, [esi+48]
movaps xmm4, [esi+64]
movaps xmm5, [esi+80]
mulps xmm3, [edi+48]
mulps xmm4, [edi+64]
mulps xmm5, [edi+80]
addps xmm0, xmm3
addps xmm1, xmm4
addps xmm2, xmm5
add esi, 96
add edi, 96
sub ecx, 6
jnz top

とするのが最強かな
試してないけど

>>137
あーあ、敢えて黙ってたのに言っちゃったｗ
馬鹿すぎて面白いからもっと無知を曝け出させようと思ったのにｗｗ

>>139
そもそも組み込みですらそういうCPUって皆無な気がするんだが
（ARM9以下のレンジになるとこいつが馬鹿の一つ覚えのように言ってるFPU自体が実装されてないことも珍しくない）

そもそもARMは整数の割り算命令が無いCPU…
積和演算命令はあるけど。
ARMv7もA系では整数割り算命令無い。コプロにお任せ!!

使用頻度から言えば妥当な判断だし、そういう割り切りは結構好きだけど。

RISCに分類されるCPUって除算命令がないのは別に珍しくないけどね。
SPARC厨がパイプラインを乱すから除算命令はクソだとかﾄﾞﾔ顔で言ってたな。

Teslaが載る前のRICC（Nehalem-DPベースのクラスタ）でTop500登録したときに
理論性能の9割オーバーのFLOPS数たたき出してたよな。

OoO+レジスタリネーミングつきのCISC ISAでFP/SIMDレジスタ16本って十分足りるし
逆にコアあたりのレジスタ128本PowerXCell採用クラスタが実効性能比7割どまり。
いまどき単純な論理レジスタの数なんて性能の決定的要因ではない。

スパコン1位の京で使われてるSPARC64 VIIIfxは浮動小数点レジスタを256本持ってる

スーパーコンピュータ向けＣＰＵSPARC64 VIIIfx について
ttp://www.ssken.gr.jp/MAINSITE/download/newsletter/2009/20091125-sci-2/lecture-4/ppt.pdf

だからなんだ？
SPARCの命令セットは積和命令のソースオペランドにメモリ（L1）を指定できないし
Venusはレジスタリネーミング機構を持っていない

SPARC64 VIIIfxの後継で16コアのSPARC64 IXfxがあるらしい

LSI、富士通と「SPARC64 IXfx」を共同で開発したことを発表
ttp://news.mynavi.jp/news/2011/11/16/001/index.html

しっかし、くっだらないガラパゴスCPUなんてこしらえた物だな
京こそ日本の科学技術の発展を阻害する害悪

SPARC64 VIIIfxは8コアなのに消費電力58W

ttp://www.ssken.gr.jp/MAINSITE/download/newsletter/2009/20091125-sci-2/lecture-4/ppt.pdf
SPARC64 VIIIfx Chip 概要? アーキテクチャ
8 コア
5 MB の共有L2キャッシュ
メモリコントローラ内蔵
クロック2 GHz
FMLの45nm CMOS
22.7mm x 22.6mm
760M トランジスタ
信号ピン数1271
ピーク性能
演算性能128GFlops
メモリスループット64GB/s
消費電力
58W (TYP, 30℃)
水冷

SPARC64 VIIIfxはTSMCの45nmで製造してるのに8コアで消費電力58W

富士通のFab維持に血税投資して結局TSMC？
何が国産だよ。
とっとと仕分けろ

あ、SPARC64 VIIIfxは富士通の45mnか
SPARC64 IXfxがTSMC 40nmだった

どっちみちくだらねーな。
そもそも45nmだ40nmだって言ってる時点で既に競争すべき分野を間違えてる。
2013年には22nmで50コア・150W以内で1TDLOPSのチップが出てくる。
1000億も投じてガラスパ確定じゃ世界の笑いものだな。

1T DP FLOPSね

互換性を求められる汎用CPUとリコンパイル前提なHPC・組み込み専用CPUでは最適なアプローチも違ってくる
京はライバルが更新の谷間の上手いタイミングで世界一取ったものだと思うよ

東工大のTSUBAME2.0でも1回だけとはいえ1位とれたんだが？
故意に無かったことにしたがってる文部科学省の馬鹿には呆れる。

floatはレジスタが多いほど性能よい
これが現実世界での事実
XEONがいくら性能よくても変えられない

> floatはレジスタが多いほど性能よい
FLOPS数は演算ユニットの数に比例するがレジスタの個数に比例しません

レジスタリネーミングは強力だけど
SandyBridgeレベルのものは相応のトランジスタ・消費電力と引き換えだから
論理レジスタを多くする代わりにスケジューラを単純にして
浮いた分のリソースを演算器に投入するというのは選択肢の一つだと思うよ

SPARC64 IXfxがTSMC 45nmで2GFlops/Wを実現しているということは
そうしたアプローチの有効性をいくらか支持していると思われる

まぁ京とかあの辺は正直仕分けたほうがいいとは思うけどね

>>158
1位にはなってないよ

22nmプロセスのHaswellの3.2GHz・8コアで理論上400GFLOPS程度、0.9かけでも360GFLOPSか。
ぶっちゃけるとMICにはそれほど市場規模を期待してないが
（とはいってもクソVenusよりは遙かに売れるだろうが）
世界で最も売れてるサーバプロセッサが、近々1チップでこれだけの性能を獲得することになるわけで
日本は1000億もかけるべきところを間違えてるとしかいいようがない。

45nmだ40nmだの割には効率がいいって言いたいんだろうけど、それが日本の技術（笑）の限界だし
遙か先のプロセスルールの製品を市場投入するIntelは、同じ土俵におりてきてくれない。

ああいう誰得なプロジェクトが通ってしまう原理がよくわからんよね

TSMCの28nm使った製品出てますけどね
Intelの22nmには敵わないけど
ttp://pc.watch.impress.co.jp/docs/news/20111222_501056.html

アレも富士通の独自のインタコネクトとか3次元トラス配線とか見るべきポイントもあると思うけどね
SPARCにする理由は1ミリもなかったと思うけど

>>163
ちなみにintelの2010年の研究開発費は66億ドル

日本産のステッパーも使われてる

富士通が作るHPCチップのベースに
SPARC64でなかったら何がありうるだろう?

京の筐体って8プロセッサの1ノードで1千万くらいだっけ。
価格競争力なさすぎるだろ。

>>168
富士通が使えて、ある程度今まで使われた実績のあるISAは
SPARC、MIPS、ARMくらいじゃないの？
もともとSPARC64やってたからSPARCを拡張するのは自然の流れでしょう
中国はMIPSで独自のマイクロアーキテクチャのCPU開発してるね

Transmeta Efficeonの製造だけならやってた

PRIMEHPC FX10
SPARC64 IXfx 16コア
1ラック 12ノード 5000万円

約2万円/GFlops
高いね

京は世界一にはなったけど、ある意味行き止まりなんだよな。
こっから伸びしろはない。ガラパゴスに税金つぎ込むなよ。

いい加減にABS命令載せろよクソインテル
クロックの上がらない命令は避けてんじゃねぇよ

MACオタがいないだけでこの勢いw
いないならいないで問題だよな｡

>>174
つPABSB/PABSW/PABSD

>>163
Ivyで10コアいくから
Haswellも10コアでしょう

加減算が1サイクルでできるのになんでクロック上がらないと思ったんだろう？
ひょっとしてなんか別のABS？

>>136
ループをアンロールすると、ループボディが大きくなるので、
静的スケジューリングでレイテンシの大きな命令をできるだけ前に持ってくる時に、候補が増える。

>>139
単純に、昔にくらべて命令キャッシュが増えたので、例えば同じループならアンロールできる段数が増えたとか、そういう話なんだけど。
まさに
> 時代の推移を含めて一般論
のつもりだけど、「今日び」のどこが気に食わなかったのか理解しかねる。

最近のRSエントリが山盛りのCPUだと
そもそも静的スケジューリングの効果が薄いんでないの？

L2以下なら増えてるけどL1Iの容量なんて16〜64KBのまま10年以上停滞してるけどな

>>137
ありがとう。ありゃAtomだったのか。

>>145
団子はどうして条件もそろってない比較ひとつで結論を出すんだ。
x86とPowerXCellにはレジスタ本数差よりもはるかに大きなアーキテクチャ的な差があるじゃないか。

アンローリングやインライン展開が効果的なんていわれたのなんて近年だとCell（SPE)くらいじゃないのｗｗｗ
あれは256KBに収まる範囲内でならレイテンシは同じだし。
というかここ近年でinlineキーワードとかunrollオプションでめいっぱいコードサイズを展開できるCPU
（およびそれ用のコンパイラ）なんてCell（当然オワコン）以外知らないｗｗｗ

俺もテンプレ使って故意にループを展開したりあと関数の強制インライン化のオプション
試すことがあるけど、展開させることあるけど、多用するとキャッシュミスが多発して
かえって全体のパフォーマンス落ちるケースの方が多いんだよね。
（このへんの実践テクニックは「C++パフォーマンス戦略」あたりでも触れている）

本当に必要なのはプロファイルをとり一番実効時間を食ってる関数を特定することと
命令・データともキャッシュミス率をいかに抑えるかだ。

いまどきのCPUでは小手先の手動命令スケジューリングなんて殆ど役たないし
キャッシュミスを減らすことに尽力した方がいい。
特に無闇にやたらに「アンロールすれば速くなる」なんて思ってる知ったかぶりには
コードを触らせないことが特効薬かもしれないね。

13章まるまるAtom向けの最適化って書いてあるんだがｗｗｗ
ﾊﾞｶｼﾞｬﾈｰﾉｗｗｗ

>>161
> 論理レジスタを多くする代わりにスケジューラを単純にして
> 浮いた分のリソースを演算器に投入するというのは選択肢の一つだと思うよ

論理レジスタが多ければ、逆依存や出力依存は少なくできるからね
レイテンシも読みきって静的スケジューリングするなら、OoOの出る幕ではないな
ま、そこまで完璧にいくことはまあないけどね

団子さん、x86最適化の本書いてください。
アセンブラの本で勉強したけど、あれじゃぁ内部のレイテンシやスループットを意識した組み方ができまへん。

http://www.agner.org/optimize/
最適化するならここは基本

>>183
レジスタ本数込みでのアーキテクチャ差だろ
自分がレジスタ本数がどうこう言ってたのの反証出されると今度は条件が揃ってないからって子供の言い訳かよ
お前団子が嫌いだから団子を腐すための反論のための反論してるようにしか見えん

>>189
> レジスタ本数込みでのアーキテクチャ差だろ

レジスタ本数の違いが性能に与える影響を調べるには、レジスタ本数以外の条件を(なるべく)一緒にしなけりゃならん。
これは、わかるよな？
x86はいいとしてPowerXCellはCELLアーキテクチャだ。プログラミングモデルからして違う。

>>187
それさ、ちゃんとボトルネック分析はできてる？

本当に最適化すべき場所を特定しないでいきなりコードレベルの最適化に走ると
ドツボにはまりますよ。
SSEを使えば2倍4倍に速くなるとか思う前にまずは問題を切り分けること。
LUTだのハード依存のコードだのを選択するのはそれからでいい。

Intel固有の最適化ならIntelが出してる本以上のことを書いてるものなんてほとんど無いと思うよ。
SSE*なんちゃらとか書籍として出てるものは最適化マニュアルを若干噛み砕いた劣化コピー。

ぶっちゃけIntelにメールで頼めばPDFの内容を製本したもの送ってくれますよ。

x86とAMD64で比べればいいじゃない
その程度の差だよ

>>192
それができればそれですむことなんだが、
知りたいのは8個と16個の差じゃないからね。
浮動小数点レジスタが16個と、それ以上の場合の違いが論点になっている。

同じアーキテクチャの系統でもスループット重視かシングルタスク性能重視かで設計変えるから違うコアになるのに
レジスタ本数が違うほど変えて"なるべく一緒に"なんて端から無理な注文じゃん

>>188
ぎゃー、英語ムズいっす orz

>>191
どもです。
やっぱIntelのドキュメントですか。
がんばって読みますん。

>>193
x86とAMD64の
8本と16本の差で数%しか変わらんのだから
それ以上増やしてもほとんど変わらんだろ

レジスタ本数を増やす効果は逓減すると思ってるんだけど
そうじゃない理由があるの？

SONY CSラボの人が昔Agnerの最適化マニュアルを日本語訳してvectorのページにあげてたけど
あれ無くなったっけ？

大分古い奴だけどさ。

富士通がNehalemクラスタで理論FLOPSの90%を超えるHPLの数字叩き出してるのに
16レジスタが足りないだのわめくのは頭が悪い証拠です。

>>194
> レジスタ本数が違うほど変えて"なるべく一緒に"なんて端から無理な注文じゃん

ちゃんとした論文ではエミュレーションでやりますね。
だいたいの傾向がわかればいいのなら、VenusとVenus前で比較すればいいし。

>>196
> レジスタ本数を増やす効果は逓減すると思ってるんだけど
> そうじゃない理由があるの？

浮動小数点計算をするプログラムは、多くの場合、コンパイル時にレジスタを使い切るまでループアンロールするよう指示します。
アンロール後のループ本体は、オリジナルの本体よりもかなり大きくなります。
ループ本体が大きくなると、静的スケジューリングの対象が増え、より高速なバイナリがされます。

俺が今使ってるコンパイラはそんなことしないよ
ICC 12.1

最近のx86は極めて特殊なCPUだから議論の外ってこと？

>>198
サンプル一つだけで、よりによってベンチマークとしては非常に筋が悪いと叩かれているLINPACKの結果だけで判断する団子に乾杯。

>>201
それはアンロールができるほどレジスタがないからでは。

別にFFTでもいいけどTOP500はHPLのスコア順だし、LINPACKの否定は京の否定にもなるわな。

特にSandyだと下手にアンロールしまくるとuop cacheが効かなくなるからな
agnerもアンロールすんなって言ってる

>>203
お前はレジスタリネーミングできるケースを理解できる脳味噌が足りないのでは？

そもそもこの人はOoOもレジスタリネーミングもしないアーキを前提に言ってるのか知らんが
とにかく噛み合ってない

>>205
というかμOPs cacheの格納効率考えると強制インライン展開とかもたいがい蛇足だね。

N-bodyのコアループもXMMレジスタ13本でお釣りが来るしな（リネーム前提）
レジスタ16本で不足するケースって何があるだろ？

>>205
なるほど。
でもまあ今はそれは特殊例だな。将来はともかく。

>>206
アンロールはコンパイラか人手で行うもので、レジスタリネームはハードウェアが行うものだが、一体どういう繋がりが…

>>203
いや、例えばループ内ではxmm0~2までしか使わずに
アンロールはしないようなコードも出てくるよ

最近のx86でアンロールした方が速いケースというのは
ループ本体が数命令程度と小さい場合か
特殊化することでコードを簡単にできる場合くらいじゃないの？

インオーダやRSの小さいOoOでループアンロールが
命令のレイテンシ隠蔽に効果が高いのは理解するけど
SandyBridgeの54エントリのRSでどうにもならないってどんな場合？

あとまぁこれはCore2〜Nehalemの特殊例かもしれないけど
register fileのポート数が少ないから
loop invariantはレジスタに置かずにL1から読んだ方が速いケースが結構ある

> SandyBridgeの54エントリのRSでどうにもならないってどんな場合？

L1キャッシュ範囲内のRead＋FADD+FMUL+Shuffle+Writeのレイテンシ全部足しても54には届かないので
実用上皆無だね。
逆にL2以下のデータなんてそもそもスケジューリングそのものが不可能だし

>>212
ロード融合命令推奨ってむしろAMDのほうがその傾向つよくね？
理由はマニュアルにしっかり書いてあるが（むしろ分けるとボトルネック）

>>211
アンロールの目的は、
ループ本体を大型化し、スケジューラによる並列度の抽出やレイテンシの隠蔽の機会を増大させることです。
で、スケジューラが頑張るほどliveな値が増え、より多くの「論理」レジスタが必要とされるわけです。

>>211
> いや、例えばループ内ではxmm0~2までしか使わずに
> アンロールはしないようなコードも出てくるよ

上にも書いたとおり、アンロールしてもスケジューラが頑張る機会がない場合には、アンロールしないんでしょう。

> SandyBridgeの54エントリのRSでどうにもならないってどんな場合？

アンロールでがんばると、スケジューリング対象の範囲がアンロール後ループ本体になります。
これはRSの54エントリよりはずっと大きい。

隠蔽しなければならないレイテンシに対して
RSで並べ替えられる範囲が十分大きければ
静的なスケジューラが頑張る必要はない
ゆえに論理レジスタ数も必要ないと理解してるんだけど

そうではないということ？
それとも隠蔽すべきレイテンシとしてL2とかの大きいものが想定されているということ？

>>216
> 隠蔽しなければならないレイテンシに対して
> RSで並べ替えられる範囲が十分大きければ
> 静的なスケジューラが頑張る必要はない
> ゆえに論理レジスタ数も必要ないと理解してるんだけど

おっしゃる通りです。

> それとも隠蔽すべきレイテンシとしてL2とかの大きいものが想定されているということ？

その通りです。
レイテンシ隠蔽の埋め草を、非常に遠く先の命令まで探しにいく必要があるということです。
また、長レイテンシ命令は、すべて見つけ出し可能な限り早く実行しなければなりません。(これはRSでは困難です)

これを静的に実現するのがループアンロールとスケジュールの組み合わせです。
レジスタリネーム+RSがやっていることとは本質的には同じですから、
論理レジスタより物理レジスタのほうが多いという事実から、アンロールが論理レジスタを要求するということは類推できるでしょう。

大本営発表だけど
http://www.ssken.gr.jp/MAINSITE/download/newsletter/2010/20101020-sci-2/lecture-4/ppt.pdf
にレジスタ拡張についての評価が載ってる

>>197
まだあるよ
http://hp.vector.co.jp/authors/VA003988/how_to_o.htm

x86以外ならレジスタ間の演算はともかく、メモリの読み書きをリオーダーしないOoOは結構あるんじゃないの？

RAWハザードの回避ってコストでかいからね
でもメモリの読み込み（レジスタ全更新）でリネームできないOoOは欠陥としか言いようが無いぞ

> > SandyBridgeの54エントリのRSでどうにもならないってどんな場合？
>
> アンロールでがんばると、スケジューリング対象の範囲がアンロール後ループ本体になります。
> これはRSの54エントリよりはずっと大きい。

これはつまり、アンロールをするからアンロールが必要になるという手段と目的が自己完結した
もっとも馬鹿な例だな。

>>221
おお、確かに意味不明だな。さんきゅ。

> アンロールでがんばると、スケジューリング対象の範囲がアンロール後ループ本体になります。

アンロールを行うと、スケジューリング対象の範囲がループの1イテレーション分からアンロール段数分に拡大します。

に訂正しとく。

>>217
ランダムアクセスでなければL1ヒットの場合が多いと期待できるから
レイテンシは確率的でかつ平均レイテンシと最悪レイテンシが乖離するので
SMTの方が効果が高い場合も多いんじゃない？

>>218
>HPC-ACEで、使用するFR数を32個と256個として性能を比較
>約140本の実コード中、73%のコードで効果を確認、平均で1.2倍の
>性能向上
分布が興味深いね
半分くらいのコードではほとんど効果がない
一定以上のレジスタ数で効果が飽和してくるのかな

CPUがいろいろだから最適化のアプローチもいろいろなわけで

例えば話をIntelのHPCに限ったとしても
MICの方はなかなかOoOにならないわけで

アンロールするかしないかなんて
使ってる環境が○○ならする、××ならしない、という話にしか
ならないんじゃないかな?

> ランダムアクセスでなければL1ヒットの場合が多いと期待できるから

浮動小数点アプリの場合はメモリアクセスパターンが比較的シンプルなので
逆に「L1にはあたらない」ということがわかることも少なくありません。

Itanium2みたいに浮動小数点レジスタがL1にアクセスできないものもあります。

>>224
なぜ○○ならアンロールするのか、何段すればよいのか決めなければなりませんが、
そのための根拠が必要です。
その根拠となる考え方を、一般論で語ってきたわけですが。

ストライドアクセスとかならHWプリフェッチが有効になるんじゃない？

>>227
L2へのプリフェッチなら有効だと思います。
L1へのプリフェッチはかわりに必要なラインを追い出してしまうため、まずやらないと思います。

たしかにL1へのプリフェッチは次ライン読み込みくらいだね

> SMTの方が効果が高い場合も多いんじゃない？

1スレッドあたりで使えるL1キャッシュが半分になり、L2の読み書き頻度が増えるので
必ずしもパフォーマンスにいい影響を与えるわけではないね。

LinpackやFFTなんかだとHyper-Threading使うとかえって性能が落ちることが多かったはず。
Nehalem以降のXeonスパコンはSMTを無効にして納入されてることが多いし、
「HPC用」という位置づけのマルチソケット対応Nehalem-EXの6コア
Xeon X7542は同シリーズ中最高クロックながら2000ドルを切る価格設定だが
そのかわりにHTサポートを無効化（有効にできない）して出荷してる。

>>223
HPC-ACEは256ビット分のFMAC操作で8ビットのオペランドフィールドをフルに使うと
前置命令＋命令1＋命令2で3命令かかるクソISAですから。
FRが32本といってもレジスタリネーミングもメモリ間接アドレッシングもないのでx86のSSEと比べて
決してリッチというわけではない。

256本とはいっても2命令で追加レジスタにアクセスするのに1命令の前置命令が必要になるので
単純に命令数は1.5倍になる。
デコード帯域が4命令/サイクルしかないのに2つのSIMD-FMACを操作するだけで3命令。
当然ロード・ストア命令もFR32-127を指定するのに前置命令が必要になるので
L1キャッシュへのアクセスを同時発行してる余裕なんて最初からないんです。

HPC-ACEアーキテクチャにおける同時アクセス可能なレジスタが多いというメリットは、
レジスタ上でこね回さないと性能が出ないというパフォーマンスの制約と紙一重ってこと。

>>228
コンパイラがアクセスパターンをそれなりに認識できるという前提なら
コンパイラによるプリフェッチ命令の挿入で
静的な命令並べ替えと同様の効果を論理レジスタを消費せずに得られるんでない？

>>230
逆に言えばGEMMやFFTでは1スレッド16本の論理レジスタで
十分レイテンシを隠蔽できているということなんだよね

Sandy Bridgeは128b/256bの Load(+broadcast)+FMUL+FADDをしてついでに
時々ストアもやる程度の余裕はあるのでそれほどレジスタが少ないことはデメリットにならないね。
論理レジスタが多いよりは毎サイクルL1にアクセスできるほうが俺は使いやすいと思うね。

>>219
ありがとうございます！
しっかり読ませていただきます！

>>231
プリフェッチはメモリアクセスなので実行ユニットも使い、オーバーヘッドがある。
プリフェッチはタイミングが難しい。早すぎても遅すぎてもいけない。
動的スケジューリングのみで適切なタイミングで発行するのは難しい。

>>231
レイテンシがわかっている場合は、静的スケジューリングのほうが有利。
アンローリングによる並列度の向上。
RSエントリ数よりはるかに広い範囲から並列発行可能な命令を探せる。

お前の言ってる最適化ってCell SPEにしか通用しねーんだよ

インオーダで鍛えられたからアウトオブオーダでもやれると無駄にプライド高いとｗｗ
自作錯誤のゴミ人材をゲーム業界に大量に生み出したソニーは罪深いな。

時代錯誤ね

スレ伸びてると思ったら団子が寝ないで必死だった。

寝ないで出勤したのは金曜だけ。
徹夜明けはローソンVLの900mlのブラック無糖コーヒーをラッパ飲みまじでおすすめ。
105円でみんみんだはより効く。

デメリットは今日の今まで胃がもたれて変にテンションがおかしくなること。

しまった今日が金曜で昨日が木曜だった

>>235
実行ユニット使ってしまうのはともかく、タイミング難しいのはアンロールも一緒じゃない？
- L2に乗ってるかどうかわからん
- メモリアクセスしたらレイテンシ予測できない
- ものによってはL2もレイテンシ予測できない

読み込みの問題でなくて、
for () { a = read b = f(a); store(b); }
みたいなループがあった時に、アンロールして手でメモリアクセス並び替える必要があるから、
x86以外だと、OoOでもアンロール有効な場合って結構あるんではないの？と、言いたかった。
とは言っても、大半の人は、そんなプロセッサで最適化することはないからアンロールが必要な場面なんてほとんど無いと思うけど。

【社説】 「韓国大統領、慰安婦問題で日本に誠意求める…なぜそう主張するのか」「韓国の人は、日本の資金出しや謝罪知って」…朝日★４
http://uni.2ch.net/test/read.cgi/newsplus/1324371760/

ゲーム業界もハード屋のわがままで潰しのきかない最適化技術わざわざ覚えさせられて大変だな。
SONYもVitaでコモディティなプロセッサ採用したからCellプログラマは見捨てられたようなもんだが。

>>243
たとえば関数f()が1命令だけなら使うレジスタは1本だけだろ？
readの時点で依存関係を解消して別の物理レジスタをアロケートするヒントになるから
そういう単純なケースではアンロールは必要ないな。
問題になるのはストアアドレスが予測しづらい場合だけだ。

典型的な2ch脳だな。
最後に主張したら勝ち。
非を認めなければ負けではないと言う考え。
2chでは強制力のある存在がほとんどいないからそれで通るが、
社会では無視して強制執行されて終了。

ちなみに次のイテレーションが前の値に依存関係がある場合アンロールしてもどうにもならない。
ループの内側の命令がすくなすぎてインクリメント・条件分岐のオーバーヘッドが相対的に
大きい場合に限ってx86を含むモダンなプロセッサでもアンロールは有効だが、そもそも内側の命令数が
少ないならレジスタが不足しようがない。

コンパイラで自動的に静的スケジューリングする場合は
Ｃ言語の制約は大きいよね

例えばsourceとdestinationのポインタを取る関数だと
そのメモリ上での位置関係が明らかでないから
読み書きの順序にプログラマの意図しない制約ができてしまう

その場合でもmemory disambiguationは投機実行であるので
読み書き順の入れ替えが可能になる

Fortran使えという話はあるが

ARMならストアアドレスの予測とかしないでは？
ttps://gist.github.com/1513601
とりあえず手元にあったCortex-A9だけ測ってみた。
一応、Cortex-A9はOoOだけど、アンロール+ハンドスケジューリングが効くように見える。
というか、Cortex-A9がOoOに見えないんだけど、FPUはin-orderとかの制限あるんだっけ…

A9はROBもないしRSも浅いよ

>>250
そうなのか。情報どうも。
じゃあ、数命令程度並びかわるぐらいなのか…

Intel、次世代Hyper-Threadingテクノロジを公開
http://pc.watch.impress.co.jp/docs/2003/0222/kaigai01.htm

＞投機的マルチスレッディングはこの問題を解決する『打ち出の小槌』だ。
＞投機スレッドを走らせることで、必要なデータを完全にプリフェッチしてしまう。
＞それによって、DRAMアクセスのレイテンシを完全に隠蔽して、CPUの性能をブーストする。

これ、すごくイイ機能だと思ったんですが、
なぜ採用されずに今に至っているんでしょう？？

投機失敗した分がまるまる無駄な電力増になって
電力性能が大変なことになるから

なるほど･･･。
ちょうどプレスコで騒ぎ出してた頃だから、なおさらっスね･･･。

>>252
こういう自動処理って融通利かないから下手すりゃ帯域食って逆に遅くなる
予想できるなら横着しないでプログラムにプリフェッチさせとけばいいだけだし
そもそもレイテンシを隠蔽するためにハイパースレッディングが作られたんだし

SSEのプリフェッチもやり過ぎると帯域圧迫することになりますし、あれと同じですね。

やはりレイテンシの隠蔽が大きなポイントですね。
メインメモリをSRAMにするなりして、そもそものレイテンシを小さくするアプローチも是非とってほしい次第です。
DRAMコントローラ内蔵とかで少しずつ良くはなってるみたいですが。

Sunも一時期（潰れる前）やってたけど再コンパイルして投機処理用のスレッドをわざわざ生成する必要があるとか。
そういう方法とるなら明示的にプリフェッチした方がマシだし決してタダメシ食い用の技術ではない。

Sandy Bridgeのダイを全てSRAMで埋めたとしても32MBぐらいにしかならないじゃん。
http://pc.watch.impress.co.jp/img/pcw/docs/318/033/html/kaigai4.jpg.html

価格的に全くペイしないと思う。

実際に作ったところで、基板まで配線を引き出して結線するんじゃ、アクセスが遅くなっちゃうよ。
オンチップで配線しないと意味無い。

＞オンチップで配線しないと意味無い。
それもそうですね。
TSVなんかでスタックすれば配線のスピードは稼げるかと思うんですが、
アクセス粒度が大きいのが問題でしょうか。
WideIOではリージョン分けでマシにはしてるようですが、やはりアプリケーションは選ぶような気が･･･。

メインメモリとはしなくても、GPUのローカルシェアみたいな、
独立したメモリ空間を持つ領域を設ければ、
クリティカルな部分はプログラマが明示的にアロケートできると思うんですが、
実際のところプログラミングを煩雑にするだけでしょうか･･･。
GPUプログラミングも、性能をフルに出す難しさが取り沙汰されてるようですし･･･。

オンダイとは言わないまでもオンパッケージなら…
それなんてSlot1

>>259
メインメモリとはしなくても、高速なSRAMをDRAMの間に設けて、
メモリアクセスのレイテンシを隠蔽する技術がありましてね、キャッシュって言うんですよ。

キャッシュは既存のプログラミングモデルを大きく変えずに使えるので重宝されています。

>>261
キャッシュを明示的に操作する必要が出るくらいなら、もはやキャッシュじゃ
なくてもっとプリミテブなオンダイのスクラッチパッドメモリで良くね？
って話かと。

>>262
CellのLSが上手く行ってるとは思えないなぁ。
あれはプログラムをしにくくしただけだと思う。

スクラッチパッドメモリならアンロールしてもキャッシュヒット率を気にする必要も無いしね。
PSVitaのCPU（Cortex-A9ベース）の設計は、実はCellのときと同じソニー・東芝・IBMの3社連合。
もはやCellは生みの親にも否定された鬼子だよ。

SPARC64 VIIIfxのセクタキャッシュじゃだめなんか

>>265
これインテルのアーキには載らないのかな？
ちょっと使ってみたい。
Cellよりもずっと使いやすそうだ。

別に従来キャッシュでいいじゃん。
明示的なノンテンポラルロード・ストア命令を活用し、一度読み書きしたら二度とキャッシュ上に
残しておく必要の無いデータはさっさと追い出せばよい。

DDR SD RAM系のDRAMの性能向上は既に物理的に頭打ち状態だから、
この状況を打開する為にはRD RAM系のDRAMに移行しなきゃ駄目って事？

>>264
携帯機でのMIPSからARMへの乗り換えであって
据え置きコンソールの行方はまだ定まってはいないかと。
IBM&PowerPCに依らずに、東芝とARMではたして作れるのかどうか。

いや、PSPはPS2のモバイル版、VitaはPS3のという関係を当てはめるなら
PS3プログラマ居場所ないよってことでしょ。

PS2・PSPのはMIPSとはいっても独自にカスタマイズした実装だし、
スマホやタブレットにも使われてるCortex-A9のIPをそのまま採用したのは
ガラパゴスなハードウェアアーキテクチャに囲い込む戦略の終焉を意味する。

東芝もソニーもファブライトあるいはファブレス化の流れだし独自アーキテクチャで
ゴリ押しするのはもう難しいのでは？

>>270
元々コンシューマゲーム機は世代毎にノウハウ使い捨てだから心配しなくて大丈夫だよ

>>271
互換性を捨てたハードや互換を軽視したハードは苦戦するし、
旧世代ハードが壊れた後の救済策が無いとレトロゲーマーの反感を買う事になる。

PS3はPS2切り捨てたしVitaもUMDドライブないぞ

レゲーを遊ぶにはエミュしかないのか

>>268
DRAMチップの進化は、大した進歩ができないDRAMセルを、
DRAMチップ内部でインターリーブする事でバーストアクセス時の速度を改善したり、
クロックの両エッジで転送のタイミングを捉えて、データの転送を高速化したり、
プロセッサーとのインターフェースをシリアル化したりパケット化したり、超並列化する事で行われてる。

DRAMのレイテンシを短くする為には、DRAMセルの改良が必要だが、
これはDRAMセルからデータを読み出す部分に、
チャージされる電荷量や、センスアンプのスルーレートなどの物理的な、
制約があるので、今のところ大きく改善するような兆候は無い。

ポストDRAMは研究されているけど、DRAMの圧倒的な大容量と低価格に勝てないので、
今のところPC用のDRAMの代わりにはなれない。

つまりまだ当分は、この遅いDRAMとなんとか上手く付き合っていくしか無いって事。

この遅いDRAMでも十分なアプリはいいけど、
高速なDRAMが必要なソフトは厳しいだろうな。

ま〜大概はプログラミングで対処可能だけどね

サーバ・デスクトップ・モバイル・組み込み・スマートフォン・HPC
ハードウェア要件がいろいろならCPUもいろいろ、ソフトウェアの書かれ方もいろいろよ

DRAMのレイテンシはどうにもならんのは仕方がないから、
もっと帯域を増やしてほしいわ。
8chくらいになれば、嬉しんだけどな。

>>279
チャネル数を増やすと、データやアドレスラインが並列の場合、
CPUソケットのピン数が増えまくってしまい、
CPUパッケージのコストや、CPUソケットのコストが上がってしまう。
もちろん基板上の配線コストも高くなる。

通信をシリアル化すると、信号の周波数が上がってしまい、
通信を行うトランジスターの発熱量が増えてしまう。

メモリ速度が上がって高帯域になると、
スタブ配線での信号の反射が問題になるので、
1chに1モジュールしか接続できなくなる。

信号品質的には差動伝送が望ましいが、
差動伝送にするとピン数が倍になるのと、
1chに1モジュールしか接続できなくなる。

DRAMの高速化は難しい。

DDR系は限界をとっくに超えてる。

DDR2以降、レイテンシと消費電力が上がっていくばかり

>>280
まあ、現状のDIMM形式出やるなら、後半の部分の問題はあるわなあ。
XDR2あたり使えればDDR3とかのPHYまわりの問題は解決できるが、
コストとレイテンシはもっと増えるよなあ。
そろそろGPU並のメモリ帯域がほしい。

LGA6000とかきたら胸熱ｗ

#こないと思うけどｗ

TSVなんかで、DRAM載っけるしかあるまいて

インテルがTDPを下げてきてるのも
熱に弱いDRAMを載せる為の準備じゃないかと
妄想してる

シリコン貫通ビアでDRAM積層の願いは1980年代からある。

実現されるといいね。

すでに動く試作はインテル作ってなかったか？
多コアの奴でさ

DRAMだけのTSV積層ならもう製品化されてるし

昔からあるから〜的な否定的物言いはなんか、気分悪くなるわ
内容ないし

>>286
これでしょ?
http://www.brightsideofnews.com/news/2011/9/19/intel-micron-hybrid-memory-cube-the-future-of-exascale-computing.aspx
まずはHPC向けらしいけど「Haswellでは何か乗せてくるのでは?」なんて想像している人もいるね。

俺は全てSoC化されるのを望んでいるよ。否定的だなんてとんでもない。

最後の一文を否定的に感じてしまった
すまぬ


ダイ面積は余り気味なんだしチップセット機能も
どんどん取り込んで欲しい

Haswellは、性能++、統合+++、省電力++++らしい
Skaylakeだと、統合が++++くらいかも

>>281
レイテンシは実時間ベースだと伸びてない

延びてるのはレイテンシじゃなくて、ウェイトだね。
バスの速度が上がったのに、レイテンシが変わらないから、ウェイトが増える。

とってもご機嫌ななめだわ！

》249
atomよりアンローリングが効くっていったい。。。

>>281
RDRAM系はDDR系よりレイテンシが長い
レイテンシを短くしたいなら1T-SRAMかね

もし仮に、レイテンシ1で無尽蔵の容量のメインメモリがあったと過程すると、
それだけで今のプログラムは何倍くらい早くなりそうでしょうか？
メモリアクセスがネックであればあるほど効果が大きいと思いますが、
特に大きいアプリって何でしょう？
そしてそれはどれくらい改善されそうでしょうか？

実際にはありえなくても、理論限界は知りたいな、と。

2倍くらいか?

>>293
Atomは2パイプでA9は3パイプだからね。
レジスタ間オペレーションだけに限ればもともとA9のほうがクロックあたりの理論性能は高い。

x86の強みはメモリアドレッシングにこそあるわけで
ご丁寧にもAtomはL1キャッシュのレイテンシ分をパイプラインステージとして組み込んでて
L1キャッシュから読んで処理してもは同速となりうるわけだが、こーいうコード例では
addssにメモリロードを組み込んで命令数を減らすとかできない。
1.1の定数をレジスタ上に保持しなきゃいけないでしょ？
ロード＋乗算に分けるか、あるいは1.1の値をコピーしてからロード付乗算、
いずれにしても2命令になってしまうね。

3オペランドのAVXなら、vaddss dest, src1, [src2]みたいなこともできるが
22nmでアウトオブオーダ採用が確定してるし
インオーダのままAVXを採用するx86アーキを見ることはなさそうだ。

>>294
1T-SRAMって要はフルCMOSプロセス化したMDRAMだろ。
何か馬脚を現しそうな予感がするんだがｗ

>>295
実アプリケーションとなると、各アプリケーションでメモリアクセスの頻度がまちまちだし、
CPUの速度を律速しているのは、メモリだけじゃなく、I/Oにも待たされるし、
現状でもキャッシュの恩恵は受けているので、100倍とかにはならないとは思うけど、
じゃあ、どのくらい？って言われるとそれに答えるのはなかなか難しい。

ちなみに並列処理では、I/Oの他にThread間の同期処理にも待たされる。

CPUメーカーの技術者で、実際にどのようにメモリが使われているかを、
各種アプリケーションを分析して、
広範囲にプロファイリングしてる人なら答えを出せるかもしれない。

L1キャッシュの中に収まるような小さなコードを書いて、
その実行速度をプロファイラか何かで計ってみれば、
そこから想像を膨らませる事はできるかもね。

>>299
おお、詳細な回答ありがとうございます。

＞L1キャッシュの中に収まるような小さなコードを書いて、
＞その実行速度をプロファイラか何かで計ってみれば、
＞そこから想像を膨らませる事はできるかもね。
それイイですね！
すごくクリーンなプログラムですｗ

現実には分岐予測ミスによる性能低下も厳しい

>>295
rdpmcでMIPSを測ると
普通のアプリケーションでも1.0 x86ops/cycle位は出てるよ
よく最適化されたプログラムで2.0ちょい位

L1に入っても2か3位が限度だから
3倍より速くなるってことはないだろ

>>250
ROBなくてARMの仕様を満たすのはあり得なくないか？

http://www.arm.com/images/A9-Pipeline-hres.jpg
この図の"OoO write back stage"ってのが相当するものだと思うよ
write backする前に並び替えているはず

WBそのものは古典的なRISCにもあるステージだよ。
すくなくともブロック図には値（あるいは物理レジスタ番号）をRSから参照させるような
機構は書かれてないね。
トランジスタを食うし消費電力が大きくなるから採用を見送ったという話ではなかったかな？

一知半解の団子の面目躍如だな

ARMのスライドには
Leverages OoO without traditional power/resource hungry reoder buffers
とあるから少なくとも普通のROBはないのだろう

http://www.arm.com/files/downloads/cortex-a9_devcon-talk_introduction_final-02.pdf

> ROBなくてARMの仕様を満たすのはあり得なくないか？
何故こう思ったのか聞きたいな

PowerPCですら成し得なかったx86 CPU実機より速いPCエミュをARMに託しても大丈夫ですか｡

>>249
Android NDK r7でコンパイルしたら
impossible constraint in 'asm'
と出て動かなかったのだけど、どうすれば動く？Scorpionで試してみたい

A9なんてコア単体の速度で言ったら
Atomの毛をむしった程度のものだ。
あくまでPCの1/10、1/20の電力しか使えない理不尽な制約のある世界での「速い」なので
x86を性能で凌駕出来るとは思わない方がいい。

組み込みの10倍、20倍の電力を使えるx86の方が理不尽な世界なんだけどな。

組み込みで組み込みの設計が出来ればそれも理解できるかな

>>309
FPUオプション付けてないんでは？
手元では
arm-linux-androideabi-gcc -B $SYSROOT -c -O2 memdep.c -mfloat-abi=softfp -mfpu=vfp
でコンパイルしてる

>>306
ROBがないと先行して発行した命令がリタイアするまでは
後続命令をリタイアできなくてパイプラインストールするから性能上のメリット薄くないか？

特にレイテンシ差の大きいFPUだといまいちそうだけど

>>310
そう考えると、ネットブックよりサクサク感のあるiPadやAndroidタブはなんなんだと。
ＭＳが悪いのかね。

そういえば最近Android3.xのソース公開になったからネットブックにもAndroid入れられるんだっけか。

>>315
結局そういうユーザ体験が大事ってことだよね。

>>315
Windowsは高いハードを買わせるためのものですし。
安い・古いマシンで動くことなんて考慮してるわけがない。

iOSもMacOSとおなじ同じXNUカーネルを使ってるけど、MacOSそのものは使ってないでしょ？

>>315
だぶん今Windows95をAtomで動かしたらかなりのサクサク感になるだろうなあ。

無駄に滑らかにアニメーションしてサクサク動いてるように見せかけてるけど、
ブラウザ起動すると馬脚を現しませんか?

個人的にはアニメーションなんぞ全部切りたい。
無駄に使えるは電池ねえんだっつーの。

あ、確かに、アニメーション系全部切って同じ操作したときの電力改善がどれほどかは気になるね。

>>315
Windows Phone 7.5やWindows 8 for ARMにご期待ください。

Window生成やGUI描画にGPUを使わない「遅いアプリ」は強制的に退場させられるので
ARM上でも快適な動作をするWindowsが出来上がりそうです。

Atom上で動作するWindows 8は今までのGDIをサポートするからそれだけ性能があるという判断なんだろうね。
ARM版と同じようにMetro UIとWinRT用アプリに限定すればより快適に動作するみたいだよ。

>>320-321
CPUがメインのAndroidはまだしもGPUメインのiPhoneやWP7は大して消費電力は減らないと思うぞ。

特に全てをDirect3Dで描画しているWP7なんて回転も拡大も移動も
UIの頂点（ポリゴン）を指定してやれば後はGPUが勝手にアニメーションしてくれる。

たぶんオフに出来たとしても10分程度延びればいい方じゃないかな？
それならレスポンスタイムを減らすためにアニメーションしてくれた方がいい。

>>323
それくらいだったらアニメありのほうがイイに賛成！
心理的な気持ちよさや分かりやすさに繋がるからね。

GPU描画をハードウェアスプライトか何かと混同していないか?

>>313
ありがとう。NDKはFPUなしを前提にすることを忘れていた。armeabi-v7aで解決。
_android_log_printするようにして測った。そしたら、測る度に5cyc程度ズレる。酷いとnoschedが45cycになったり。
なのでブレが小さい結果の中で最も速かったものを選んでみた。参考値ということで。
投稿制限の関係でcycのみ。
Qualcomm MSM8255 (Scorpion)
// 1024
nosched 11.81[cyc/data]

sched 4.25[cyc/data]

read only 11.53[cyc/data]

read only sched 5.05[cyc/data]

nosched-hazard 33.61[cyc/data]

sched-hazard 10.99[cyc/data]
// 16384
nosched 13.25[cyc/data]
sched 4.55[cyc/data]
read only 10.99[cyc/data]
read only sched 5.04[cyc/data]

nosched-hazard 21.38[cyc/data]
sched-hazard 9.58[cyc/data]

>>325
実際、各UI要素はテクスチャとしてGPU内に描画されますよ。

それでタイルなどのタップしたときに浮いている板を押したようなアニメーションや
画面遷移時のページをめくるような動作をポリゴンの回転で表現していますし。

命令レベルの最適化が必要なプログラマってどれくらいいるの？

>>314
出力依存消せば、リオーダーされるとかじゃないの？
>>249 をちょっと修正した、
https://gist.github.com/1513601
これの、func_read_only_no_output_depと、func_read_only_output_dep比べると
- 出力依存無し : 7.0[cyc/data]
- 出力依存有り : 9.0[cyc/data]
こんな感じで、出力依存無いほうがちょっと速い。
まあ、メリット薄い気がするのは同意だが…つかA9のOoOが有効な場面て殆ど無いんでは？という気が。

>>258
メモリーがオンチップでもオフチップでも配線遅延がアクセス速度を律速するわけではない。オンチップにすると配線本数を桁違いに多くできるけど、レイテンシは変わらない。
DDR3-1600でカラムアドレス出てから9とか10クロックも掛かるDRAMの構造を根本から変えないと解決しないので、SRAM使ったら、と思うわけ。

>>327
アニメーションを描画するために
ポリゴン座標をちょっと移動・回転させ、テクスチャを貼り付け、二次元のフレームバッファに書き込む、という演算を
1/60秒毎にCPU/GPUが行っている。
アニメーションがなければ、一回フレームバッファに書いてしまえば、後は次のユーザ操作まで
CPU/GPUはまるまる休んでいられるところである。

,,　・´　∀　｀・　,,）っ-○○○ はホームページ持ってないの？
主張とか技術的な書き込みをまとめてくれよ。

http://vr-zone.com/articles/chinese-high-end-cpus-are-now-in-the-game--details--part-2-alpha/14347.html

ていうか団子はまずトリップ付けろや

>>329
Scorpionで最新版をやってみた。結果は1cyc弱。それなりに効いているっぽい。
// 16384
read only no oputput dep 14.44cyc
read only output dep 15.27cyc

>>332
誰かサーバスペース貸してよ

>>334
キーを平文でpostする時点でトリップなんざ論外
実質個人証明としての機能は何も持ってないのと同じ

その割にはつまんね〜機能をやたら高性能に作って遊んでたじゃね〜かw

>>332
>主張とか技術的な書き込みをまとめて
無理だろう。良くも悪くもプログラマーに「しか」なれなかった人だから。

駐車場の警備のバイトもやったよｗｗｗｗ

そのくらいの覚悟もないと独立なんてできないよ

団子さん、独立してるのか！
自信と覚悟がないとできないことだね。
ここで有益な情報も出してくれるし、尊敬する！

デタラメばっかりだけどな

まあ、元の能力があっても国家プロジェクトの予算にたかってるだけの
自覚症状のない生活保護研究者たちにくらべたら遥かにマシだわな > 独立

他人の嫉妬ってどうしてこんなに心地いいんだろう

ぶっちゃけ半端な覚悟じゃ今の時期は食いっぱぐれる。
会長に拾ってもらって今に至る。

超絶馬鹿アンロールの発狂具合が心地よすｗｗｗ

Xilinx、SSIを利用したVirtex-7 2000Tの出荷開始を発表
http://news.mynavi.jp/news/2011/10/26/012/index.html

TSVが出るまではこれ使ってCPUとDRAMを繋いでみてはどうか?

このシリコンインターポーザはTSVを使っているよ
でないと表と裏にパッドを作れないでしょ

インターポーザ遅延が1nsでしょ
クロック分配の資料は出たっけ?
Tデバイスは避けたいなぁ

http://news.mynavi.jp/articles/2010/10/27/xilinx_ssi/index.html
200Mbps 11000本で0.5Wってのは魅力だな

インターポーザは複数ダイを平面上に並べたその底に敷くってことは
かなりデカいシリコンになりそうだけど
2世代落ちの枯れたプロセスとはいえコスト的にはどうなの？

多積層のTSVより熱密度は有利そうだけど最終的にコストは増えそうだよね

メタル層だけだからそこまで高くないんじゃないの？

>>349
Microbumpって言えばPSPでｅDRAMの代替に使ってたけど
ソニーが世界に先駆けて、みたいな発表で唐突感もあったけど
この記事読むとImage Sensor製造技術の応用とあるから
センサー屋のソニーが初になったのはある意味当然だったのね

http://techon.nikkeibp.co.jp/article/NEWS/20111220/202822/?ST=lsi
>　なお、2011年12月に開かれた「Semicon Japan 2011」の技術セミナーでは、
> フランスYole Developpement社がXilinx社のSiインターポーザに関し、コスト
> 推定の結果を示した。それによると、40mm×40mmのSiインターポーザ1枚
> 当たりの製造コストは、約32米ドルと推定されるという。

>>353
そこそこコストは掛かりそうだね
シリコンの原価はメインダイの１、２割って感じで
実装工程に加わる分含めてトータル３、４割増とかそんな感じなのかな

さすがに　TSMCも40nmはいい値段するんだなあ
牧野さんのGRAPE-DR関連の日記は読んでて面白かった。

団子さん、あけおめ。
団子さんのホムペ教えて。

AMDは知らんが今のCPUは比較＋条件分岐のところにintよりunsigned intを使ったほうが速いんだな
こんだけ詰め込んでもEX-ORゲート使いたくないんだろうか

> AMDは知らんが今のCPUは比較＋条件分岐のところにintよりunsigned intを使ったほうが速いんだな
どんなコードをどんなCPUで試したの？
単純な大小比較＋分岐ならどんな条件でも2命令（Macro Ops Fusion次第で1オペレーション）で処理できるはずだけど。

>>356
個人ページなら破棄したから誰か作ってｗ

Core2までだとsignedな大小比較はmacro-fusionが効かないから、というのはあるかもね

条件フラグを2ビットみないといけないからか。なるほどね。

それぐらいでfusion出来なくなる男の人って……

まあCore2 MAは64bitなだけでも出来なくなるから、macro fusionはおまけか。

フラグが直前の命令に依存するのでオペランドをチェックする必要がないから
プリデコード段階でfusionして構わないというのがミソなわけだよね

だからcmp+jcc系以外にもcmp+cmov/setccはfusion出来そうだね
add/sub/inc/dec+jccはどうだろう
PCとレジスタで別のライトバックパスを持ってたら1uOPでできそうなものだけど

> add/sub/inc/dec+jccはどうだろう
Sandy Bridgeからできるようになったね。
あとand/or/xorとか、Port5で発行できてフラグを更新する命令は大体対応みたいな感じ。
ライトバックパスが大幅に強化されたんだろうね。

SandyBridgeすごいな
ループの dec+jz も1uOPでできるということか
最近のコンパイラが吐いてるのは見ないが

Sandyさんは要る子。

条件ジャンプの前にLEAを埋めこんだオレバカス

他のスレに書き込んだのですが回答がないので、

SandayBridgeのL3キャッシュについて３点質問です。
１．L3キャッシュはリングバスでつながっているそうですが、このリングバスとは、トークンを使ったバスのことでしょうか？
２．L3キャッシュは各コアごとのL3キャッシュ2Mb〜4Mbをリングバスでつないでいますが、
　　各コアごとのL3キャッシュと他のコアのL3キャッシュではアクセス速度は同じでしょうか？
３．２．でアクセス速度が同一コア上と他のコアで異なるならば、SandayBridgeのキャッシュの構成は、
　L1,L2,同一コアのL3、他のコアのL3キャッシュ、の事実上４段キャッシュになると考えて様でしょうか？

http://pc.watch.impress.co.jp/docs/column/kaigai/20100924_395972.html

なぜTokenRingにトークンが必要かというと
バスを流れるパケットが可変長で、新しいパケットを流せるタイミングがトークンなしではわからないからで、
CPU内部のリングバスは1サイクルに1パケットの固定長だから、トークンは必要ない。
前サイクルに回送すべきデータが届いていなければ、今サイクルで新しいパケットを流すことができる。

SandyBridgeのLLは単純にウェイ単位で各コアに割り当てられてるから
ウェイごとにレイテンシは異なるけどキャッシュ階層としては1段
局所性は利用されていない

>>370
本当に?
局所性を利用しないのも、コア数でway数変わっちゃうのもおかしくない?

http://news.mynavi.jp/articles/2011/08/25/hot_chips23_intel/index.html
HotChips23のIntelの発表の解説
>LLCは物理的には各コアとペアになっているが論理的には一体のキャッシュとなっており、
>各コアがアクセスしたメモリデータはアドレスに従って4つのLLCに振り分けられ、自分のペアとなっているLLCだけに入るわけではない。
ウェイ単位ってのは嘘だったごめん
でも局所性は使ってないぽいよ
振り分けにはなんらかのハッシュをつかってるのかな

興味深い
局所性を利用しないのはアクセスが集中しないようにかな
アドレスで単純に振り分けてるなら、6コア品でもLLCは8コア全部使ってるのかなあ

>>362
>>363
間接分岐のためにデータパスからフロントエンドへのパスはあるが、
条件分岐ではそんなものは使わない
分岐先アドレスの計算もフロントエンドで行う

なるほど分岐先アドレスはフロントエンドで決定できるね

分岐ミスが確定したのなら、分岐命令まで状態を巻き戻さねばならない
これは例外と同じメカニズム

例外って分岐ミス程度のコストと考えると意外に安い？

>>363
javascriptのV8 JITとかは
intの演算に全部joがおまけでついてくるからfusionは旨いのかな
まぁintの演算ボトルネックなjsのコードはありえなそうだけど

>>377
特権レベルが切り替わったりするので軽くはない

HT/CT/LT/VT−4つのテクノロジを拡張できるNetBurstの秘密
http://pc.watch.impress.co.jp/docs/2004/0309/kaigai071.htm

MicroCodeで拡張性と柔軟性を得たのは分かるんですが、
その場合、デコードに手間がかかる（レイテンシが多くなる）というデメリットがありますよね？
パイプラインを深くして配線のクリティカルパスを短くし、高周波にすることと共に、
ますますサイクル数がかかってしまうわけです。

ネトバは、それに対し、分岐予測精度を上げてパイプラインストールを現象させたり、
SMTによってレイテンシを隠蔽するというアプローチを取ることで欠点を補おうとしたと。

そしてリーク電流の増大によってパフォーマンスは頭打ちになって幕を閉じたと。

こういう認識であってますか？？

トレースキャッシュでデコードそのものをパイプラインから分離した、だろ

シンプルにin orderにしていればもっとクロック上げられたと思う。

なるほど〜。

これが真のNetBurstアーキテクチャだ
http://pc.watch.impress.co.jp/docs/2004/0310/kaigai072.htm

次の日のコラムにも説明がありました。

＞最後に、このレポートと前回のレポートで説明している内容を、最初に洞察した人物は塩田紳二氏だ。
＞彼はIA-32e発表の直前から「機能の多くをMicrocodeとして実装し、マイクロアーキテクチャを仮想化することで
＞拡張性を実現しているから、柔軟なアーキテクチャ拡張ができるのでは。カギとなるのはデコーダだ」と推察していた。
＞その推論を、Gelsinger氏にぶつけた結果、まさにその通りの答えが出てきたわけだ。
＞オリジナルの洞察は彼のものだ。

塩田さんって人、すごいですね。

プレスコはあのような設計ながら 大きく性能を落とさなかったのが奇跡だ｡

まあ、プレスコは過小評価されてるとは思うけどね。
バックアッププランを用意していたインテル偉いとしか言いようがない。

ネトバ自体がItaniumのバックアップだった訳だが、
イスラエルチームがとんでもなく優秀なのに救われたね。
あとインテルの90nmは酷すぎた。半導体産業はこれで頭打ちかと思ったくらい。
AMDの90nmもさぞかしと思ったら、低発熱で拍子抜けした。

イスラエルチームは神。

自作PC板でもイスラエルチームか否かでスレを立て分けるべき

イスラエルチームなんてオレゴンチームが造ったものを改良してるだけじゃん。

>>387
同じ90nでPenM作ってたんだけど？

>>390
その改良ってのが改良の域を超えて
半端無い程、徹底してるから神って言われるんだと思われ

神ならなんでTimnaはキャンセルされたんだっての。

Timna内蔵のメモコンがRIMM対応だったから。
MTHくっつけてSDRAM仕様にしたらチップ数増えて、
i810+Celeronに比べてコスト的メリットもそんなに無い上に
新たにバリデーションの手間が増える

DRDRAMが（技術的にでは無く市場的に）ダメダメになるのが読めなかった
事はハイファチームの責任じゃないだろ＞Timna

その程度なのに神とか呼ぶから違和感があるんだろ…

>>387
あの頃のAMDは良かったな。
今じゃインテルみたいに上手く方針転換しないとCPUは本当にやばそう

あまり、イスラエルかオレゴンかで気にしても仕方ない気がするけど。
オレゴンチーム率いていたゲルシンガーがintel辞めてから、
intelでx86CPUのアーキを決定するトップはイスラエルチームのトップになってるんだし。

>>396
Timnaは128KBのL2含むCeleronとi810相当の機能を統合しているにも関わらず、
河童Pentium!!!と共通ダイの河童Celeronと比較してダイサイズはほぼ同じと言われている。
(チップセットはCPUより古いプロセスで製造されているので、当時最新のCPUと同じプロセスで製造すれば小型化可能、
プラス、Pentium!!!の機能制限版のCeleronは一部無効にされているL2を含んだダイサイズなので驚異と言う程ではない)
んで、Timnaの経験を生かしてBanias(初期のPentiumM/CeleronM)を設計したらしい。
ハイファチームはこのように元々モバイルや小型省電力なチップの設計を担当しているのでそういう方面の改良が得意。
ネトバショックを引き摺っている人にとっては正に神に見えるんだろう。

Timna出て欲しかったなPS2のおかげでRDRAMは後に激安品になってコスト問題も
解決したのに。

インテルはチップセットとドライバを何とかしる！！

CPUもGPUもメモリ空間統一すりゃぁ、転送のコスト0でｳﾏｰじゃん。
AMDのFusion構想ﾏﾝｾｰ。


って思ってたんだけど、
よく考えたら、メモリ空間別なほうが、プロセッサ間のスヌープなくせるし、
そういうややこしい制御にトランジスタ割かず、転送は必要になるけど、シンプルな構造にしておいて、
転送のオーバーヘッドは膨大なスレッドで隠蔽するって方針のほうが合理的だったりする可能性が気になってきた。

みんなはどう思う？

メモリ空間が共通という話と
メモリコントローラを共有しているという話と
キャッシュのコヒーレンシの有無の話は
全部別

GDDRが使えないならGPUで計算させる意味なくね？

Intelが次世代デスクトップCPU「Tejas」をキャンセル
http://pc.watch.impress.co.jp/docs/2004/0509/kaigai088.htm

これほどまでに大きな転換を行ったことってなくない？？
時代が変わったと感じる出来事だね。

＞そして、おそらくNetBurst(Pentium 4系)アーキテクチャは、そうしたチャレンジの中で、消える運命にある。
なんか泣けてきた ；_；

しかたないね、物理法則に勝てる人間がいるとしたら実際神だからね

>399
こういうレベルなら神でいいと思うねw

>>404
メモリ律速なアプリケーションじゃなければ意味はある
APUやQPI接続のKnightsほどCPUと近ければデータ転送のコストが高いディスクリートGPUより有利な場面もある

GPGPUのCPUに対する利点ってbandwidth/FLOPSなんだがな

>>408
単精度

SandyBridge 2600K DDR3 1333
21.2[GB/s] / 217[GFLOPS] = 0.097[B/FLOPS]

Radeon HD7970
264[GB/s]/3790[GFLOPS] = 0.070[B/FLOPS]

Radeonがベンチ番長で実際のHPCに使われない証左ですな

Tesla C2070は単精度1030GFlopsで144GB/s、B/Flopsは約0.14とその辺のx86やGPUよりは良好なのだろうが、
さりとてこれで十分かと言えばそんなことはないわけで、昔のベクトル機のごとく2B/Flopsとまではいかないまでも0.5ぐらいは欲しいところ。
現状のTeslaとかの値段でそれを実現するのはTSVが来ないと困難だろうけど。

実際上、メモリバンド幅ネックのアプリで重要なのは
絶対バンド幅もしくはバンド幅あたりの電力、コスト。
B/FはFを下げれば好きなだけ上がる。

来る来る言ってなかなか来ない狼少年の一角TSVがとうとう来そうなんだが
既存のアーキテクチャの延長という枠では収まらないので
設計から製造まで含めてどこをどう割り切るかで性能に劇的な違いが生じる気がするぞ

単純なフィルター処理でも一個のデータで何十回も積和計算するから
キャッシュが効いてりゃ0.1で充分でないのか

数GBのデータにFFTをかける仕事でもしてるんじゃないか？

キャッシュが効く、という仮定が成立しない局面もある

【フリーメーソン】ユダヤの陰謀【イルミナティ】13
http://toro.2ch.net/test/read.cgi/occult/1323947324/
　ユダヤが解ると、アメリカ経済が見えてくる　
http://kohada.2ch.net/test/read.cgi/eco/1213792124/

なぜRambus方式のDRAMが主流にならないのでしょうか？
どう見てもDDR系より帯域広くできますよね？？

優れている物が主流になるわけではない。
RIMMはバカ高かったから市場から消えたんだよ。

あれって談合で吊り上げたんですよね？
馬鹿馬鹿しいです。
コンピューティングの進化を妨げる由々しき行為です。

出て欲しかったキャンセルされたCPUがTimnaとTejas
出てたらどうなったかな？
Timnaが出たらRIMMもPC市場でもう少し長生きできただろうに。

それからItaniumがKittsonで終わらないかどうどうか不安である

>>421
DRDRAMが安価で普及する見込みが立たなかったためにTimnaはキャンセルされた
わけだから、鶏と卵だな。

1970年ころから続いてきた、プロセッサの高集積・高クロック・高消費電力の進化が、
Pentium4で高クロック・高消費電力の進化が止まってしまったのが残念だな

たかだか100W程度で文句言うやつの責任だな
これくらいの消費電力で文句言うやつがいなけりゃ、いまごろデスクトップCPUは、
クロック10GHz・消費電力1kwで超高速の方向に進化してた

CPUが溶けそうだなそれ

問題は消費電力じゃなくて、高クロック版のPenDが空冷では放熱が間に合わず自動クロックダウン状態だった方。
空冷の限界≒個人向けCPUの限界

CPUが溶けて、マザボが焦げて、電源が爆発しそう

今はヒートパイプが安く普及してるから空冷でももっと行けそうだけどね
10年くらい前と比べると発熱密度で一桁くらいは緩和されている

水冷はメンテナンスがめんどくさいからな。

爆熱ネトバのお陰で冷却系が飛躍的に進化して、TDPの下がった現代のCPUでは
さほど苦労せずに静音と冷却が両立できたり、また300W超のGPUも利用可能に
なったりしたわけだから塞翁が馬だな。

>>423
上でも書いてあるけどPS2の爆発的な普及で量産効果が働きRDRAMは馬鹿みたいに
コストダウンした上に利益があったのでラムバス的にはおいしかった様子。
でもPS2が本格的に普及しだしてRIMMのコストが下がりだしたのはTimnaがキャンセル
された直後だったのは皮肉。
インテルがPCとかサーバーしかみておらずゲーム機市場を軽視していたから読み違えた。
初代X-BOXだってCPUはインテルだったのに理解不足でX-BOX720では逃げられたし。

>>420
基板の製造コストも高いみたい。

>>428
かつて爆熱呼ばわりされたK6ファミリ(特にK6-IIIなど）でさえ、
いまのノート用省電力CPU程度の電気で動いてたってのがな。

優れた物が主流になるのなら，今頃世界はPOWER一色だった｡

>>409
キャッシュの少ないGPUでこれは致命的

>>433
優れれてクライアントサイドの高パフォーマンスコアではPPC970みたいなのが精一杯なら
ARMなんて論外だろうなぁ

>>431
Rambusはまだ特許ゴロ商売に慣れてなかったからライセンス料をふっかけ過ぎたんだろ。
あと必ず２枚ひと組で増設しなければならなかったのも面倒だった。
空きスロットにはダミー基盤をつけなければいけなかったし。

>>436
あの基板はdummyじゃない。
終端のために使っていた。
今はODTがあるから必要なくなった。

しかし今のメモリ価格を考えると、XDRなんて使えんわな〜。

2倍の価格で2倍速ければ需要はあるだろう

RAMBUSは商売の基本である独占したら値上げを守らず、
独占してないのにもかかわらずライセンス料ふっかけたからな

独占したのはインテルのマザーボードのメモリ規格のみで、インテル以外がついていかなかったから

ハイエンドデスクトップ限定で良いからXDR使わせてくれよ〜
インテルさん、DDR4の後どうするんだよ
今の技術の延長でDDR5なんて可能なのか？

HMCみたいなのが来るからメインメモリなんてどうでも良くなる
それがあるからメインメモリの進化にどこも力を入れていない

メモリセルにDRAM使ってる限りXDRもDDRも大して変わんないって。

>>438
用途しだいだろう。
メモリ速度が二倍になっても動作速度は2％も上がらんしなあ。

メモリ速度を二倍にするよりメモリ容量を二倍にする方が、PCの動作環境が向上するんだから。

過去のRIMM全盛期みたいに、速度二倍で価格五倍とかよりはマシだろうし、
いまのメモリ価格での二倍価格程度なら誤差みたいなもんだから、需要は作れるんだろうけど。

>>436
二枚一組は、CPUバスよりメモリの方が低速だったからデュアルチャンネルアクセスにしようとして設計したせいだろ。
Pen4の時のは。

Pen3（i820ﾁﾌﾟｾﾄ）のときのRIMMはどうたっだっけ? 忘れた。

ま、30pinSIMM時代末期みたいな、4枚一組での増設に比べたらマシだ。

SRAMをメインメモリにしたいなぁ。
500MBくらいあれば大概のことはできるっしょ。

100万円くらい出せばいけるかな？
これで10年はいけるし、10万円/年なら安いもんだ。

メモリが早くなっても性能伸びないのは周波数が早くなってもDRAMのメモリセル自体の動作速度がほとんど変わってないから
周波数に合わせてレイテンシも伸びてるからだ
SRAMといわずともMRAMとか低レイテンシ化出来るメモリセルになれば高速メモリにも意味はあるよ

MRAMは速いんか！？
そら楽しみだ。

>>437
違うよ。
DirectRambusはデイジーチェーン接続だからマザーボード上の終端まで信号線をつなげる必要があったから、continuity module(CRIMM)ってのが必要だったのさ。
28Ωって変態的なインピーダンスを要求されたけどマザーボードのコストは並だった。
それよりライセンス料のおかげでDRAM の値段が下がらないのがネックだった。
モジュールを追加、交換して容量を変えるような用途には構造的に不向きだし。

>>442
DDR3になってもSDRAMの頃と中の人のクロックは同じで
バンクが増えただけだしな
古いPCに増設させないためにちまちま規格を変えてんじゃねぇのか

中の人は200MHzくらいで息切れ･･･

>>448
いやクロックは普通に上がってるから
レイテンシが変わってないだけ

>>450
SDR→DDR→DDR2→DDR3で各々プリフェッチを倍にしてるからスループットも
倍々で増えてるけど、メモリセルそのものの速度はPC3200もPC2-6400も
PC3-12800も全部一緒。
なのでプリフェッチが有効なシーケンシャルアクセスではスループット向上の
恩恵が受けられるがランダムアクセスだと一向に向上しないレイテンシの悪さが
馬脚を現す

http://techon.nikkeibp.co.jp/article/NEWS/20111220/202842/

やっぱりSTT-MRAMが本命なんかな
これ以上DRAMの微細化を進めていくと
電荷の保持ができなくなるとかいわれてたし
10年後にはSTT-MRAMが取って代わるのかな

>>452
DRAMの電荷保持はすでに限界だけどね。
レーストラックメモリは容量密度が高いみたいだけどどうなるのかね。

>>444
たとえメインメモリがSRAMでも、汎用インタフェースを使う限り早くならないだろ
オンダイのSRAMが早いのは専用の高速接続を使ってるからっていうのもある

そのうちアクセスする前にデータが出てくるタキオンメモリができるさ

レイテンシの弊害を考えると、個人用PCのメモリはDDR2で十分だと思うんだよね。
シングルスレッドの性能はもう上がらないんだし。
オンボで4kやるとDDR3が必要なのかな。

>>454
そっかぁ･･･。
TSVでもダメかな？

>>456
レイテンシはDDR2もDDR3も変わらないけど？
もしDDR2で帯域が十分だというならDDR3で低電圧化してビット幅を減らした方が
電力も実装面積もコストも減らせる

DangoBurst
DangoWood
DangoField
DangoBridge

DangoQuest

DgonQuest

DagonQuest

>>448-449
いや、SDR-SDRAMのころは66MHzスタートで、133MHzで打ち止めだったじゃん
それより早いヤツは、PCでは普及しなかった。

DDR-SDRAMのときは、133MHｚぐらいからスタートだっけ?
最後、200MHz（DDR400）まで、時間はかかったが普及した。

現行DDR3は、133（DDR3-1066）でスタートし、
いまは166（DDR3-1333）から200（DDR3-1600)への以降が進行中で、
233（DDR3-1866）やら266（DDR3-2133)への移行が進みそうな気配もある。

転送レート向上速度より大幅に遅いとは言え、コアクロックも上がってはいるだろ。
まあ、4倍まであげるのに15〜20年ぐらいかかってる気がするが。

レイテンシの短縮速度は、もっと遅いんだっけ。

ベースクロック133MHz以上は何かと物理的に難しいんじゃなかった?
今時は100MHzに抑えてるくらいだし
消費電力からの要請かね?、知らんけど

世代を追う毎に次世代規格の立ち上げが困難になって来てるんで、それまでの
繋ぎとして（特に生産立ち上げ時の）スピードイールドが悪化するからメモリ
メーカーとしては本音ではできるだけやりたくないベースクロックupを強い
られてるってのが実情だがなｗ
ttp://pc.watch.impress.co.jp/img/pcw/docs/486/032/html/01.jpg.html

DRAMにもキャッシュメモリ積もうぜ

CPUから遠い位置のキャッシュって効果あるのか？

VC-SDRAMはそれなりに効果があった

>>463
何をどう勘違いしているのか知らないけど、DDR3-1066は533MHzだし、DDR3-1600は800MHzだよ?

えっ
メモリセルのクロックの話ならDDR3-1066は133MHzのプリフェッチ8であってるはずだが

ランダムアクセス性能なら16MHz相当なのにﾑﾁｬしやがって

だからそれは1bitのアクセスに対して8bitを一度に読み出して(プリフェッチ)
内部インターリーブで8倍のクロックで1bitずつ転送する結果であって、メモリ
セル自体の速度はその1/8(ダブルエッジ・クロックなので表記としては1/4)
なんだってば。

実際レイテンシの激増でどんくらいロスって発生してるもんなんだろ、今時のL2L3キャッシュ山盛りCPUで

>>466
任天堂が使ってる1T-SRAMってそんな感じのメモリーじゃなかったっけ？

いまのDDR3ってレイテンシは50nsくらいだったと思うから、イニシャルアクセスに170cpuサイクルくらいかかる。
LLCは60サイクルくらいだから、CPUのクロックあげないとLLCの効果は薄いよな。

>>475
そんなもんだっけ？と思ってsamsungのDDR3-1600見たら
CL=11 tRCD=11となってるから27.5nsじゃないのかい？
DDR2-800がCL=6 tRCD=6とCL=5 tRCD=5の2種類だから
レイテンシはほぼ変わってないな

DDR3-1600でCL11はかなり遅い部類じゃねーか？

>>472
メモリーセルの話ならクロックでなくアクセス速度で話をしないと。SDRAMであってもクロック同期なのはI/Oとかのロジックだけで、セルは非同期だからね。

マザーボード上のL2キャッシュをサードキャッシュとして利用したK6-IIIマシン思い出した｡
Slotを復活させて4GB SRAM L4キャッシュでも積むかい？
階層深過ぎて性能でないのがオチだけどw

>>479
SRAMを4GBも使えるなら、わざわざキャシュにせずにメインメモリで使うでしょ。

>>479
その時代なら今のSSDがメインメモリでもいけそうだな。

メインメモリは256GBあるんだろう

>>481
フラッシュメモリーってDRAMの100万倍遅いぞ

NOR型フラッシュはメインメモリに直接マッピングできるくらい早い

でっていう

スパンションはNOR型でも首位から転落か

“Many-Core CPU”へと向かうIntel
〜CTO Gelsinger氏インタビュー(1)
http://pc.watch.impress.co.jp/docs/2004/1112/kaigai133.htm

【Gelsinger】 その通りだ。我々が今研究しているのは、多くのコアを使う並列化マシンだ。
Intelはデュアルコアとマルチコアをアナウンスしたが、私が携わっているのは
もっとCPUコアの数が多い“メニイコア(Many-Core)”だ(笑)。


当時は「メニーコア（ﾜﾗ」だったのかｗ

オク出品の50万円のSX-8誰も落札せずに終了。
50万でベクトル機が入手できるチャンスだったのに。

コンパイラもないのにどうするんだよ

そもそも、動くかどうかすらわからないしソフトウェア無い時点で使い物にならないでしょ？
一般家庭で使うには電源工事がいるから敷居が高いし

所詮古いスパコンなんてオブジェ以上にはならんだろうな

SX-8 8年前だがメモリ帯域だけは今のPCより速い
1ch 64GB/秒

SXをはじめとするベクトル型は、メモリ帯域が広いことで有名だからな
メモリ帯域が重要な計算は、TOP500でナンバーワンのKより現地球シミュレータのほうが速かったりする

京はGlobal FFTでも一位だよ
ESが二位

しかも京の2/9しか使ってないのにES2の3倍の速度出てるしね

スパコンってOSがUNIXベースだから、UNIXの知識ないと使えんだろ。

ところでDRAMの話が上がっているけどDDR5って将来的に可能なの？
どうもDDR4の延長では無理だって上で書いてあるんだけど・・・・

>>497
TSVやインターポーザーが来るので
ソケット介したメモリなどどうでも良くなる
あとは容量稼ぎの役目しか無い

番組の途中ですがアフィサイトへの転載は禁止です 2012/01/17(火) 01:28:32.24 ID:tepO+ZU0
何個会ってもかわらねえよ
http://sakuraweb.homeip.net/uploader/src/up171516.jpg
http://sakuraweb.homeip.net/uploader/src/up171517.gif

>>496
システム管理する人と、アプリを作って動かす人がいて、
後者ならべつにUNIXなんてごく基本的な知識があればいいだけだよ

>>498
それで解決するのは、せいぜいモバイルや一般個人向けのデスクトップPCくらいなもんだろ

ハイエンドデスクトップやサーバ、HPCじゃ大量のメモリが必要なので、
何らかの汎用インタフェースは必要

たとえば個人向けのハイスペックPCは、TSVでCPUに1Gの大容量メモリキャッシュ＋DRAMで16Gとか

>>501
トランスピュータ方式で、メモリ量が必要なら(メモリ混載した)プロセッサの
数を増やすｗ

こいつの出番か
http://hothardware.com/News/CPU-Startup-Combines-CPUDRAMAnd-A-Whole-Bunch-Of-Crazy/

4096bitバスｗ

>>500
>アプリを作って動かす人がいて、
>後者ならべつにUNIXなんてごく基本的な知識があればいいだけだよ

基本知識ならまだしも、アプリ作って動かすってかなり難しいと思うんだが。

>>501
だからその状況だと最後のメモリは容量のみ必要で
レイテンシも帯域もどう変わろうが性能に殆んど影響ないの
だからどこも力を入れてないのがその証拠

容量こそが必要な部分のメモリの速度を上げる必要は無いわけね

IBM creates 9nm carbon nanotube transistor that outperforms silicon
http://www.extremetech.com/computing/115657-ibm-creates-9nm-carbon-nanotube-transistor-outperforms-silicon

うお

4096 ウェイインターリーブってマジですか
SRAMじゃダメなんですか

数十億トランジスタの複雑なパターンを印刷方式で製造できるのがシリコンの強み

DDR5SD-RAM（6400Mhz）まだ〜？

まだ

整数演算性能のよさ，みたいなものを体感する，
方法って，あ・るのー？

たとえば浮動小数点がどうとかほざいてたPS3でLinuxを動かしてみる（ただしファーム更新前）
まだAtomなんかのほうがよっぽど速く、日ごろ整数演算性能の恩恵にあずかってたことがよくわかる。

団子ちゃん、久々

x86の汎用レジスタ8つとか少なすぎ！
x64で16個に増えたけど、何で最初からそれくらい用意しとかないかなぁ。
腹立つ。

8bitの8080の頃からの名残
AXレジスタ←Aレジスタ
BXレジスタ←Hレジスタ、Lレジスタ
CXレジスタ←Bレジスタ、Cレジスタ
DXレジスタ←Dレジスタ、Eレジスタ
SPレジスタ←SPレジスタ
これに
SIレジスタ、DIレジスタ、BPレジスタを追加したのが8086
8086は8080の命令を一対一で8086の命令に変換できた

これを32bit化したのがIA-32
EAX←AX
EBX←BX
ECX←CX
EDX←DX
ESI←SI
EDI←DI
EBP←BP
ESP←SP

8086〜80286(緑部分)と80386(緑＋白)のレジスタセット
ttp://www5c.biglobe.ne.jp/~ecb/assembler/gif/1_1_1.gif
8080のｒｙ
ttp://www.onlyme.sakura.ne.jp/zu3_3.jpg

8080の盲腸由来ってのもあるが、x86(特に16bitコード)は同時期の他の
CISCに比べてもレジスタ指定フィールドのビット数を少なくして命令
語長を短くする事を重視したISAだったからな。

むしろなんでx64でも16個なんだろう
IA64みたいに128個用意しろとはいわないが、
mipsとかpowerみたいに32個でも良かったんじゃないのだろうか

8080トランジスター数6000個
Z80 トランジスター数8200個
8086トランジスタ数2万9000個
68000トランジスタ数6万8000個
32bitレジスタを16本持ってた68000はトランジスタ数でもダントツ
8bitや16bitCPUの時代はたくさんのトランジスタを集積できなかったし
トランジスタ数が価格に直結してた
32個のトランジスタが当たり前のRISC系CPUの時代は
トランジスタ数が数十万個が普通だった時期

参考
386 27万5000個
486 120万個
R3000 11万5000個
R4000 120万個

>>520
8086は1バイトのオペコードの命令が多数あるな
68000は基本的にオペコードは16bit(2バイト)だった

>>521
限られたオペコード空間でREXを1バイトにするためには16本が限度じゃない？
今時のx86CPUで論理レジスタを32本に増やしたところで性能上のメリットもほとんどないし妥当だろう
IA64はVLIWの静的スケジューリングを前提にしていたからレジスタ本数を増やす必要があった

>>522
386が1.5~1um
486が1~0.6um
1世代しかプロセスがシュリンクしてないのにトランジスタ数増えすぎ
凄い時代だな

486のトランジスタ数の1/3は(386には無かった)キャッシュだからな。
それを除いても386の倍以上になったのはマイクロコード主体から
ワイヤードロジック化を推し進めたため。
おかげで486のIPCは386の二倍近くに向上した。一世代でのIPC向上は
この時期が最大だったんじゃないかな？

FPU内蔵化もあったの忘れてたわ　＞486のTr数

レジスタリネーミングがあるX86じゃ16本もあれば十分じゃないか？

ダイの写真見る限り、ほとんどキャッシュに費やされた感はある。
http://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:80486dx2-large.jpg

ItaniumとかPower7とかのメインフレーム級の巨大ダイもかなりの部分がキャッシュだしなあ

>>519
あぁ、そういえば上位下位に分ければもう少し増えるなぁ。
んでも、パーシャルレジスタストール（だっけ？）があるんだっけ？
なんか損した気分になる･･･

整数演算程度なら１６個もレジスタあれば、使い回しで余裕のコードを今時のコンパイラは吐くみたいだからね
レジスタは多ければいいってもんでもない、命令長にも関係するし
如何にメモリアクセスを少なくするかが早くするコツなのかも

実アプリケーションでは16では足りない。24欲しい。

いまどきレジスタ数ケチる必要もないし、HPC用CPUみたいに、256個の倍精度演算にも使えるレジスタでものっけとけばいいよ

コンテキストスイッチが出来なくなるのでそれはやめて
ていうか命令長32bitに収まらんよ

Itaniumみたいなレジスタ山盛りのアーキテクチャって
コンテキストスイッチのパフォーマンスはどうだったんだろう

今時のCPUは割り込みのペナルティが既に激重いし
数kB程度の退避復帰はどうということない気もする

割り込みは別に重くなってない。
割り込みの頻度が増えただけだ。

古典的RISCだと例えば256本のうち16本のみをバンクメモリのような感じで
アクセスして(レジスタ・ウィンドウ)コンテキストスイッチはバンクの
切り替えで行う。
IA64の場合は128本のうち32本(R0〜R31)のみが直接アクセス可能でR32〜R127は
リネーミング用及びコンテキストスイッチのための実メモリ上のスタックエリアの
上位部分のキャッシュ的な使い方だったと思う。

HPC用とかで大量にレジスタがあるやつの扱いは、
ほぼHPCアプリ専用レジスタとなってるレジスタ群は、OSやシステムアプリでは使わなくして、
その部分のレジスタの退避・復帰処理をおこなわないっていうことをすればいいんだよな

SH3/4が２バンク構成のレジスタ群つけたけど
コンテキストスイッチ？のせいで裏バンクレジスタ群はほとんど使われなかったような
armはレジスタ１６個あるけど、使い方が固定されたレジスタがあるから
数としては微妙な感じ

今、GPGPUのプログラミングしてるんだけど、何千ってスレッドが超高速に生成・切り替えられる。
CPUのスレッド生成や切り替えはクソ遅くて腹立った。
なんで同じようにできないんすか？？
つーかOSのせい？？

>>541の頭が悪いせいです

レジスタの量を誇るアーキテクチャって概してL1キャッシュのロード・ストア性能がｸｿレベルなんだが

>>541
Atomだと1クロックでスレッド切り替えられるよ。

>>541
スレッドと言っても別のもの
CPUもOpenCLとかで書けば超高速で多スレッドを"切り替え"できる
1スレッドにSIMDで展開されるだけだから

生成はスレッドプール系のライブラリだったらGPUのカーネル起動よりはるかに低コスト

>>543
L1やロードストアユニットに使う分のリソースを節約できているという見方はできる
同じリソースなら生FLOPSを上げることができるから特定アプリケーションでは有利
プログラマ的にはL1が速い方がうれしいけどね

ルネサスと国内3社が家電用プロセッサ事業の統合の方針を打ち出したが・・・

いまごろ遅すぎるんだよ
国内半導体メーカーはどこも規模が小さすぎて新プロセスに投資できないし、
財務が悪くなりすぎて身動きできない

５年前に大合併してでかくなって、最先端プロセスに投資できるだけの大きさになるべきだった

>>541
プログラムでスレッド切り替えたからと言って、
それがOS/CPUから見てスレッド切り替わってるかどうかは、言語やライブラリの実装次第だな

MCMCという逐次モンテカルロの中の重い処理をGPUとPTHREADで比較したら
PTHREADの方が早かったってことあったし一概に言えんわな
GPUの欠点でディバイス側にデータを送るコストとディバイス起動コストがあるからね

>>543
ベクトル型スパコンなんて、キャッシュ無しとか豪快なアーキテクチャだけどな
最近はベクトル型でもキャッシュ積む方向っぽいけど
メインメモリへのアクセスがボトルネックになるような演算をする場合、
あまりキャッシュ性能にこだわっても性能アップはしない
ベクトル型はもろにそういった設計だな

キャッシュ性能がそのまま実効性能の向上につながる計算なら、キャッシュ性能が高いほうがいいが、
HPC分野ではキャッシュ性能が実効性能向上につながらない計算も多いんでしょう

>>550
ベクトル型はプログラミングモデルが高速なメモリを前提としてるからね
メモリ帯域か安くて演算器の実装コストは高かった時代の名残

>HPC分野ではキャッシュ性能が実効性能向上につながらない計算も多いんでしょう
極論を言うとHPCのアルゴリズムはGEMMとFFTに還元できる（！）
GEMMはもちろんFFTもそれなりにキャッシュは効く

レジスタとL1キャッシュの性能って同じにならないの？そろそろ

今はDRAM帯域がもっともコストの高いリソースだから
そこを浪費するアーキテクチャは上手いとは思えない

GPUは帯域を浪費するアーキテクチャだけど
今のところGDDRのアドバンテージでどうにかなってる

レジスタは常に絶対アドレスで読み書きされるメモリだから
アドレスの計算やアドレス変換は必要ないし
依存関係もレジスタ番号を見るだけで解決できる

またスクラッチパッドメモリﾏﾝｾｰ!!の流れかｗ

>>551
HPC Challenge Benchmarkで、いまだにFFTで地球シミュレータが2位なことからして、(1位は京)
FFTでキャッシュが効くっていうのはかならずしも当てはまらないと思う

>>556
Global FFTでESが速いのは
クロスバのインタコネクトが効いているのと
メインメモリが超マルチバンクだからFFTのアクセスパターンで実効帯域が出るため

キャッシュがなければもっと凄まじい差が出る

ご意見ありがとう〜。

>>544
マジで！？
Atomすげぇｗ
なんで他のIA-32プロセッサもそうしないんだろう･･･

>>545
＞1スレッドにSIMDで展開されるだけだから
SIMD演算機をGPUでいうストリームマルチプロセッサみたいに使うってこと？？

＞生成はスレッドプール系のライブラリだったらGPUのカーネル起動よりはるかに低コスト
GPUのカーネル起動のコストがでかいだなんてショックだ･･･
ただでさえホストからのデータ転送で時間かかるのに。（ストリームで隠蔽する努力はするけどさぁ･･･）

>>548
やっぱそのへんが絡んでるんだね。
CPUの能力をフルに発揮するために、邪魔になるようなことはしないでもらいたいものだね。

>>549
＞PTHREADの方が早かったってことあったし一概に言えんわな
衝撃･･･ｗ
よほどGPUのアーキテクチャに合っていない処理だったのでは･･･？？

HPC専用設計のプロセッサなんて使えねーっての。いまだに夢みてんなぼけ老人は。
プログラムを選り好みしてるからニッチになって廃れる。
愚者は経験に学ぶというけど学ぶことすらしないのは愚者以下だな。

誰も流行るとか廃れるなんて話はしてないのになｗ
コンプレックスが酷い…

当たり前の話をしてるのに「コンプレックス」って発想がまず酷いｗｗｗ
コモディティの価値を理解できない頭の悪さｗ

FFT専用アクセラレータをCPUに積むのとおとなしくSSEだのAVXだので最適化するのどっちがマシなんだろう
アクセラレートしてもメモリ律速しちゃうから意味ないとかGPUに放り投げろとかは考えない

いかに大衆を騙してコモディティパーツの中に浸透させるかが大事だね。
CellはPS3さえ成功してればそこそこいけたのかもしれないね。
GPUは割と現実を見てるしVenusは何もわかってない。

今専用ハードを使ってメリットがあるのは
bit操作とかのCPUが苦手な処理か
FPでも完全にパイプライン化できる処理
前者はDESなんかのアクセラレータ
後者はGRAPEの6までとかかな

そうでなければデータパスや(オンチップに限定しても)メモリ操作が支配的になってしまうので
汎用プロセッサでいいやということになる

>>563
Venusは
与えられた制約：富士通の45nm の中で
目標：10PFのLINPACK性能
を期間内に確実に実現するという点では仕様を満たしているからね
責められるとしたら仕様を決めた奴らだろう

x86でノード作ると故障が多くて10PFなんて無理

XeonとKnightsのオールx86でエクサ狙ってるインテルを忘れんな
最近のXeonはRAS機能充実してきたお陰でItaniumがますますいらない子になっちゃうくらいまともなんだぜ…
Itaniumの未来はどっちだ…

decimal対応のFPUってどの程度需要あるかねえ

Itaniumは実質PA-RISC2みたいなもんだろ
HP-UX専用CPU

>>564
ビット操作みたいな命令レベル以下の細粒度処理が頻出であれば
FPGAでいいんじゃないのっていう
需要があるから改良され続けて陳腐化する事もないだろうし

規格化された処理なら専用ハードを作っても
元が取れるのかもしれないが、それは暗号化とかの話であって
いわゆる専用ハード（アクセラレータ）とはちょっと毛色が違うように思える

HPCは、TOP500対策にLinpack性能さえよければいいよっていうなら、汎用品のCPU・GPUでやるのが一番だけど、
Linpack以外の各種指標・いろんなアプリでの実行性能を求めるなら、現状汎用品寄せ集めでは無理

Linpackだけで評価するのはスパコンの性能を決める指標としてふさわしくないから、
HPC Challenge Benchmarkができたんだし

京ってさ、なんだかんだであの大失敗といわれてるΣプロジェクトより巨額を投じてるんだよ

IT分野での公共事業でいちばんの失敗作は、森総理時代にあやしいベンチャーとかにばら撒いた補助金だろ
かなりの額が補助金掠め取るだけの実体のないダミー会社や、ヤクザに流れたと思う

GPUをユニファイド・シェーダー単位で分解してCPUに統合，
CPUからは拡張命令で明示的かつ透過的にシェーダーで
演算を行えるようになるのか

インパク（笑）とかあったねえ

>>561
x86プロセッサがコモディティ・・・だと・・・？

DSPの１割でもいいからコーディング時のことを配慮してくれ

>>574
そんな細かい単位でCPUに結合しなくてもC++AMPとか（あるいはOpenCL･･･）とか言語とランタイムレベルでの統合は進んでくでしょ
それがハードウェア的にAPUほど密なのかGPUほど離れてるか、QPI版Knight的な付かず離れずくらいなのかはともかく

>>576
アスペは放っておけよｗ

どこのPCショップや家電量販店でも買えるものがコモディティじゃない理由を聞きたいね
限られた代理店しか扱ってないような限定生産品と一緒にするなよ

>>569
だな

http://www.computerworld.jp/topics/597/201155/
http://www.computerworld.jp/topics/597/201605/
＞HPはIntelに対し、年額8,800万ドルものお金をひそかに支払って同チップの
＞寿命を伸ばすとともに、Itaniumへの長期にわたる関与を公衆にアピールしたが、
＞こうした援助がなければIntelは同プロセッサの開発を止めていたはずだ

スパコンからx86サーバへ - コモディティ化が進むHPC市場におけるデルの戦略
http://news.mynavi.jp/articles/2009/12/07/dellhpc/index.html

君のコモディティの脳内定義とそぐわなかったからっていちいち噛み付く前に少しは
ググるなりしたっていいんだよ僕ちゃん

あれだけARMを馬鹿にしてきて、ここに来てコモディティのメリットを強調ｗ

>>582
そこでコモディティ化しているのはDellとか富士通といったメーカーが作っているPC(PCクラスタ)であって
x86プロセッサはコモディティ化していないからこそIntelは莫大な利益を上げ続けられていると思うんだが。
DRAMとか価格大暴落で大変なことになってるじゃん。x86プロセッサ市場ではそういうことは起こりえない。

x86はコモデティ(一般製品/日用品)ではあるけどコモデティ「化」(「枯れた」
製品市場にメーカーが乱立していて差別化が難しくなった状態)には至ってないな。

>>583
は？ARMのどこがコモディティなんだ？ｗ

>>583
馬鹿にしてんのは最近多いx86を駆逐してPCは全部ARM化！！！みたいなこと云う馬鹿の戯言だろう
ARMがx86と同じパフォーマンスだそうとしたらx86並かそれ以上に電力と熱と開発費を要するからな

> x86はコモデティ(一般製品/日用品)ではあるけどコモデティ「化」(「枯れた」
> 製品市場にメーカーが乱立していて差別化が難しくなった状態)には至ってないな。

CPUやOSのアーキテクチャが独占的な支配力を持ち競争が進んだが故に
PCは低価格競争が進んだんだが。
サウンドボードが廃れ次は単体GPUが廃れようとしてる。

君は何を見てるのか？

>>588
なんか食い違うと思ったらあんたはx86＝PCと捉えてたのか。
俺はx86＝プロセッサと捉えて>>585を書いたんだ。

>>585
なるほど。勘違いしてた。

http://northwood.blog60.fc2.com/blog-entry-5678.html
H.265が策定されるようだ。8k4kのスーパーハイビジョン規格、最初に再生に対応する
CPUは何だろうな

HD動画16本分だから大して難しくないんじゃないの
規格が通ったらすぐ出るだろ

というか、今の流れならむしろGPUの仕事だろ動画再生は
タブレットの貧弱なCPUでそれなりに快適に動画見れるのもGPUのおかげ

GPU？
ただの専用回路です

えっ

別にGPUの演算器使ってるわけじゃないから

GPGPUならエンコが爆速という話はどうなった？
最近はめっきり聞かなくなったが・・・

そんなの言ってるやつ居たか？
メーカーの人間だってGPGPUで高速化できるのはエフェクト適用部分ぐらいだって言っていたが。

CPUに比べれば早いけど画質が悪いってのが定説だった気がする。

画質が悪いのは10何年かけて煮詰められたCPU向けのmpeg2エンコードエンジンと同等の実装が出来なかったりするからだし
単に分岐予想だらけだったり演算が整数オンリーだったりGPUに向いてない要素が多すぎるってのもある

8k4kなんてGPUが余裕で死ねる

モニタが用意されない限り個人が心配する必要はないから大安心

>>600
最近のGPUは整数演算にも強いからスピードだけなら6コアのCPUより早いよ

いや単純な足し算、掛け算ならそうなんだろうけど
離散コサインだから264は

DCTこそGPUが最も得意な分野の一つじゃないか

同じHighPlofileでエンコードしてみたらPhenom×6の２倍くらい早かったな。
intelの６コアとは同等ぐらいかな。

H264はデコード時に整数演算だけでOKってだけで、エンコード時に使う演算とかは規定されてないので、
エンコーダがどんな演算やってるかなんてそれこそエンコーダ次第だろ
造ろうと思えば浮動小数点演算を使うエンコーダだって可能でしょ？

超越関数

画質から考えてx264を使ったCPUエンコ以外考えられない
GPUエンコがCPUエンコと同等以上の画質にならない限りおれは使わないよ

H.265とか出てもモニターも対応できないし一般人にはしばらく関係ないね。
GPUが対応するのも20nm以降でしょうしね。

8k4kは2k1kのいわゆるハイビジョンの16倍の高負荷だから現行のGPUではどうにもならない。

初期は専用チップ積んで当然

どうせ作成側に回れるのは、それなりに機材が安くなってからだから
CPUにしろGPUにしろ大幅に向上してる

>>610
動画再生支援はもともと専用チップだし対応すんの何て簡単だろ。
それほどトランジスタ食うわけでもないし。

普通の2K1Kでも圧縮率上がるんだから一般人関係ないなんてこと全然ない。

誰ももう圧縮率なんて気にしてねーだろ
気にするのは放送業界だけ

>>616
さすがにそれは無い。

>>607
整数DCTな上に使う行列まで仕様で決まってるが？

整数DCTはMPEG4/H264では支配的な処理ではない
符号化では適切なモードを選択する必要がある
動き検出にしてもCPU用のエンコーダは適応的な探索パターンを使うから分岐が多い

MPEG2なんかだと分岐はあんまりなくてよかった
そもそもMPEG2はハードウェアでの実装を強く意識したものだった

>>617
どこに需要があるか教えてほしい

youtubeのような動画共有サービスやってるところだと、
圧縮率上がる方が良いんじゃないの？
端末の性能との兼ね合いですぐに採用できないだろうけど、
圧縮率上がれば、ストレージやネットワークにかかるコスト節約できるし。

>>618
決まってるのはデコーダの仕様
エンコーダの仕様は決まってないよ
整数DCTを使わないといけないなんてことは無い

>>622
いや使わなきゃいけないからｗ
誤差の蓄積を防ぐために直交変換には整数演算を使わなきゃいけない
>>619の言うように動き検出なんかで使う余地はあるけどね

話のわからん奴だなw

MPEG2のときに手抜き演算が幅をきかせたので整数演算で縛ったら
動き検出で思いっきり手を抜かれたでござるの巻

あぁ、intelがrealの特許買ったのってこういう流れも見込んでのことか

>>623
使わないといけないって決まりはないって。
デコーダで再生できるならどんな手段を使ってエンコードしても問題ない。

それこそ拡張倍精度浮動小数点数を使って最後に整数に変換してもいい。
精度が上がるかは知らないけど

Wikipediaを見る限り、整数変換を使わない実装は非現実的に見えるけど

>>627
エンコーダで想定してる残差とデコーダで得られた残差が違ったら困るだろ？

つーか仕様書見たことないのか
変換行列の係数の約0.416を0.5で近似して、その分をポストスケーリングで補正
かつポストスケーリング係数を量子化パラメータと一体化させてテーブル引きにしてるんだぞ
浮動小数点演算で実装する意味がない

0.416じゃなくて0.414だった

だから何？
整数を使わないといけないなんて仕様では決まってませんが？

なんて突っ込まれてるのか理解しろよ

そりゃお前、整数以外を使うとか普通ありえないから、
あたりまえすぎて仕様に書いてないってやつだろ
それを仕様に書いてない、仕様で決まってないとか主張したいなら、
いいから砂場から人生やりなおせよウザいから、ってことじゃないのこれ

DCTの定義式どおりの変換とH.264の仕様で決まってる整数DCTは誤差があるので
定義式どおりに浮動小数点演算で実装するのは不可。

整数演算でできる事を仕様通りだけど浮動小数点演算でやるってのなら可能だろうね。
右シフトするところをわざわざ0.5掛けて丸めるとか。無意味だけど。

仕様で整数なんだが

16K9Kはいつの日か……

>>632
デコードの規格しか決まっていないのは事実だ
当たり前すぎるとかじゃなくて、それだけ決めれば十分だから
エンコードで整数でやるしかないのは、事実上そうなるだけ
因果関係理解しようぜ

GPUで整数演算がサポートされてなかったころからGPUを使ったエンコーダはあったから、
GPGPUを使ったエンコーダは浮動小数点演算で実装してると思う。

単にGPUに専用回路埋め込んでるだけじゃねえの？　そのほうが何かと楽だし

昔のati avivoはcpuしか使ってない

sandyのQSVやtrinityにもエンコ回路つくから
もうあんまりGPU使ってエンコはなくなっていくのかもしれん

GPGPUでも整数演算できるよ
浮動小数の仮数部を流用する

>>636
それを言い出すならデコードを整数でやるしかないのも事実上そうなるだけなんだが。
というかエンコード側の直交変換も仕様で決まってるっての。当たり前だが。

>>638
GPUを上位のものに変えると変換速度がちゃんと上がるから、
専用回路ってことはないと思う。
QSVは専用回路だと思うけど。

上位だとGPUクロックが上がっているからだったりして
専用回路はGPUクロックとは独立してるんだっけ？

GF6800に内蔵されてたエンコーダは固定機能のハードウェアエンコーダだったよねえ
その頃のmpegとかwmvのエンコードはfp演算メインだが当時のShaderでやらせるのは面倒だったろう

エンコーダあったのか知らんかった

ハードウェアエンコーダ載せてたのか。

GF6800にエンコーダ内蔵されてるなんて聞いたことないけどな。
デコーダと勘違いしてるんじゃないの。

デコーダだろうね

動画のデコード支援ならATI 3D RAGE�U+あたりのすっげえ昔からついてるし

Xbox 360コアとCellの類似性
http://pc.watch.impress.co.jp/docs/2005/0909/kaigai210.htm

http://pc.watch.impress.co.jp/docs/2005/0909/kaigai04l.gif

浮動小数点演算の前にあるキューが最初は「？」でしたが、
分岐によるストールを抑えるためと分かり感心しました。

クレバーなやり方だと思うのですが、
今どきのIntelCPUとかはこの方式は採用していないのでしょうか？
段数が増えて消費電力が上がるから避けているでしょうか？
（分岐ストールの抑制は分岐予測の精度を高めることのみで対応？）

http://pc.watch.impress.co.jp/docs/2004/0415/kaigai27.jpg
nv40のビデオエンコーダはフル機能実装してるわけじゃなくて一部の処理をオフロードって形らしいね
対応してるソフトは結局でなかったが。

>>650
>分岐によるストールを抑えるためと分かり感心しました。
ストールを抑えるためではなくてCompletionの巻き戻しの実装をケチるためじゃないの？
ストールはどのみち発生する
ROBがあるCPUならこれは必要ない

>>652
そうなんですか。
ありがとうございました。

いつの日か中華CPUを買える日が来るのだろうか
Chinese 16 core CPU uses message passing
http://semiaccurate.com/2012/02/21/chinese-16-core-cpu-uses-message-passing/

中華オリジナル()なCPUは既にいくつか出てる

龍芯：MIPSの盗用。訴えられてその後ライセンス契約。これを搭載するLinux
　ベースのネットブック発売の計画が数年前にあったが頓挫したっぽい。

神威：Alphaの盗用疑惑あり。中華スパコン「神威藍光」に搭載

龍芯 Godson MIPSライセンス
飛騰 FeiTeng(FT)　open source SPARC instruction set
申（神）威 ShenWei Alpha？

http://av.watch.impress.co.jp/docs/news/20120223_514066.html
8k4kで120fps対応の撮像素子が開発されました。これがビデオカメラに乗る日も近いですね


流石のHswellさんも内臓GPU程度の性能では手も足も出ないでしょう

近いわけあるかｗ

8k4k以下でいいから120fps〜240ｆｐｓあるいはそれ以上で撮影できる
レンズ交換可能なデジカメOR民生用ビデオが早く欲しい
EXILIM直焦点化改造とかより正式なレンズマウンタ使いたい

>>655
おうごんせんし　が おきあがり　なかまに なりたそうに こちらをみている！

>>659
黄金戦士は歴としたIntel純正のMobile MMX Pentiumを下駄に直付けしただけ

それよりはPentiumの刻印書き換えの漢芯を出すべきだらう。

プロセッサの話でたまに出てくる「リタイア」と「コンプリーション」ってどういう意味ですか？？

>>662
専門用語なので専門書を読んでください
コンプリーションはわりとIBM用語なので一般的ではないかもしれないが誤解の余地はない

CPUじゃないけどエルピーダ逝っちゃったね。
益々samsungばかりになっていくのか

エルピーダは製造を継続するよ
でもメモリ価格は少し上がるかもね

エルピーダ社長はかつてメモリ製造は将来２社になるっていってたが、それが当たったな
のこる２社にエルピーダがなれなかっただけで、
サムスンとハイニックスの２社になった

おいまだマイクロン生きてるぞ

CEOが死んだじゃん。
あれはやっぱり消されたと思うんだ

映画の見すぎ

両方、韓国政府が赤字を肩代わりしているわけで

日本の半導体会社はどこも電機メーカーの一部門で、自社の製品に使うことしか考えてないような製品ばかり作っていたな
もう少し早くファブレス化とファウンドリ化を進めたり外販を意識した製品を作っていれば今より少しはまともになっていたかな？

ファブレス化は嫌でも進行しちゃってるでしょ。日本電機メーカーの最大の失敗は規格を一般化というかデファクトスタンダードにできなかったことにあるかもな。

ファブレス化、とか効率の面で(つまりコストの面で)有意義だったってだけで
そんなに持て囃してどうすんの?って感じ
食糧自給の話と間接的に同じで、効率だけで人間が生きていけるなら
こんなに人口増えてない…

世の中振動したり螺旋だったりするんです。
今持て囃されている手管が普遍的かどうか見抜いたつもりは危険

ま10年保障のDRAMとか、私は「は?」 とは思ってたけどね。

１０年保証とか永久保証とか、そんな長期間使ってる人は少ない＆本当に壊れた時に保証をうけに来る人は
非常に少ないっていう前提で設計してあるんだしな

そもそもPCパーツなんて10年たてば実質ゴミ同然で使い道がないし
こわれてたとしてもだれも気にしない

寒チョンは払ってる法人税より輸出還付政策で戻ってくる額が大きいからなあ
そんな超絶チート経営してる国策企業に勝つのは並大抵のことではないよ

10年間保障は10年間壊れないじゃなくて10年間供給し続けるという意味かな
組み込みなら10年保障はありがたいんじゃない？

各社の製造部門が海外勢に各個撃破されて競争力が無くなった後に税金でゾンビ企業を誕生させてもな

露光装置も既に日系二社のシェア合わせても半分行かなくなっちまったのに未だに合併とか強化策が出てこない
現状まだ圧倒的なシェアを誇るもやはりインゴットやウェハを手掛ける二社もいずれああなりかねない

半導体族議員はいないのかよおい

>>678
いや、PC向け。

「技術で勝って経営で負けた」という言い分の真実　日本半導体の栄枯盛衰（後篇）
http://jbpress.ismedia.jp/articles/-/2554

技術力があるのが何人いたかってことじゃないの？
その他大勢な人たちの集団だった？

技術者が自分のオナニー技術は世界一自慢してただけってこと
顧客がそんな技術いらんつって買ってくれないのに
んで客が欲しいものを作る技術は低いというアホさ
液晶も露光装置も太陽電池も全部同じ構図なんだな

マクロの経済政策があんなでは、
一企業の多少の技術優位なんて簡単に覆される

>>663
分かりました。
調べてみます。

DRAMみたいな労働集約型産業は最初から日本に勝ち目ないよ。
知識集約型産業も衰退してるのが日本のエレクトロニクス業界の問題。

一番の決め手はシャレにならないほど円高が進んだことと
逆にシャレにならないほどウォン安が進んだことだよ。

韓国ウォンは４年間で価値が半減しているからメモリのドル価格が半額になってもウォンベースではとんとん。
逆に日本円は４年間で価値が1.5倍しているからメモリのドル価格が同額だったとしても円ベースでは3割以上の減収。

これでは戦えるわけがない。

>>676
不具合があったら交換するから「検査を省略しますよ」
っていう、コスト低減のマジックだったりするしな。

日本に技術力があるなんて、飛んだ戯言だ
いったい何を見て言っているんだか、理解に苦しむ。

ｴﾛPとｲｿ�р�比べようにも、仕事の誠意も
組織的な目的遂行能力も、比べるべくもない。
そこに会社の大きさは関係ない。

技術力てのは新しいオリジナルを作っていく能力のことで、
古いものをコピーする力じゃないと思うんだがな。

古いものを安く高品質に作るのも立派な技術力。それをさらに効率化させるための技術にも当然価値はある。

効率化が限界を迎えたら、最後は人件費なんで貨幣価値の安い新興国にはかなわないわけだが。

ペーパーカンパニーみたいなところは少ないような、日本の場合？

DRAMや液晶はその「古いものを安く高品質に作る」技術で負けたわけだがな

負けたというかダンピングに勝者はいない

まあ、メーカーが減ってきたら上がるだろ

メーカーが2社とそれ以上の数とで一体どれだけの差があるのか

この手のネタになると例に違わず
チョンとユダの工作員が湧いてくるな

>>689
> 古いものを高品質に作る
この能力が日本にあることには同意

だが、
> 安く
これはないな。

そもそも、非効率こそが日本のお家芸だと思うんだがw

>>696
日本で効率が悪いのはホワイトカラーっていわれてるな。
工場はましな方だし、省エネのような明快な尺度がある方面も優秀

看板方式もセル方式も日本が発明。どっちも万能ではなく弱点はあるが。

ホワイトカラーの仕事において、こういう工場の例に匹敵するような
日本発の方法論てあまり聞かない。なにかあったっけ

>>698
「Karoshi」
幸い欧米ではあまり採用されていないようだが

>>699
Karoshiﾜﾛﾀｗ

たとえ過労死で多少死のうが経済発展したほうがみんなが豊かになる

豊かって何だ
みんなって誰だ

福井県のことさ
ヤクルトの投手さ

CPUスケーリングの将来について，今後は素材が鍵になる？
http://www.extremetech.com/extreme/120353-the-future-of-cpu-scaling-exploring-options-on-the-cutting-edge

CPUアーキテクチャーは汚い方が勝つ。美しくてもコストが掛かるアーキテクチャーは消え去るのみ。その意味でARMの64bitは失敗が約束されている。

>コスト
?

綺麗なところから汚いものは作れる。
逆は無理。

速いCPUこそ美しい
それ以外の基準はバカの戯言

速度競争に引き込んだけど、頭打ちが早かったよね

むろん電力効率など指標は様々だが、審美学を持ち出すのはバカに限るということは不変

?
放射線に強いのも美しいよ?

そういう意味では今日美しかったものが明日は醜くなるのは必然

atomicな処理が苦手なのは今後不利になってくんじゃねえの？

>>708
モトローラで68040とか68060とか開発してた奴らに言い聞かせてやりたくなる言葉だ。

たしかにプログラム開発の面では綺麗なアーキテクチャだったんだろうけど、
そのための能力（動作速度）コストが過剰で、結局は墓標に化けたんだよな。

壮大な神の経綸に依りて
人類を滅ぼす

異星人から技術供与を受けて開発中のCPUに期待したい｡
コードネームは当然「Roswell」

モルダー、あなた疲れてるのよ

>>716
仮に異星人いるとしても、連中の使用してるコンピューターも2進数のデジタル
式だろ？単にシリコンよりスイッチング速度速い素材を使っているだけで。
基礎は地球製と変わらないと思うんだが。

異星人のテクノロジーも大したことなさそう。地上では普通に車で移動するっぽいし。

http://www.aliencomputertechnologies.com/

>>716-717
ﾜﾛﾀｗ

もともとCPU技術なんてない。メモリは死に、HDDは壊滅、Tronなんてなかった
一体エレクトリック大国神話の根拠は何だったのか

電子立国日本とは一体何だったのか

oioi
CPU技術はあったし、メモリは世界を席巻したし、HDDは優秀だったし、Tronはイケてたよ。
長期的に見れば我々は皆死んでいる。
神話の根拠よりも、神話崩壊の根拠を探そうぜ。

はははCPUはコピペ
アップルの尻に乗っかることしかできない日本の携帯端末企業
何も変わってない

日本に足りないのは小汚いマーケティング力
言い換えれば必死さ

潰れる寸前になって汚い事をし始めるなら、最初からこずるくなっとけよ。
それか潔く座して氏ねと。

倒産寸前の会社が見苦しく詐欺まがいのことをし始めるのが見苦しい。

小汚いビジネスをする人間は増えてるんじゃないかな
ソーシャルゲームとか。ハードウェアではいないけど

ワークステーションがもてはやされた日本のバブル期
速さだけでも、普及はしなかったってことじゃあ

まぁでもこういうハナシもあるワケで... http://anond.hatelabo.jp/touch/20120229223543

>>728
＞2chとかで、韓国ハイテク製品の劣悪さを書き込んでるやつらは
＞何も知らないくせによく言うぜとか。

ネラーの言い草は噴飯物なのかもしれない。だが、
メモリーなどごく少数の品目で例外的に技術があるだけかもしれない。

鉄道や建築や韓国軍の装備品など数々の失策とかあるわけで、
韓国の人材はサムスンなど一部に偏ってるんだと思うよ

・高い技術力があるから商売で成功する
・商売で成功してるから研究開発に巨費を投入して技術力が高くなる

日本メーカーや日本人の多くは前者が正解だとおもってたら実態は後者だったっていうオチ
アメリカの半導体メーカーでも、インテルなんかは商売で成功し続けてるから、
研究開発に巨費を投じて技術でもトップに立ってる
韓国の電機メーカーも、技術では劣勢だったのに商売で成功し、
それで研究開発に巨費を投じたので技術でもトップになった

ちなみにインテルなんてかつては技術的にはたいした会社じゃなかったんだよな
それでも、商売の成功を生かして研究開発・設備投資に巨費を投じだから
技術でもトップになった

量は質に転嫁するって事かな
販売量増加→開発費捻出→質の向上
日本企業のこのサイクルが壊れ始めたのはいつ頃なんだろう
そしてどうして競合を見ないやせ我慢を続けたんだろう

劣等民族のチョパーリかわいそうニダ(´；ω；｀)
ウリナラのCPUとメモリをOEM供給してやるニダ<丶｀∀´>

>>732
だよな。SEDテレビも結局発売できなかったし

まとまった設備投資を必要とするような段階になると日本は弱いよな

SED
そんなのもありましたね

日本の敗因の一つは、よく言われることだが
標準化を軽視したことだと思う。
デファクトスタンダード、ISO、等々。
ガラケーがいい例だ。

もっと言えば、市場の公正がもたらす意味を
理解せず、目先の利益で経営方針を
ころころ変える会社が多いと思う。

市場の公正はコンプライアンス上の縛り、と
のみ捉えるのは浅薄過ぎる。

むしろ積極的に競争相手を作ることで、
一時的に自社の利益を減らしてでも、
長期的に市場の存続と拡大を望む視点が
日本の経営陣には欠落しているのではないだろうか。

>>737
携帯以外にも例をあげてくれるとうれしいな

スマートフォンもタブレットPCもOEM供給してやるニダ<丶｀∀´>
チョパーリは従軍慰安婦を輸出すればいいニダ<丶｀∀´>

民主党という根本的な原因に誰も触れない件

>>737
むしろ製品が標準化されたことにより、技術がある一定のレベルに
達するとイノベーションが飽和してしまい、製品の差別化が要素が
価格に収れんしたにも拘らず、低コスト化戦略を取れなかったことが敗因。

標準を主導する企業は、その標準が陳腐化しないようにすることで
製品の脱成熟を図る。これが出来る企業をプラットフォームリーダという。

そんなこと書いていて恥ずかしくないの？

ダイスタッキングが進化すると今のような基板のメモリモジュールは消滅し、いくつかのメモリダイを搭載したLGAタイプの
チップをソケットに装着するような形式に移行するだろう
そうなれば接続の電気的特性が改善して現在の数倍の周波数で接続できるようになり、接続ピン数も大幅に増やせるため
帯域が大幅に向上する
この時代には一般のパソコン程度のメモリはすべてCPUパッケージ内に搭載されることになり、メモリソケットを持つコンピュータは
サーバのみになると予想する

とはいえ、現在の（PC用）CPUでさえ、286のころのPCのメインメモリなみのキャッシュ積んでるからなあ

98しか頭にないから640kbすか

486の頃でも4〜16MBくらいだったよな
DX2 8MBでWindows95動かしてたのが懐かしい

イノベーションって簡単にやれるようなもんなの？

やれません！

もしも簡単にやれたら、多数生まれてくることが当たり前になり、
そうなると、一段違う当たり前ではないモノにしか価値がなくなり、
そちらがイノベーションと呼ばれるようになる

コロンブスの西インド諸島発見はイノベーション？

ノーバントノーボール作戦

あれは帰りの航路を見つけたのが大発見だったらしいから
あえていうとパラダイムシフトかな。

>>746
今だったら、OSを含め、すべてキャッシュに乗るんだよな。
と言うことは、20年後にはwindows7の環境がキャッシュに収まっているんだろうか？

今のアプリは肥大化してるから、全部乗せるのは無理なような
無駄な処理がhddに移動してるだけじゃ

あらゆる機能をCPUに集約する方向に進みそうだね
自作PCはますます廃れそうだ

しかしCPUとメモリをワンパッケージ化するとしたら
メモリメーカーと協業でできる範囲を超えそうな感じ
IntelはMicronを買収でもするのかな

>>753
ムーアの法則が健在なら約1000倍のトランジスタを使えるから載せられる
しかしまぁ無理だろう

頭打ちした法則に意味があるのかいな？

いままでどんなけ半導体の進歩にフリーランチしてたかを思い知るためだな

>>757
むしろ、その他の条件は頭打ちか悪化してる中で
ムーアの法則だけが続いてる感が

今後はトランジスタを無駄遣いしてでもワットパフォーマンスを上げるか、
マルチコア・メニーコアでソフトウェアに性能向上の責任をたらい回すか
たぶん両方を並行して試みる事になるんだろうけど

そこまでコストを掛けないと進歩できないならもう今くらいでいいんじゃね
という風になると悲しいな

IT業界の投資効率の高さは半導体の指数関数的な進歩に裏付けされていたわけで
製造業並みにしか進歩しないようになると金回りが一気に悪くなりそうだ

指数関数的に高性能化したおかげで、かつては50万くらい出してPC買ってた状況から、
PCなんて5万もあれば十分みたいになったけどな

あと、PCが安くなったのは、クロックが上がらなくなって一般人がなにで性能を判断すればいいか
わからなくなったのもあるとおもう

かつてはクロックが早ければ早いほど高性能っていうのは、かなりの素人でも理解できたので、
クロックが高いのを買おうとする動機がうまれて、結果として高いモデル買う人が多かった
いまじゃ安いモデルでも高いモデルでもあまりクロック変わらない

いまは、iPhoneは32Gより64Gのほうがいいみたいにフラッシュ容量で性能を判断する時代

周辺その他もろもろがコスト競争して、手頃な値段になったってだけでしょ
クロックうんぬんは一部のパワーユーザーが騒いでただけのような
パワー競争に引き込んだってのもあるかも
ゲームマシンとしてパソコン使うにはCPUパワーが必要な作りになってる？

ムーアの法則はアナリストみたいな人が法則と言ってるだけで実態はロードマップみたいなものなのでは？
まだしばらくは頑張るみたいだけど、現場ではあらゆるコストとデメリットが膨れ上がってて大変なんじゃないかと。

今後周辺回路のSoC化を終えれば、トランジスタの使い道も苦労しそうで状況や用途に合わせた専用モジュールが増えていきそうですね。

>>759
これもそうだね。トランジスタを省エネに使う。

ARMが次世代CPU「Atlas」と「Apollo」の計画を発表
http://pc.watch.impress.co.jp/docs/column/kaigai/20120214_511793.html
そして時代はARMサーバーとARMスパコンへ
http://pc.watch.impress.co.jp/docs/column/kaigai/20120221_513347.html

微細化が色々厳しくなってるし今後
半導体産業の方向性が大きく変わりそうだね

Intelでさえファウンドリ事業やら450mmウェハーへ
移行推進だの言って
最先端プロセスで利益を維持しようと苦労してる
GFやTSMCはそれ以前に32、28nmで歩留まりをあげられない

未来の見通しにしても
EUV露光は光源開発で大幅に遅れてるらしいし
液浸＋マルチパターニングで
コストが上がる一方じゃ微細化進める意味ない
下手すると14nmかその次ぐらいでCPUのプロセス開発は終了しそう

以前に比べて絶対性能の向上を求めるCPUユーザーは減った。
しかし電力当たりの効率向上は依然として求められている
（モバイルではバッテリー、データセンターではランニングコストからの
プレッシャーが強いわけで）

後者だけでプロセス開発のコストが捻出されるかどうか、かなー

EUVはたった数社・・・しかも実質Intel以外息切れ状態じゃ、開発スピードが加速しなさそう
そのIntelも22nmの出荷が遅れているし。

↓どう思う？
ttp://semiaccurate.com/2012/03/07/tsmc-suddenly-halts-28nm-production/

ガセニダ
NVのGK104が上手くいっているニダ

>>766
データセンター等は、性能基準→性能/電力基準ときて
今では性能/電力/価格基準になってきているからな。
処理量当たり価格が導入コストを含めると下がらない、という状況になったら、
プロセスを進める余地があっても歩みは止まるだろう。

GFが2015年にEUV採用らしいけど、大丈夫なのかな。
IntelはEUV採用はどんどん遅らせて、11nmも液浸でいけるって言ってるけど。

iPhone・iPadで、モバイルでも高精細ディスプレーが当たり前になったが、
現状じゃディスプレー解像度に対して、モバイル用GPU・CPUパワーが十分ではない

デスクトップ用じゃCPU・GPUもコアゲーマー以外には十分なパフォーマンスを持ってる

あんな小さい画面にあの解像度は意味あんのかね。

3Dにすれば解像度は2倍必要だな
3D表示が必要かどうかは別の問題とする

>>773
至近距離でみる場合には、PCディスプレイは画素が粗すぎる

というか、一度見てみろ
新iPadはまだ見たことないけど、PC用の技術展みたいなので、あのくらいの密度のパソコン用ディスプレイ見たことあるんだが
目がすげえ楽だぞ。ものすごく見やすい。まるで紙を見てるような

早いとこパソコンにもあのくらいのディスプレイが出てきてほしいもんだ

本を読むように使うにはnew iPad くらい解像度がある方が楽だろう。
しかし、本のように見る場合はバックライトではなく
反射型（かつ高コントラスト）の方が楽だが

eInkは見やすくて良いね
アレみると液晶でブックリーダーはやっぱりちょっと……ってなる
欧米のペーパーバックみたく藁半紙に毛の生えたような代物の代替なら別だろうけど

新ipadはiphoneよりぜんぜんDPI低いじゃん
Samsungの新型は2560x1600らしいし、早いところ10型タブは3072x2304くらいが当たり前になってほしい

フルＨＤのテレビやPCモニタより高解像度なのかよ
そんなに解像度あっても意味なさそう

各原色が二階調だからタイリング(網点やFMスクリーニング)で中間色を
表現する印刷物だと600dpiとか1200dpiとかが必要だけど、ピクセル
自体の輝度が多諧調な液晶やELなら精々200〜300dpiで充分で、それ以上
精細化しても意味が無い。

最初iPhone 4なんてイラネ言ってた3GSユーザーが
Retinaディスプレイ見て「もう3GSの画面見てらんない」と心変わりしたように
一度2048x1536を目にしたら旧iPadには戻れんよ

http://cdn.pocket-lint.com/images/Fq2W/ipad-retina-screen-how-good-0.jpg

たかが画質なんて3日使ってれば慣れる

>>782
こりゃすごいな･･･
10インチ程度の画面にオーバーフルHDは過剰かとｵﾓﾀが、
これを見ると認めざるを得ないな･･･

>>783
新PC組むとその速さにすぐ慣れてしまう
そして前のやつ使うと超遅く感じる、その後3日使い続けても遅く感じる

進化にはすぐ慣れるけど、退化には違和感を感じるのが人間の感覚

そうやって人類は進化してきたんだな･･･

なんで早速ステマ沸きまくってんの？

ウルトラブック終わったかな

Intelの「ノートブックじゃありません！ウルトラブックです！」が笑けてしょうがないｗ

>>771
GFの場合は2015年どころか、今年の28nは大丈夫なのかっていう

Androidには、例の緻密なディスプレイの機種が出てくるんだよな
PCは本格的な作業用なはずなのに、iPadやAndroidタブレットに置いていかれてる

ドット細かくなくてもいいからせめてタブレットの全画面を表示できるディスプレイを安く出してくれ

需要がないからでないだろ。

高精細なモニタはいいんだけど、結局大きいモニタの代わりにならないからな。

デスクトップPC用には、23インチ4k2kディスプレーが必要だな

なんでだよ

Pentium4時代には15インチQXGAのノートPCが売られていたわけだが…

Windows側が高精細に対応したインターフェースじゃなかったからな
文字が小さいだけで読みにくくなったり、文字大きくしてもアイコンその他のサイズがうまくマッチングできなかったり

Windowsとアプリが高解像度のディスプレイに対応しきれていないのがな
今は亡きLonghornの理想はどこへいったのやら

OSやアプリの高解像度ディスプレー対応が先か、高解像度ディスプレーの普及が先かってところだな

iPhone/iPadは、ハード作ってる会社と、OS・標準アプリ作ってる会社が同じだったから、
ハード・OS・標準アプリ足並みそろえて対応した

NeXT STEP の時代に既にDisplayPostscript で解像度非依存が
目指されたのに普及は遅々として進まない

安藤さんの経歴詳しい人いない？
SPARCに携わってたらしいけど、アーキテクトレベルだった？？

http://www.ieice-hbkb.org/portal/doc_writer_detail.html?wid=81

>>802
ありがとう！
やはり、なかなかの経歴！

htmlで解像度非依存化が進むかと思ったけど、結局、見た目にコダワルでざいな〜達によって
解像度非依存は達成されていない…

flashとか使いまくってるしな。

Retina iPad並みの高解像度でFlash描画したらCore i7レベルでも
フレーム落ちするコンテンツはザラにありそうだが

html で論理構造、意味的内容と
視覚的具体化とを分離するはずだったのになー

でざいな〜様には歯向かえませんわ。

フレーム落ちを防ぐためには、GPGPUとか、FPGAや専用のDSPとか、ASICなんかを
混載させたりすればいい。

単純スケーリングだからそれほど高負荷にはならないだろ｡

Freescale Releases 28nm 12-Core and 8-Core 64-bit Power CPUs
http://www.brightsideofnews.com/news/2012/3/12/freescale-releases-28nm-12-core-and-8-core-64-bit-power-cpus.aspx

ところがどっこい
Flashの2DレンダラーはCPU描画なんです。

GPUアクセラレーションがきくのはあくまで埋め込み動画の再生の部分だけ
そりゃAppleが嫌うわけだ

CPUはバク速頭打ち、そのかわり、GPUその他の周辺がインテリジェント化って流れになっちゃたよね

Flashは、10.0ベータ版の初期の頃はかなりの部分をGPUで処理してCPU負荷がかなり軽くなった
でも、たぶん特定のGPUやデバイスドライバでうまく動かない等の互換性問題の解決のためか、
いろんな部分をCPU処理に戻して、CPU負荷がどんどん高くなった

久々に来たんだけどコテハンを初めとして
熱い闘いを繰り広げてた人達はどこいったのー？
(´･ω･`)

団子さんは闘志を失ったのかな？

たぶんこっちで虐められてる↓
http://awabi.2ch.net/test/read.cgi/phs/1331128938

団子ならAMDスレかプ板にいきゃ見られるよ

>>817
え？プロレス板？

A5Xデカすぎじゃね？
http://www.anandtech.com/show/5685/apple-a5x-die-size-measured-16294mm2-likely-still-45nm

Appleくらい売れないと元が取れないな

>>819
28〜32nmで出る次のiPadまてばよろしい

まあ、GPUだろうしな、でかくなった分は
そのくらい足回りしっかりさせとかないと、画面が4倍になってるんだから厳しいんだろう

http://semiaccurate.com/2012/03/21/ibm-power-7-spotted-and-it-is-a-monster/

きたか…

>>823
要約してちょ〜。

リンクを開け。英語読め。




次世代Power7+（のプロトタイプ？）は4CPUダイをひとつのInterposerに搭載してパッケージングされるとのこと。
でもCharlie割とDisり気味だな。4つも乗せての熱問題とか、なんでeDRAM乗せないとかInterposer以外の点で。まあそんな冒険してほしくもあるがIBMらしいといえばらしい。

>>825
ありがと〜 ( *´3)ﾟдﾟ) -chu!

Power7がでかくて熱くてしょうもない子だっただけに熱の問題はまあたしかにあるな
あの大容量eDRAMキャッシュなくなったら足回りに不安があるのも確かだし

次期Itaniumちゃんとどっちがマシか勝負？

無印の45nm からシュリンクされるだろうから
こういうMCMからインターポーザーに切り替えるってだけなのでは

ttp://news.mynavi.jp/photo/articles/2010/01/03/supercomputer2010/images/004l.jpg
ttp://news.mynavi.jp/articles/2010/01/03/supercomputer2010/

放熱機構が支配的なので実装密度だけでいえばMCMとそう変わらないだろうから
あえてシリコンインターポーザ（？）を使うというのは
チップ間インタコネクトの消費電力が馬鹿にならないということなんかな

>>827
対象市場が一応は有利なのとクロック落とせば何とかなるだろうから、これぐらいならいけると踏んだんじゃ？シングルスレッドもいるけど基本鯖でスレッド偏重だし。
ItaniumはOracleといまだに揉めてる。


>>828
どーなんだろね。HPC向けなのかいまいちわからん。確かメインフレーム向けならL4キャッシュを外付けしてたはずで、
それをMCMにしろとCharlieが言うんだったらわかるが、ただ低コストになるだけであんまメリットないし帯域より容量重視が基本だしな。
BlueWatersをもう一度やるにしてもさすがにここまでやるか？と思う。

POWER7は小規模なシステムはそこそこ売れてるだろう。
巨大HPCとしては設置されてないけど

安価だかプアバンド幅のx86 クラスタとバンド幅リッチだが
高価すぎるSXの間を埋めてる感じ

あれはHPCだと大規模SMP用だろう

>>825
| でもCharlie割とDisり気味だな。4つも乗せての熱問題とか、なんでeDRAM乗せないとかInterposer以外の点で。
どこにそんなことが書いてあるんだ? 全文転載しとくから具体的に指摘よろ。

==
[1/2]
http://semiaccurate.com/2012/03/21/ibm-power-7-spotted-and-it-is-a-monster/
IBM Power 7+ spotted, and it is a monster
Common Platform 2012: Mine is bigger than yours
Mar 21, 2012 in analysis, Channel, Chips, Memory, Microprocessors, Opinion, Rumors, Servers Tweet
by Charlie Demerjian

Every once in a while, a company will do something really unexpected, like IBM’s laying down the law in packaging last week.
Yes, they showed off a chip, two actually, that does things no one else is even talking about doing.

If you look at the chips below, you will see, well, a really advanced packaging set-up. How advanced? Well, this is four CPU
dies on an interposer, and not a small interposer at that. Each black spot is a 32nm multi-core die, and a very hot one too?
How hot? Well, the chips below are the first Power 7+ parts spotted in the wild, so think really stinking hot.

>>833
[2/2]
Power 7+ package minus lid

To be specific, the two on the left are four P7+ dies on an interposer, and that is mounted to a ceramic package far left,
organic to the right of that. On the right, there is an unnamed stacked die chip with and without lid. This means IBM can
stack die directly, do a PoP on both ceramic and organic, and most importantly do it on a higher power part than anyone else
will ever need. We won’t mention reliability, if there was any question about that, IBM wouldn’t put it on Power chips, those
customers don’t cherish their downtime. It’s one of the few platforms deemed too reliable for Windows.

OK, so IBM is laying out the law on advanced packaging, and no one else has shown this type of tech, not to mention anything
on this scale. Could it get any better? Sure it can. What if I told you that the interposer wasn’t a passive part, but an active
one with lots of embedded RAM. Need a few, oh, lets say tens of MB cache with a silly wide interface? See above. Also see
your local IBM rep because no one else can do this. S|A

>>829
MCMの中の1チップがDRAMインターフェース 100GB/s分、
MCM内接続用 360GB/s分とか持ってるから、
電力への寄与がかなりあるのかもしれないな

>>835
DRAMは実効100GB/s でグロスだと180GB/sだった。
あとCPU MCMとインターコネクトモジュール間接続
48GB/s (4チップで192GB/s) も

>>815
ちょっとしんどい仕事とってきたのよー。
報酬はまあまあでかい。

団子さんｷﾀーーーーー！！
お仕事お疲れさんです！

nVIDIAの新GPU、Keplerについてどう思いますか？？

団子さん的にはL/Sが少ないから論外なのでは
いまもCUDAの開発者のサンプルってもらえるなかな

181 : ,,・´∀｀・,,）＜一番良い -○○○ を頼む : 2010/12/17(金) 02:28:15 ID:B5m/oTnv
>>179
残念ながら俺は【店員】のバイトなんてやったことは一度も無いんだわ。
よくできてると思ったのはあなたの自己紹介としてという意味でいいのかな？

あ、ちなみに今は時給換算1900円くらいのしょっぱい仕事だけど
顧客からもちゃんと高い評価は得てるよ。

少しは報酬上がったのかな？

んな薄給なの？
俺が雇うぞ

いくらで？

Webは概して単価安いよ。

団子の知識でwebかよw
HPC関連やんないの？

Nの営業に仕事クレクレしたことあるけど断られたけど？

市場が未成熟HPCは分かる人間少ないからうまく分かる人間にく当たらないと難しいと思う
線形代数、数値計算は問題ないよな

古いマシンで使う分にはFermiの方がKeplerより良いと思う。

目をつぶって数学公式集を開いて、どの公式に当たっても
既存のライブラリと同等以上のものが書ければ
HPC関連で自営業始められるかもな

そのテクニックがライブラリに反映されておしまいじゃね?

派遣屋さんに近所の某旧帝大の研究室常駐の仕事紹介してもらったことがあるけど
マージン抜いたらしょっぱい時給になったよ。
経歴に書く程度には役立つかもしれないけど上手い飯は食えないな。

自分で仕事取ってきて稼ぐなんてカッコイイ！！
団子さん、憧れる！

ただのフリーターだろ

むしろ自分でパッケージを開発して売り出さないとね

まあ、大学の研究室常駐の仕事ってバイト扱いだしな。

マージン抜かれなくても、時給千いくらとかだろ?

プロジェクト付きの助教とか講師なら掛け持ちでも結構出るけどな
飾りでも学位と業績がないと採るのが難しいのがあれだが

テクニシャン?

CellできますCUDAできますなんて言ってもなかなか食えない

厳しい世界なんだなぁ･･･
難しいことできるのに･･･

本当に難しいのは誰もやりたがらないつまらない仕事のことだ。
Cell, CUDAは楽しいけど、殆ど役に立たないから金にならんのだよ。
HPCも一部の研究者が必死に宣伝しているけど、同じで
実際やれば大したスキルが必要ないことがわかるぜ。
(HPCユーザである研究者の殆どは、シミュレーションの方式と結果に感心があっても
最適化コードの些細な速度差には関心がないからそんな技術は元々いらない。
ネットで騒いでいるコンピュータオタク兼研究者の人たちは特殊な人たちなので、誤解が広がってるだけ。)

そんなぁ･･･
でも今まで何日もかかってたMRIの計算が数十分でできるようになったとか、
すごく世の中に役立ってるじゃないスか。

百倍はやくなるとか、オーダー違いで3乗が2乗になるとかだったら
価値はあるが、それはコードの最適化スキルというより、アルゴリズムの研究だな。
コードの最適化というのならどっちかっていうとコンパイラ屋とかOS屋の方が向いていると思う。

シミュレーションの世界で2倍, 3倍じゃできること殆ど変わらんのよ。
それにこだわるのはPCのCPUで10%の性能差に目くじらたてるのと同じで、
一般ユーザの考えではないから。
宇宙の空間だけで3次元あるということが既にきびしいだろ。

2倍3倍違えば大きいぞ
20％30％じゃたいしたことないが

一般ユーザが使用している資源とハイエンドの全体近くを使うような物では
2桁3桁の規模の違いがあるからシミュレーションに質的な変化を起こせる
可能性は多くのユーザにある。
またそれだけの並列度の違いを乗り越えるにはそれなりのスキルも必要だろ。

PS4の噂
http://kotaku.com/5896996/the-next-playstation-is-called-orbis-sources-say-here-are-the-details
http://orbis.scedev.net/

・コードネームでOrbisと呼ばれている
・2013年のホリデーに発売予定
・PS3互換はなし
・中古対策あり
・ゲームはBDとダウンロードで供給

スペック
・AMD x64 CPU
・AMD Southern Islands GPU

・開発キットは今年初めから出回っている
・Orbisの性能は次世代箱より低く、EAは失望したようだ

GPUはまだ解かるがCPUもAMDってのはなあ。GPUもSouthern Islands積むなら時期的にKeplarもいけるだろ。

据え置きゲーム自体がオワコン

空間が3次元だから厳しいとか、70年代からタイムマシンで来た方ですか？

1次元よりは厳しい

1年で200倍くらい性能を伸ばせない所が人間の限界だわ｡

ｘ86とかｘ64はゲーム機に向かないよ。アーキテクチャがどうこうじゃなくて
えんえんとゲーム機の寿命まで同スペック（シュリンクや省電力化はアリ）で生産し続けるわけで
PC向けがどんどん性能あげていく中で、明らかに遅い旧式スペックをわざわざ作る羽目になる

生産や改良の非効率もだけど、PCと直で比較されるからそう長く売ってられない
たとえばPS3に出た当時のx86が積まれてたとして、Ｐｅｎｔｉｕｍ４積んでるゲーム機ってCore2くらいの時点でもう売れないだろ
多少の非互換覚悟して新型CPUを低クロックで動かすにしても、今度はその低いクロックでがっかりだしな

x86載せるならゲームのルール変えなきゃならんよなあ

>>869
学生さん？
古くなろうが金になるなら作りますよ

アーケード筐体のtypeXはwindows PCなんだが

ごく単純なことで、修士、博士、オーバードクターの持つ
ソースコード生産性（能力ｘコーディングへ向けられる時間）に
明瞭な差をつけるような人間でなければ、給料払って雇う意味がない

>>871
作らないって話じゃなくて無駄ってことねｗ　ちょっと表現がわかりにくかったかスマン
ま、一番「向かない」理由はPCにスペックでおいていかれるのが目に見えるってほうだけど

>>869
Pentium3相当を積んでいる初代XBoxもずっと売ってたし
Geforce7800相当を積んでるPS3も今のPCより明らかにしょぼいがまだ売っている

XBoxがコストダウンに苦しんだのは設計情報を持っていなかったからで
>>864の噂はCPU/GPUともにAMDということだから 特注で設計情報は押さえて
将来的にシュリンクしたらワンチップ化してコストダウンという想定なんじゃなかろうか

>>875
その初代箱が、シュリンクも周辺のワンチップ化もやらない（できない？）で、高コストのままだったのも
苦戦した原因のひとつって話を見たことがあるんだよな（原因がこれだけって話ではないので念のため）

AMDがらみならAPUってことで、グラフィック関連の統合はできるというか出来てるとして
低性能CPU（機器の寿命後半ね）は組み込み向けとかを使うつもりなんだろうか
シュリンク版とかを別系統で開発する余力はないだろうしな

>>864
これは嘘だろうな
SCEのハード設計部門が海外主導にならない限り、あり得ない話
PSVitaを見ても中身は東芝製が主で、体制体質はPS2、PSPと大きく変わってない

どっちかと言うと次世代Xboxの話なら信じられる話
新型Xbox360の1チップ化、設計はAMDが担当したって言われてるし

GPU部分がAMDなのはほぼ確実だし、その部分がAPUってならありかもしれん
Cell+APU

cellにする意味なし

>>877
設計はどう見てもIBMだが
ttp://pc.watch.impress.co.jp/docs/column/kaigai/20100825_389002.html

>>869
今でも80386（30年近く前のx86CPU。動作周波数は12〜40MHz）がえんえんと生産されて
実際に宇宙開発や兵器用途に使われているという実績があるのは無視かい？

そして性能比較されるっていうけどゲーム機用のCPUなんて
ファミコンにARMを積んでいたころから数ランクも格下だった歴史も無視かい？

そういえば韓国軍のK9自走榴弾砲のCPUがi386だか486だって書いてあったな。
つっても所詮用途が用途だし受注生産に近いだろうから同じCPUでも高騰してしまってるだろうけど。

最先端のCPUって宇宙放射線で動かなくなるんじゃなかったっけ
軍用も現場で使われるのは性能よりファンレスで動く事の方が重要だろうな。

新鋭CPUを使わない理由は安定性重視してる面が強いな。
枯れたCPUは一般ユーザーがベータテストしてバグ出し協力しきったモノと言う見方が出来る。
あと宇宙用途だとなお信頼性が高い必要がある上にシュリンクされすぎてるものはビットエラーしやすくて使いにくい。

設計開始から運用開始まで20年かかったりするからな
最新CPUは採用したくてもできない

F22はi960を使っているが、
開発開始(YF22)が1986年、初飛行1990年(YF22)、1997年(F22)、運用開始2005年だ

>>885
えらい長期間なんだな。
そんだけかかると、さすがにテクノロジー背景が大きく変わってそう。

>>881
まず「コスト競争で不利」であって、「作れない」ではないよね？
現に初代箱がCPU作ってもらえなくて終了って話は見たことも聞いたこともない

次に、ファミコンは6502系カスタムチップ、ARMはゲームボーイアドバンス

純正品としては486やPentiumあたりも製造終了らしいけど、
互換チップは現役で作られてるよなあ。パッケージ（ピン形状も）は変わってるだろうけど。

K6だって、PCでは見かけなくなったあとも、けっこう長い間作られ続けたはず。

Z80も未だに作られてるんじゃね

Z80とか最悪エミュかFPGAでどうとでもなるレベルだけどな。

>>875
設計情報つーか、NVIDIAがチップを卸して宝だったはず

>>886
F-22（つか90年代開発の兵器の少なからず）は冷戦終結のあおりで計画着手〜
量産のスパンが延びてるけど、軍用機はおおむね設計から量産開始まで10年、
量産開始から配備定数生産完了までまた10年程度が普通。
要素技術は設計開始時点で既に十分実績のあるものである事が必須だから、
民生品感覚だと随分古い（枯れた）ものを使ってる。

最近はアップデートもあるよね

10年かかると、もし今今年丁度に就任する機種があったらCPUの設計は2002年のベースになるのか
2002年ってなんだっけ

北森が出始めた頃だな

散々笑いものにされた藁が世界の平和を守るのか･･･
熱が胸いな。

90年代開発開始2000年代に配備開始のF-2はMIPSだな

>>889
Z80だって、すでに互換CPUとセカンドソースだけしか残存しないんでは?
ひょっとしたらセカンドソースもなくなってるかもしれん。

そもそもザイログ社そのものが...

CMOS版のZ84C00が2010年のザイログのカタログに載ってるけどな
NMOS版はシャープも製造やめたようだし絶滅種かもしれん

>>896
イージス艦のCOTS（民生品利用でコストダウン）改修では一番最初の時はほんとに藁P4積んでたぜ

>>861
あんた、多少わかってる人だね。
二乗根、三乗根のｸﾞﾗﾌの横軸を性能向上、縦軸を得られる効果とみれば分かり易い。
規模の小さい問題しか解けなかった昔はｸﾞﾗﾌの立ち上がり期辺りに当たるので、
多少性能が向上するだけで露わに効果が現れたが、
しかしある程度規模の大きい問題が融けるようになればなるほどｸﾞﾗﾌの平坦部に移行し、
横軸方向にリニアに性能を向上させても縦軸の解にほとんど何も変化をもたらさなくなる。
半日が30分になったとか人間が感覚的に体感しやすいﾚﾝｼﾞにある
一部の問題以外では性能向上による効果が薄くなったのさ

>>892
10年も経ったら部品作ってない・・・・・・なんちゃってｗｗ

軍用機も、二次大戦のころは毎年のように新型機だったのに、今じゃ親と子で同じ飛行機ってのも珍しくないからな
パソコンもあと50年もすればそうなっちゃうのかな

ま、タブレットその他に食われて消えちゃう未来もあるかもしれんが

軍用機は平時にはほとんど損耗しないのに加えて、高機能高額化で調達数がどんどん減っていった
つまり数が出なくなったから開発ペースが落ちただけで、PC業界とは全く傾向が違う

細々とだけど確実な需要があるから悪くは無いと昔は考えられていたけど。
今、特機部門なんて、どんどん閉めてるもんな…

【レポート】従来比2倍の性能を1/10の消費電力で目指す - メニーコアシンポジウムが開催
http://news.mynavi.jp/articles/2012/04/05/many_core/index.html

>>906
壮大な計画だなぁ･･･

>>906

いつまでにってのが重要だよな。来年？

基本は「今のシングルスレッド（C）をメニースレッド（OpenCL）に変換する技術を構築」であって
長期的な学術研究なのに期限が重要か？

>>909
10年後に1/10で2倍を実現しても意味ないですよ。

自動並列化研究の「失敗」から、一般的にはシングルスレッドを並列化するのは不可能というのは既に自明だと思います。
これは時間が解決するような問題ではないと思いますが、どういうアイデアでそんなことが可能になるのでしょう？

>>910
リンク先YONDA?

>>911
ちゃんと読んでませんでしたが、対話的にOpenCLを生成するところが新しいアイデアということでしょうか？
そんなことするなら、最初からOpenCLでコード書いばよいのでは？

お前がタダで書いてくれるの？

ﾜﾛﾀw

>>910
別に自動並列化が失敗しているわけではないだろ。
なにいってんだ？
それに10年後に2倍になるんならいいじゃねーか。
今2倍になるのと同じ事だろうからな。

大量のレガシーコードの存在を考えると
自動並列化系の技術を進めるしかないんじゃないかなあ
技術的な困難が大きいのは分かりきった話で、
それでもなお強い必要性がある

SMPの自動並列化はｺｺ10数年くらいで十分実用的になった。
賢いｺﾝﾊﾟｲﾗがとっくに使われている。
もし実用的でないと思うなら使っているｺﾝﾊﾟｲﾗがいまいちなんだろ。
いまのインテルのはよくなったのかね、しばらくつかってないからｼﾗﾈ。
HPFのような分散並列の自動並列化のことを指してうまく言っていないと言うなら、その通りだな

エンコのような、どこから誰が処理しても良いデータ、ではマルチスレッドは
誰がどう見ても有効だけど、
世の中の99%以上は、それ以外の、処理順番が変えられないデータ、での
マルチスレッドの有効性に関するパラドックスは解決されつつあるのかな。
昨今のマルチコアは、この問題への解答を用意してないよね。
コア数なんてただのマーケティング戦略と、歩留まりによるコアが１つか２つ死んだ
不良品でも良品として、低グレード版で出荷できるようにするためだけのものだよね。

今のCPUはシングルスレッドでもちゃんと進化してるのかね。
いや、正確にはシステムでの性能って話なので、キャッシュに納まるミニ・プログラム、
ありていに言えばベンチマークの話をしてもしょうがないので、
まともに普通に複雑なソフトのシングルスレッド性能はあがっているのかね。
DDRxを使っている限りメインメモリのランダムアクセス性能に変化は
考えにくいのだから、システムとしての性能がどれだけ変化しているのかな。
もう１０年くらい進化が止まっているように感じるのだけれど。

DLP(データレベルの並列性)がない逐次処理系は
昔も今も変わらずシングルスレッド性能命だわな

MS-DOSの時代ならまだしもVista以降はうまいことマルチコアを活用しているよ

今でもシングルスレッドはほとんど変わっていないけど
時代の変化で１アプリだけが動作する環境なんて存在しなくなったわけで
複数起動しても性能が低下しにくいマルチコアシステムは有用だよ。

応答速度が求められたり時間管理がシビアなものはスマートフォン向けから逆輸入されたりするんじゃね

>>917
icc/gccを使ってるけど全部駄目
まともなコンパイラっていうとどういうのがあるの？

基本的な問題としてCはアドレスの偽装とかの問題があって
依存関係を静的に解析することが非常に困難
OpenMPやCilkPlusはセマンティクスを相当制限している
自動並列化が有効なのは単純なコードに限るんじゃないだろうか

>>922
アドレスの偽装ってなんだ？始めて聞いたぞ。

自動並列化はまだまだ実用的なレベルではないから、OpenMPのようなディレクティブでコンパイラに教えてあげる必要がある。自動ベクトル化はかなりの実用レベルになっている。

アポロ計画並みの国家予算と人的資源を注ぎ込んで、
さいきようのじどうへいれつかこんぱいらを開発できないもんかね。

そういうのは30年前から聞き飽きた

並列化ができるかどうかは扱うデータの種類で決定されるから
コンパイラではどうにもならないよ。というより人間にもどうにもならない。
特にゲーム。ユーザーの入力で次の状態が決まるから、並列化は絶対に無理。

人間の入力で次が決まってから並行処理すればいいんじゃね？
まったく無関係に動いてるオブジェクトなら確実に並列に処理できるぞ（実際やるかどうかは別として）

>>923
aliasingのことじゃね

>>927
そもそも並列化とは、そのまったく無関係に動いてるオブジェクトにしか使えないんだよ。
入力が決まってから、ユーザー入力に影響を受けるオブジェクト群を処理するというのは
一見、いいアイデアに見えるが、そこではデータの局所性が問題になる。
複数スレッドにデータ分割をしようとしても、ユーザー入力で動くもの、
たとえばプレイヤーに関するデータは一定のメモリに入っているわけで、
そこの値を読み書きしないと他のオブジェクトはゲームのルールを成立できないのがわかるだろう。
簡単に言えば、弾幕STGで、敵の弾とプレイヤーが多段ヒットしないように、
結局、ミューテックス的な多重書き込み禁止機構が必要になって
並列化の性能は絶対に出ない。
ゲームではシングルコアの高クロックが良いといわれるゆえんはコレだ。

>簡単に言えば、弾幕STGで、敵の弾とプレイヤーが多段ヒットしないように、
>結局、ミューテックス的な多重書き込み禁止機構が必要になって
ここよくわかんね

>>930
たとえばさー、STGでは被弾すると一定時間無敵になるギミックは
よくあるでしょ？あれがないと、被弾と同時に一瞬で全ライフがなくなって「クソゲー」化防止機構の、あれ、さ。

あの弾幕群をマルチスレッドで処理しようとするじゃない。
仮に弾が1000発動いててコア４個で４スレッドで２５０個ずつとかさ。

そのときに、プレイヤーが被弾したっていうフラグはこれらの
４つのスレッドで共有する同じアドレスのメモリにないとだめだよね。
同じメモリの変数だから、並列処理でもゲームのルールは破綻しないわけ。

では、実際に各スレッドがこのメモリを読み書きするときには、
無条件に好き勝手に好きなタイミングでアクセスすることはできないんだ。
スレッドＡはプレイヤーは被弾してないと思っても、
すでにスレッドＢでプレイヤーは被弾してるかもしれない。
このためにミューテックスていう排他制御機構、Windowsも持ってるを
使って他のスレッドとカチ合わないように処理しないといけない。

無論、これは弾幕ゲームの例でロジックの組み換えで回避できる話かも知れないけれど、
ゲームとマルチスレッドの関係について、参考になるかと。

弾幕をマルチスレッドとかそもそもそんな無駄な実装はしない
1フレームの間に逐次的にやりゃいいだけなんだから

例はなんでもいいがな
ゲームがその他のアプリと決定的に違うのは
一定の短い入力タイミングで、その次はプレイヤー本人以外には
予測不可能な状態遷移をすることであり、
並列処理はほぼ不可能なのだと理解すればいい

カプコンの石田氏はMTフレームワークで、ゲームでは難しいとされていたマルチスレッドによる並列化を実現したそうだよ。
タスクキューに放り込んで空いてるコアからどんどん処理させるタイプ。

西川善司の3Dゲームファンのための「ロスト プラネット」グラフィックス講座
http://game.watch.impress.co.jp/docs/20070131/3dlp.htm

タスクキューを使うのとGPUコマンド生成ってのは
もうずーっと前から（ロスプラなんかよりもね）行われている
現代のゲーム製作の基礎中の基礎だ。

http://game.watch.impress.co.jp/docs/20070131/3dlp12.htm
そしてこの図を見るとわかるように、同期更新と呼んでいる
処理が必ずボトルネックとなる。これを書いてるやつも理解してないようだし。

あと、紹介したお前も理解してから貼れよと。恥ずかしいやつだな

>>935
ただ、同期更新の部分をできるだけ短縮するよう、計算結果のデータコピーだけにするとか、
並列処理できる割合を増やす努力をして、全体としての時間短縮をしてるみたいだよ。

>>937
要するに俺が最初から指摘してるとおり、ゲームの根本ロジック部分は並列化不可能なんだよ。
シングルスレッドの実行性能がすべてのものを言うのだ。
その図でも同期更新部分は１コアだけで実行してるだろ。
分散させたところでスレッドの排他制御の分遅くなるだけなんだよ。
これだから情弱は。

プレステ2で性能を出すためにSPEを活用しようとしたら、どうしても処理の並列化がひつようだった、のがゲームでの並列化需要の始まりかな？
それ以来の、十年だに及ぶ長い研究の成果なんだよな？

>>938
なんか根本的に考え違いがあるようだ
たとえばシューティングで、敵がひとつだけってこともないし、風景もまた別計算なので
それらは簡単に並行処理にできる。画面右半分と左半分なんてのでも並行処理可能だ
(GPUが走査線ごととかに分けて現実にやってる）
画像以外に音もゲームでは流れるけど、画像と音だって並行処理可能だよな？

もちろん、不可能な部分がまったくないわけでもないけど、可能な部分は相当多い
というか、ゲームって並行処理できない例としてはあんまりよろしくないのでは？
単にゲーム作る側のツールが追いついてないとか、意識がそっちに行ってないだけな気がするよ

>>940
最初から読み直せよ。
お前のその程度の酷さは、ここに書き込むのは明らかに場違いじゃねーの。

最近のオンラインゲームは2コアまで使うのは多いぞ
1スレッドで処理してたのを2スレッドに分散処理するのは比較的簡単にできるのでは？

それとゲームが数年前のと比べてはるかに複雑になってるわけじゃないから
並列化できないゲームロジック部分の計算量はそれほど増えてないんじゃないのか？
5,6年前のゲームと比べて計算量が増えてないならいまどきのCPUなら楽に処理できるぞ

＞それとゲームが数年前のと比べてはるかに複雑になってるわけじゃないから

書き方が悪くて誤解されるかもしれないけど
グラフィックスはきれいになってるだけで
ゲームの内容そのものは数年前と比べて複雑になってるわけじゃないといいたい

仮にゲームの根本ロジックとやらが並列化不可能だったとして
それがどの程度の割合を占めているかって問題だよな。
並列化不可能な部分があるからシングルスレッドの性能がすべてのものを言う
なんて話では短絡的すぎるし定量的な視点が欠けている。
スパコン向けのアプリケーションにすら並列化できない部分は存在するが
当然ながら並列処理で時間短縮が望めないなんてことは無い。

CPUが高性能になってCPUパワーが不足する用途の多くが
並列処理が可能な用途ばかりになってる気がする

>>945
同意。
CPUパワーを要求するのは、ゲームばかりではない。

> 簡単に言えば、弾幕STGで、敵の弾とプレイヤーが多段ヒットしないように、
> 結局、ミューテックス的な多重書き込み禁止機構が必要になって
> 並列化の性能は絶対に出ない。

当たり判定を並列に行って結果をリダクションすりゃいいじゃん

ゲームだと出力先は画面だからね
並列処理で考えても行き着くところは...

>>922
インダクション変数とかリカレンシーでググッテご覧

リカレンシはいまいちひっとしないな。
あとはループ運搬依存とか。ヒントはこのくらいにしとく。
あとは自力で探してみて。

>>951
それは説明できるほど理解してない奴が知ったかぶりするときの逃げだってばっちゃが言ってた

>>952
ｵﾚ何一つ知ったかぶりしてないよ。
子供みたいなことかくな。

レトリック野郎の言っていることは正しい
しかしそれはベクトル化FORTRAN時代からの技術だ
ここ10数年のものではない

>>954
クロスファイルなどはまだ発展途上かもしれないが、
自動並列化の強いｺﾝﾊﾟｲﾗは結局依存解析をどこまで追いかけられるかの技術の
発展上にあるわけだから探すうえでのヒントととして、匿名掲示板に書いても差し障りの…
いや、まもう君らには色々言わないでおく。
私に得る物があまりにもない。

リカレンスだろ

>>956
それそれ。この道の人かな…ｼﾗﾈけど。
さてエビス一杯あおって不二子ちゃんの夢見ながら寝るわ。ノシ

演算パワーが有り余っていれば、高価な専用ハードなしで
安物のCMOSセンサと画像解析ソフトで視線入力とかできるかも。

演算需要は「Recognition」「Mining」「Synthesis」にあるってのは
Intelが以前から言ってることだから、受け売りのアイデアだが
ttp://news.mynavi.jp/articles/2004/02/20/idf3/index.html

OSのコンテキストスイッチがすべてのマルチスレッディングにおけるボトルネック

並列処理ってよりは、負荷分散って考え方のほうがよくね？

>>959
あれってハードウェア化したりして改善できないの？？

>>961
結局、データをゴッソリ入れ替える事だから、ハードウェアでどうこうなるもんじゃ無いよ。
ただこの先、何百、何千コアが当たり前になれば、スレッド切り替えを起こさなくても良くなるかも。

>>943
並列処理がまともに使えるのならば、
これまでではできなかった大量計算を使ったゲームができるだろ。
ポリゴン同士のコリジョン計算とかな。

>>961
i386の時代からハードウェア実装されてるよ。
ただWindowsやLinuxなどは使ってないみたいだな。

WindowsにはAPIでアフィニティマスクの指定ができて
コアごとにスレッドを固定できるけどな。



・・・そのくらい知っとけよｗ

>>962
>>964
>>965
そうなのかー。

＞WindowsにはAPIでアフィニティマスクの指定ができて
＞コアごとにスレッドを固定できるけどな。
それやるとオーバーヘッド小さくなって早くなる？？
OpenMPでできないかな･･･
排他処理ぜんぜんなくても、スレッド化したらオーバーヘッド大きすぎて遅くなる･･･
これってスレッド生成、破棄がほとんどで、コンテクスト切り替えはまた別の問題？？

>>966
理論上は。実際はほとんど変わらない。
そもそも、コンテキスト切り替えは実時間への影響はほぼないかと。
何しろコンテキスト切り替えはシングルスレッドだけでも割り込みが発生したり、
カーネルAPI呼んだら起きてるんだから。


>排他処理ぜんぜんなくても、スレッド化したらオーバーヘッド大きすぎて遅くなる･･･
↓
>これってスレッド生成、破棄がほとんどで、コンテクスト切り替えはまた別の問題？？
ということだな。
スレッド処理はレイテンシが必要な処理には向かないだろ。
スループットが欲しい処理に向く。

>>967
勉強になった！
ありがとう！

    コスパコスパ騒いでるから貧乏扱いされてんだっつの
    アム猿は反論がソース無しのしょうもない妄想しか無いお花畑広がり過ぎの池沼ｗ
    シェアも性能も消費電力も負けてる生ゴミにしがみついてるくせに脳内捏造で全部勝ってると思い込んでるマヌケぶり
    バグすら無かったことにする白痴カスｗｗｗｗｗｗｗ

http://looooooooop.blog35.fc2.com/blog-entry-889.html
http://www.youtube.com/watch?v=HvaVX5Awdvg
AMDの糞生ゴミっぷりが際立つな（失笑）ドカス信者の大法螺吹きっぷりもよく分かるクズさ
貧乏な池沼に好かれるだけあるわｗｗｗｗバグまみれｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
この糞っぷりまるでチョン並の役立たずだわｗｗｗｗｗｗｗｗ

>>966
アフィニティの設定はHTTがある場合は特に重要だな。
WindowsとLinuxでビットの並びが違うのが面倒だけど、
インテルのAPIを使えば環境変数で割り当てが可能。
コードの中に埋め込んでしまえばスレッドごとに細かい割り当てが可能になる。
ただ、アフィニティを設定するコストが意外とデカイから、
スレッドを起動するたびに設定するのは良くない。

本来はOSが各（論理）コアの性能・状態と各スレッドのビジー状況見て最適に振り分けるべきなのだが…

>>924
>アドレスの偽装ってなんだ？始めて聞いたぞ。
Cのポインタはintにキャストしたりできる
その上で演算されるともはやわけがわからなくなる
GCなんかでは大いに問題になっている

CやC++はキャスト不能な専用の配列型や参照型がないのでめんどくさい
配列もrestrictで明示的に指示しないと重なってる可能性をコンパイラが排除できないしね

>>973
そういうのは偽装と言わないし関係ない。
で偽装って何だ。

>>972
時分割切り替えにそこまでの要求は必要無いような

エイリアシングを偽装と訳するおとこのひとって・・・

あわてるな
男とは限らない
人じゃないかもしれない

>>973
そもそも、ポインタを数値型にキャストして演算するのは
Ｃの言語規約に違反してんじゃね

まあoffset_t型ってのもあるし

>>978
警告無効にするためのキャストに意味はないし、将来何が起こっても不思議じゃない

86をはじめ多様なCPUを知ってる人にとってはポインタ≠intは常識。混同する奴はレベルが低い。
型不適合の警告が出るプログラムしか書けない奴もレベルが低い。
例えば972とかのことだ。

>>981
レベルの問題じゃないな。基準に達していない。

アーキテクチャじゃなくて、C言語の理解度が低い人達がいっぱいいる（実務やってる）ってことでしょ

>>933
状態遷移が予測不可能なのと、並列化は排他関係ではないのでは。投機処理と並列処理をごっちゃにしてません？
いくらプレイヤーの入力が速くても、せいぜい数十msなのに対して、プロセッサーの処理はnsオーダーなのだから、いくらでも並列化の余地はあるがな。

可変長データを表現するためにサイズ0の配列をメンバの後尾に持つ構造体とか
WinAPIとかにもあるけどな（Cでは規格外）

>状態遷移が予測不可能なの
それだと動くもの作れないような？

>>974
ポインタ偽装でググるといくつかは出てくるよ
http://www.amazon.co.jp/%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0-SEI-SERIES%E3%83%BBA-CERT-BOOK/dp/toc/4756148239
http://www.slideshare.net/yak1ex/gc-in-c0x-4923195
一般的な用語とは言えないぽいけどね

>>978
未定義ではない（＝違反していない）

この問題を語る上では「別名」で十分

>>987
>未定義ではない（＝違反していない）

完全に違反だよ。
たまたまポインタと数値型のキャストがビット落ちを起こさない、
たまたま数値型にしたポインタを演算で処理できる、ってだけで。
ポインタを数値型にキャストした時点で、
HDDのフォーマットが開始されても文句は言えない。

基本的なことがわかってない人は、規格以前でハマるってだけでしょ