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

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

x86/RISC/CISC/スーパースカラ/VLIW/MIMD/SIMD
等について語ってもよし、

フリップフロップ回路が小さいPentium Mマンセー、
CISCなのに内部はRISCなPentium 4マンセー、
x86なのに32/64bitコンパチなOpteronマンセー、
昔々8086の時代は(以下略・・・等もよし。

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

前スレ
CPUアーキテクチャについて語れ 9
http://pc11.2ch.net/test/read.cgi/jisaku/1202913839/
（スレタイは9だが実質10））

【過去スレ】
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/　（前スレ）

自作板CPU系スレッド 現行スレ案内＆過去ログ保存サイト
http://cpu.jisakuita.net/

あーいろいろミスってるなｗ
じゃー次スレ>>1用テンプレ貼っとくか
---------以下をコピペ---------------

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

x86/RISC/CISC/スーパースカラ/VLIW/MIMD/SIMD
等について語ってもよし、

フリップフロップ回路が小さいPentium Mマンセー、
CISCなのに内部はRISCなPentium 4マンセー、
x86なのに32/64bitコンパチなOpteronマンセー、
昔々8086の時代は(以下略・・・等もよし。

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

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

【過去スレ】
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/　（スレタイは９）

自作板CPU系スレッド 現行スレ案内＆過去ログ保存サイト
http://cpu.jisakuita.net/

　　　　　　　　　　 |:| 　r─'^`┐r─'^`┐rｰ'^ﾞ┐__ r┐|:|:
　 ,r"´¨｀ﾞ}　　　　..|:| 　{ニﾆ　ｺ　7 /Tコ .7./ｺT '-' l.｣:::|:|:
　{　 { ｀)　｝ 　 ☆..|:| 　{ o ﾉ二) /./ (`.ｺ .~{ o.ﾉﾆ). :O:::|:|:
　 ヾ_`ｰy"　　　　 |:| 　|:| . ,r"´｀ﾞ､...|:|／:|:|::::::|:|::::::|:|::::::|:|:
　　　　｝ﾉ　　　　　|:| 　|:| .{　(´ }　｝:|:|::::::|:|::::::|:|::::::|:|::::::|:|:
☆　　{.(　　　　　　　　　　 ヾ_,r",,ﾉ.:::::::::::::::::::::::::::::::::::::::::::::
.　　　　　/ L_　　　　　　 　 ／｛.(~::::::::::::::::ぉ::::::::::::::::::::::::::
..／＼_ / z`__7　　　　　 ／::::::::)｝::::::::::::::::::終わった:::::::::
⌒⌒^/`ｰ-.{@　　　　／::::<'"'"'ｰz:::::::::::::::なにもかも::::::
　!＼/, -､.F|'　　　／:::::::,;''⌒ヾzﾆ^_, - ､;_;;__;;;:::::,__,:::::::::::
　`ゞ{＿且且､ .／:::::::y‐'‐""}}ヾ 〉::||ｧ::::::::::::::《ｪfｭﾋ_>:::::::
　　　　　　　／::::::::::::::｀￣￣￣￣￣￣￣￣´::::::::::::::::::::::

>CISCなのに内部はRISC
これってP6以降全部そうなんじゃなかったっけ？

全部じゃないだろ。珍しくはないが。

6502最高
ARM至高

cyrixとかriseはu-ops変換しないで
x86を実行するチップ作ってた
rise mp6とか量産されてないに等しい
出荷量だと思うが

6502は。。。
なんとパイプライン化されてて
nopならスループット1サイクルで処理できた
遠い親戚にあたる68000とは大違い

>>8
6502はパイプライン化されてないし、NOPは2サイクルだし、68000とは全く縁はない
6800とはピンコンパチに近い

6502の高速化のトリックは、
実効アドレス計算の下位8ビットのキャリーを待たずに投機的メモリアクセスをするところ
キャリーがあると1サイクル余分にかかる

どこからパイプライン化説が広まったのかは謎

Core2はなんでK8/K10とあんなに差がつくのん？

6502とARMは実際似ているところはほとんど何もないが
雰囲気みたいなものは確かに似ているな

6502 6800
ARM 88000またはMIPS
NOVA PDP11

松下、実装面積/消費電力を半減したTV向け「UniPhier」LSI
http://www.watch.impress.co.jp/av/docs/20080703/pana.htm

MIPSをアンチARMにした理由は
ストア命令のフォーマットをロード命令に合わせるために、デスティネーションレジスタからストア値を読み出すところだ
実装より審美学を優先しているところが実に非6502的だ

>>8
リア中学生のとき、今はなき月刊アスキーで見た<6502パイプライン説

6502と68000は何も共通点はないけど
6800繋がりで

http://pc11.2ch.net/test/read.cgi/unix/1214127349/l50
UNIX板　SunMicroSystems最大の字余り
このスレでx86vsSparcみたいな議論起きてる。

どっかのライターが6502はパイプラインとか雑誌に書いちゃったのが伝説の始まり

>>16
毎度の事だろ
そのスレはそのスレでほっといておけ

「Super πはCore2のキャッシュに入りきるからCore2でのπ焼きは速い」
ってよく言う人いるけど、本当にそうなんですか？

・Core2でのπ焼きが速い理由はそこなのか？
・入るならキャッシュに丸ごとプログラムを入れるものなのか？

詳しい人お願いします。

>>19
自分でBIOSからL2キャッシュを部分的に無効にしていって
タイム変化を調べろよ。

キャッシュ上だけで処理できるならそのほうが圧倒的に速いので
入るんだったら全部入れるようにするのが正義ではある

……他の処理とか抱えてたら配分とかいろいろ面倒になるっぽいけど

Freescale社の通信向けマルチコアプロセッサ、
ソフトウエア開発の面でマルチコア対応を支援
http://www.ednjapan.com/content/l_news/2008/07/u0o686000000fz4n.html

>>22
…まあBTSとかのリファレンスデザインで、最近はStarCore+MPCよりStarcore+OCTEON or XLRが増えてたからなぁ。P4はちょうどそのあたりを奪還したいのだろうか。

>>19
キャッシュに入らないアプリが殆どだからモッサリって噂も（ry

>>16
これか

> 304 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2008/07/03(木) 17:46:37
> >>284,287
> おまえら、『バカ』、だろ? なんの話してんのかわかってんのか? サル?
> x86 にこびりついてるやつってみんなそんなだと思われるぞ。
>
> で、繰り返すぞ、「技術的に同一条件で作ったら x86 は最低の ISA」。クソ。wwwww



まあ事実だろうね。SPARCアーキもたいがいだけど。

英語みたいな汚い言語が世界標準だったり
プログラミング言語でいえばPerlとかC++も汚いし。
でも、汚くなるほど使われてきたものってのはそれはすなわち実用的ってこと。

>>25
同一の物量で戦ったら日本軍勝つるみたいなもんか

同一の物量で日本軍が勝つなんてのも架空戦記だけの話だけどなw

そんなに豊かだったらそもそもあんな時期に宣戦する必要がないな

VIAと組んでnano対応のチップセットを投入すると言われていたNVIDIAすけど、
Atom向けのチップセットに参入させてもらうことと引き換えに、VIAから手を引くという
話が出てきたす。
ソースわ、Digitimes。
http://www.digitimes.com/mobos/a20080708PD208.html
　　--------------------------
　　Nvidia to possibly abandon VIA for Intel Atom
　　Monica Chen, Taipei; Joseph Tsai, DIGITIMES [Tuesday 8 July 2008]

　　　Although VIA Technologies and Nvidia entered into an alliance to cooperate in the l
　　ow-cost PC and MID markets earlier in the year, according to recent reports, Nvidia has
　　used the alliance as a bargaining chip to negotiate with Intel, demanding Intel allow Nvidia's
　　IGP chipsets to enter the Atom platform ecosystem, according to sources at PC makers.
　　　Nvidia's MCP73 IGP chipset only supports single-channel memory and offers relatively
　　low performance compared to current chipsets from both Nvidia and Intel making it a good
　　fit for the Atom platform.
　　　If Intel agrees to let Nvidia's chipset support the Atom platform, Nvidia will then terminate
　　its alliance with VIA. This could impact Taiwan-based chipset makers VIA and Silicon
　　Integrated System (SiS).
　　　Both VIA and Nvidia have refused to comment regarding the speculation.
　　--------------------------

ロードとストアが非対称なのはARMじゃなくてPAだったわ
ハズカシ

VIAがNVIDIAを買收するという話はどうなったんだろ。

NDIVIA

VIAﾆﾀﾞ

HPからのスピンオフのRidgeもPyramidもレジスタウィンドウなのに、PAは違うというのも面白い話だな

やっぱり当時でもレジスタウィンドウはだめぽという理解があったんだろうね

組み込みはまだ別として

http://japan.zdnet.com/news/hardware/story/0,2000056184,20376943,00.htm

MIT、低コストを実現する25nm半導体製造技術を開発
http://www.itmedia.co.jp/news/articles/0807/11/news026.html

らしいす

さっぱり原理がワカラン……
簡単に量産化に対応できたらニコンとかが困るんだろうか

2種類のレーザーを用いて位相を調節し干渉によってレジストを反応させるのが干渉リソグラフィ。
今回のはそのレーザーを走査させてパターンを形成する技術じゃないかね。

マスクがいらない分安くはなりそうだ。
EBのレーザー版みたいなものかと。



適当に調べただけだから真に受けるなよ！

多品種少量生産品ならかなり良さそうだけど、レーザー走査だと製造スピード
の問題が出てきそうな悪寒がするな。

POWER7に関するThe Registerのスクープす。
http://www.theregister.co.uk/2008/07/11/ibm_power7_ncsa/
　- 8-core
　- Dual Chip Module (DCM) (16-core/socket)
　- 32GFLops/core (256GFlos/chip, 512GFlos/socket)
　- 4GHz @ 45nm process
　- 2010
　- 4-socket in 2U case (64-core/node) = 2TFlos / node
　-
IBMの伝統的な表記でわ、DCMとわプロセッサと外付けL3の2-chipで"デュアルチップ"なので、
若干の誤解が含まれている可能性があるす。
また、32GFlos/coreの内訳を考えると、
　4 [GHz] x 2 [積和] x ( 2 [スカラFPU] + 2 [SIMD並列数] ) = 32 [GFlops]
またわ、
　4 [GHz] x 2 [積和] x 4 [SIMD並列数] = 32 [GFlops]
となるす。
上の構成だと POWER6 + DPサポート版AltiVec、下の構成だと256-bit幅SIMDのヘテロコアという
ことすけど、どちらなんすかね。
ちなみに最近のIBMのプレゼンでわPOWER7のコアの構成わ"Workload Accelerator"とか
"Highly Threaded Cores"と述べられているすから、どちらもあり得そうす。

なお、The RegisterのソースわNCSAが計画中の新スーパーコンピュータ、"Blue Waters"筋とのこと。
http://pc11.2ch.net/test/read.cgi/jisaku/1202913839/598
こちらも思い出して比較してみて欲しいす。
http://pc11.2ch.net/test/read.cgi/jisaku/1178140550/854

下の構成だとヘテロになるのはなんで？

>>41
POWER7わ汎用プロセッサなので、いきなりスカラFPUが無くなるとも思えないからす。

しかし、4コア飛び越えて8コアか
サイズはどのくらいなんだろ

上の少し訂正す。
　誤) いきなりスカラFPUが無くなる
　正) いきなりスカラFPUや従来型(128-bit幅)AltiVecユニット

>>43
　　-------------------
　　4コア飛び越えて8コアか
　　-------------------
IBMのロードマップでわ、POWER6+世代でシステムのコア数を2倍にすると言っているすから
4-core又は実装密度倍増わPOWER7より前で登場するす。

サイズに関してわ、POWER6搭載のp575が既に16-socket in 2Uすから、ソケット数で見ると減っているす。
チップわ巨大なのかもしれないす。

>>44
今はFPとVMXは独立して存在してるんだっけ

>>45
6+の存在忘れてたわ

>>46
　　--------------
　　今はFPとVMXは独立して存在してるんだっけ
　　--------------
ユニットわ独立すけど、issueわ共通す。ただし現行AltiVecわDPをサポートしていないすから、
今までわ関係なかったとも言えるす。

AppleがP.A. SemiのPWRficientを最低3年わ提供し続けると米国防省に確約したとのことす。
http://www.my-esm.com/showArticle.jhtml?articleID=208808582
　　----------------------
　　Apple sent a letter to the DoD saying it will assure production of the 1.8 GHz PWRficient
　　processor for three to five years, said one source who saw the letter but asked not to
　　be named. The letter suggests Apple will explore selling the designs to a third party
　　after that time.
　　----------------------

SMTを強化するならスカラFPUが4つかもしれんな

コスト無視で作製できるのだからPOWERの天下は続きそうだな。

>>50
自社のブレードサーバーでx86やCELL/B.E.と競合しているすけど。。。
http://www-03.ibm.com/systems/bladecenter/hardware/servers/index.html

DPで32GFLops/coreと書いてあるの？
SPの可能性は？

>>52
>>40にも書いた通りHPC筋のソースすからDPしか考えていない筈す。

ところでAltiVecってオペコードに余裕あんの？

粘着さんが削除依頼でスレ潰しを図っている模様す。
一旦削除を拒否されてもしつこく依頼しているすね。。。
http://qb5.2ch.net/test/read.cgi/saku/1150019106/457
　　-------------------
　　457 ：451：2008/07/11(金) 22:05:35 HOST:p34137-adsau18honb3-acca.tokyo.ocn.ne.jp
　　 >>452
　　ご返答有り難うございます。
　　再度、訂正の上で依頼します。

　　削除対象アドレス：
　　http://pc11.2ch.net/test/read.cgi/jisaku/1214999146/

　　削除理由・詳細・その他：
　　５． 掲示板・スレッドの趣旨とは違う投稿
　　自作系のCPU(INTEL/AMD/VIA)についてはそれぞれ個別スレがあり、
　　またそれ以外のゲーム機や組込機器向けなどについて、自作板で
　　論ずる必要はありません。
　　PCサロン板が適当だと思われます。
　　-------------------

8か…やっぱり、2のべき乗じゃないと美学（ｒｙ

いちいちチェックしてるオタがきもいです

富士通とSUNがSparc64 VII "Jupiter"搭載サーバーを発表したす。
http://www.theregister.co.uk/2008/07/14/sun_fujitsu_sparc64_vii/
http://journal.mycom.co.jp/news/2008/07/14/007/index.html
　　-------------------
　　SPARC64 VIIは、1CPUあたり4コア・8スレッド、最大動作周波数2.52GHzを
　　実現しており、従来機と比べ1.8倍の性能向上を実現しているほか、1コア
　　あたりの消費電力を従来の「SPARC64 VI」と比べ44%削減している。
　　-------------------
The Register記事の方でわ2.7GHz位まで出そうとのことす。

>>57
自治厨とかプロ市民とかの類わ、「権力を笠に着る」術を心得ているすから、
馬鹿にしていると足をすくわれることもあるす。
注意して監視しておいた方が良いすよ。

44%削減とはそらまたずいぶん下がったもんだね

それ数字のマジックに過ぎないっぽ。
1.8倍×(100%-44%)=100.8%
結局殆ど変わってないっス。

>>61
その計算ちょっと違って、2-core -> 4-coreで消費電力+32%増なんだと思うす。
　　132 [%] / (4[core]/2[core]) = 66 [%]
ってことで。

大原氏がMYCOMでFTF (Freescale Technology Forum) 2008のPowerPC関連の
講演をレポートしてくれているす。
http://journal.mycom.co.jp/articles/2008/07/14/ftf3/index.html
資料や報道を見てもよく判らなかった新チップ内バス"CoreNet"の詳細
わ、質問してもやっぱり非公開だった模様す。
それから年末までに公開されるPower ISA v2.06を見ると、POWER7に含まれ
る新命令わ判るらしいす。

100 - 44 = 56 だよ

ATOM
45cm
25nm
電力

「ゲハじゃすぐdat落ちするから」と自作板にのうのうと押しかけてきた分際で偉そうなゲハ厨↓age

> 59 名前： MACオタ＞57 さん [sage] 投稿日： 2008/07/14(月) 17:28:30 ID:vGLb+g+F
> >>57
> 自治厨とかプロ市民とかの類わ、「権力を笠に着る」術を心得ているすから、
> 馬鹿にしていると足をすくわれることもあるす。
> 注意して監視しておいた方が良いすよ。

Atomも省電力ってタテマエの割には電気食うもんな
今の半分くらいと思ってた＞高クロック品

>>54
6-bitのオペコードで"4"がAltiVecの演算命令す(ロードストア命令わ別扱い)。
ベクトルレジスタの数わ32個(5-bit表現)で、引数の数が異なる"VA", "VC", "VX"の命令フォーマット
それぞれに拡張オペコード領域が定義されているす。
　　・VAフォーマット (4引数またわ3引数+シフト量): 6-bit
　　・VCフォーマット (3引数): 10-bit
　　・VXフォーマット (3引数、2引数+直値, 1引数+直値, etc.): 11-bit
一番スペース的に苦しい"VA"フォーマットでも使用済わ14命令で格調の余地わ十分あるす。

アレブログ vs マキーノ

やっぱり「適切に設計されたCPU」には、つっこむよなあｗ

>>69
そのGRAPE-DRの現状に関する、ご当人の弁す。
http://grape.mtk.nao.ac.jp/~makino/articles/future_sc/note064.html#rdocsect69
　　-------------------
　　とはいえ、まあ、現時点では GRAPE-DR は1チップで実測性能で DGEMM 世界最高速を実現した
　　わけで、まあ、数千億掛けたという話もある Cell とかに比べてもピーク性能、実効性能、電力当り
　　性能のどれも高い、というところで結構悪くないものができたのではないかと思っています。
　　-------------------

DGEMMに必死になり過ぎ。なんかカッコ悪いぞ。
作る目的を間違っとる。

落穂拾い的ネタすけど、NvidiaがSOI関連企業の団体 "SOI Industry Consortium"に加盟した
とのことす。
http://www.soiconsortium.org/news-events/press-releases.php?id=11
　　------------------
　　“NVIDIA is pleased to join the SOI consortium. We are looking forward in participating
　　on the advancement of such an innovative technology and its applications to future
　　products," said John Chen, VP, Technology and Foundry Operations at NVIDIA.
　　------------------
GPUも低消費電力へ向かうということすかね。あるいわ、オンダイ超広帯域メモリとしての
フローティング・ボディ効果を利用したDRAM (Z-RAM等)が目的なのか。。。

前スレで話題にした次世代CELL B.E.の命令拡張の話題すけど、少々考えてみたす。

周知の通り、SPEの命令セットわ32-bit固定長のRISC命令の中に128個(レジスタ指定に7-bit要)の
レジスタを最大4引数指定するため、命令オペコード拡張の余地が非常に少ないす。命令コードにわ
4-bit, 7-bit, 8-bit, 9-bit, 10-bit, 11-bitの6通りのフォーマットがあるので、それぞれについて、拡張
の余地を調べると、こうなるす。
　　種別　　　　　　　　　命令数　　空き
　　4-bit Op-code　　　　6　　　　　　2
　　7-bit Op-code　　　　3　　　　　　61
　　8-bit Op-code　　　　29　　　　　35
　　9-bit Op-code　　　　17　　　　　111
　　10-bit Op-code　　　　4　　　　　244
　　11-bit Op-code　　　140　　　　　628

現ISAとの互換性を保ちつつ、専用命令で『大幅な性能向上』を得るための最も単純な解決策わ
ベクトルレジスタを連結して128個の128-bit幅VRFを256-bit幅 x 64又わ512-bit幅 x 32として
扱うことす。

この結果レジスタ指定に必要な命令フィールドわ、以下のように減少するす。
　　4引数: 28-bit -> 24-bit (256-bit幅), 20-bit (512-bit幅)
　　3引数: 21-bit -> 18-bit (256-bit幅), 15-bit (512-bit幅)
そして4-引数命令を8-bitフォーマット(256-bit幅の場合)又わ11-bitフォーマット(512-bit幅の場合)
に割り当てることが可能になるす。
>>73に書いた通り、8-bit Op-codeも4引数命令を割り当てる程度にわ空いているすから、
このやりかたわ、論理的にわ可能ということす。

的中するかどうかわ、数年後ということで。。。

http://pc.watch.impress.co.jp/docs/2008/0724/ibm.htm

今週結構ニュースわ有るす。まず新しいPowerPCデスクトップ"CherryPal C500"の話題す。
http://72.51.37.17/products/
Freescaleの車載向けヘテロ3コアPowerPC MPC5121e/400MHzを搭載して、オンラインストレージ
サービスとセットで販売するという"Cloud Computing"を現実化した製品す。
何故かiTunesが動くという謎の仕様が。。。
　　・Freescale MPC5121e mobileGT (400 MHz)
　　　http://www.freescale.co.jp/pressrelease/article.php?id=280
　　　　603e系 PowerPC e300コア
　　　　32-bit RISC マルチメディアコア (200MHz)
　　　　PowerVR MBX/VGP Liteベースのグラフィックコア
　　・256 MB DDR2 DRAM
　　・4GB NAND Flash SSD
　　・802.11b/g Wi-Fi
　　・USB 2.0 x 2
　　・10/100 Ethernet
　　・VGA DB-15
　　・約300g, 消費電力 2W

>>40の記事関連でPOWER7の仕様についての予想をITJungleのTimothy Prickett Morgan記者が行っているす。
http://www.itjungle.com/tfh/tfh072108-story02.html
　・最近IBMが提示しているロードマップ(http://www.itjungle.com/tfh/tfh072108-story02-fig01.gif) [MACオタ注: 私も数か所で見たす]
　・TheRegのPOWER7記事は、2段階で計画されているBlue Watersの建設を混同している
　・POWER6+はソケットあたり4-core以上。45nmでeDRAM L3も含むMCMか？
　・"Advanced Hybrid Core"とは、オフチップのコプロのことであろう
　・POWER7はPOWER6のL3をオンダイに統合する
　・POWER7の動作クロックは3-4GHzの間と聞いている
　・噂どおりx86とのソケット共通化を行うかもしれない
　・TRIPSのリコンフィギュラブル技術を取り入れるかもしれない
　・8-core版はPOWER7+世代の仕様で、POWER7は4-coreではないだろうか
等々

上と同じく、HPCWireのMichael Feldman記者の予想す。
http://www.hpcwire.com/blogs/25783599.html
　・POWER7でクロックがPOWER6/4.7GHzより下がる原因は、10PFlopsに対応するコア・ノード数
　増加によるによる消費電力上昇か？
　・Green500ランキングを見る限りPOWER6コアの電力効率は、Blue Geneの1/4。PowerXCellの1/5。
　・POWER7のTDPは悪くて100W。できれば50Wクラスが望ましい
　・このためコアは小規模化する筈。強化版AltiVecかCELL SPE？

Intel EP80579
http://pc.watch.impress.co.jp/docs/2008/0725/intel.htm

>>79
TDPが一桁多いな。これではARMの競争相手にはならないな。

ARMでなく、PPC,MIPS辺りのSoCが相手なんじゃ？
ルータとか向きじゃない？

＞EP80579はIXP460の、EP80579 with Intel QuickAssist Technologyは
＞IPX465のそれぞれ後継となっていると考えるのが正しいだろう。

>>81
一番IA-32が有利なのはNASあたりじゃないかな。ユーザアプリが多いし、元々x86ベースのも多い。
ネットワークアプライアンス云々のWhitePaperもあるけど、そっちだと殆どMIPS系に移植されてないのないし。
別にIAアーキテクチャがとか言われても、いまIA32採用してるアプライアンスが切り替えるにはCPUが遅すぎる。
あとアクセラレータの性能が低いよ。性能ではOCTEON+だとCN5200より下クラスなのにTDPだとCN5600やXLR716クラス。バルク暗号化処理だけなら10Gbps超えが普通にあるクラスなのに。

>>74
某ドリカスCPUの内積命令ですね
わかります

>>79
これって90nmなんだっけ？
携帯サイズのUMPCはこれの次世代で作ってくれるの？

>>84
ベクトル長わ変わっても汎用レジスタとして使用できるすから、アプリケーションを限定した
専用命令とわ、ちょっと違うと思うすけど。。。

ところで命令セット違うとCPUの回路構成も違うよな？

欧州最大級のスーパーコンピュータMareNostrumやPS3Linux関連の開発で有名なスペインの
Barcelona Supercomputing Center (BSC)が欧州版Roadrunner "MariCel"を発表したす。
http://www.bsc.es/media/1762.pdf
http://www.bsc.es/media/1764.JPG
http://www.bsc.es/media/1765.JPG
Roadrunnerと同じくIBMのCELLブレードQS22のハイブリッドクラスタすけど、制御ノードにPOWER6
ブレードを使う点が異なるす。
今回発表したプロトタイプのノード数を増やしてRoadrunnerと同じく10PFlopsクラスのスーパーコン
ピュータを建設予定とのことす。

Appleのプロセッサネタが2件す。

まずAppleブランドのPWRficientチップの写真す。
http://digitaldaily.allthingsd.com/20080728/apple-pasemi-2/
AppleとP.A. SemiがARMライセンスを取得するという噂す。
http://www.eetimes.com/news/design/showArticle.jhtml?articleID=209900392
　　-------------------------
　　LONDON ― Warren East, chief executive officer of ARM Holdings plc (Cambridge, England),
　　has declined to name the company that has taken a multiyear architecture license for ARM's
　　current and future technologies. But East gave enough clues while speaking to financial analysts
　　on Wednesday (July 30) to show clearly that Apple is a contender.
　　-------------------------
予てからの報道通り、自社の次世代携帯機器向けにARMコアのチップを開発する模様す。

iphoneがPowerになるわけじゃないのか！　絶望した！

iPod touchで遊んでたことあるけど、性能が微妙だった。
けっして悪くは無いけれど、かゆい所に手が届かない・・・的な半端さがあった。

>>90
Newtonを思い出して欲しいすけど、ARMも創成期からAppleと関わりの深い会社なので、
悲観する必要わ無いす。そう言えばデス・スパイラルと言われた時代に手持ちのARM株が
高く売れたお陰で、どれほどAppleわ救われたことか。。。
http://ja.wikipedia.org/wiki/%E3%82%A8%E3%82%A4%E3%82%B3%E3%83%BC%E3%83%B3%E3%83%BB%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF
　　--------------------------
　　アップルとエイコーンは共同でARM開発を開始し、この開発作業を別会社で行うことが決定された。
　　エイコーンでARM関連の研究開発を行っていた部門を基にして ARM（ARM Ltd）が1990年11月に
　　スピンオフされた。エイコーンとアップルはARM社の株をそれぞれ43%ずつ保有し（1996年時点）、
　　VLSIテクノロジーは同社に投資すると同時にARMのライセンスを最初に受けた。
　　--------------------------

511 名前：MACオタ＞505 さん[sage] 投稿日：2008/05/08(木) 22:37:06 ID:UrOM/xel
>>505
新しい目の技術すから、これをトンデモ説とまで言い切る勇気わ無いすけど、CELL PPEやAtomわ
FGMTに分類するのが普通かと思うす。
(略)

903 名前：MACオタ＞896-897 さん[sage] 投稿日：2008/07/19(土) 08:08:55 ID:2eUAebpx
(略)
SMTわAtomでの採用で、『サーバー向け』技術じゃ無いことわ明らかになったと思うすけど。。。
メモリコントローラ内蔵等SoC的要素わ、むしろ組込チップで先行して実装されている技術す。


SMTなのかFGMTなのかどっち？

>>92
Androidとの差別化になると思っていたのでARMな時点で終わってる。
周りがPower版iPhoneを使ってる中、俺だけnVidia＋Androidを使う妄想してたのに。

今日わ、山のようにニュースがあるす。まずわIntelがSiggraph前にLarrabeeの説明会を
開いたす。見た範囲で最もよさそうな記事わTGDailyのコレす。
http://www.tgdaily.com/content/view/38700/135/
　・LarrabeeわPC向けGPUとしてリリース
　・コアわPentiumのショートパイプラン構成を64-bitと4-thread MT拡張。
　・コア数わ8-48でスケーラブル
　・512-bit x 2 (双方向)のリングバス
　・512-bitベクトルユニット (VPU; 16 32-bit ops per clock)

一方Nvidiaのチップセットネタに関してわ、絶望的なニュースが来ているす。
http://www.theinquirer.net/gb/inquirer/news/2008/08/02/nvidia-chipsets-dead
　　--------------------------
　　Nvidia is desperately trying to deny it, but don't believe the
　　spin, the division is deader than an Nvidia mobile GPU.
　　--------------------------
モバイル向けGPUの不良問題も相当深刻な模様す。
http://www.theinquirer.net/gb/inquirer/news/2008/07/31/hp-pays-half-nvidia-problems
　　--------------------------
　　Using the high number of eight per cent and the low number of
　　$150 million, we can figure out that the the total cost of a
　　recall, again with NV paying only half, is around (100/8)*$150
　　million = $1.875 billion. Nvidia only has about $1.6 billion in
　　the bank, so this could put a crimp on the decoration at the
　　company non-denominational winter festivities party that does not
　　endorse or disclaim any particular faith, religion, or point of
　　view.
　　--------------------------
倒産の危機す。

Larrabeeについてすけど、じっくり読むならExtremeTechのこちらの記事が良いす。
http://www.extremetech.com/article2/0,2845,2327044,00.asp
　- 固定機能について
　　------------------
　　Larrabee, by contrast, only performs a single piece of the
　　graphics pipeline in a fixed function unit—the texture
　　sampling/filtering. This texture sampler operates on unaligned
　　2x2 blocks of texels and provides all the usual texture
　　operations like data fetching, decompression, anisotropic
　　filtering, and so on. It supports virtual address translation,
　　and communicates with the rest of Larrabee (the cores) by writing
　　to the cores' L2 cache.
　　------------------

　- Pentium 改良型 x86コアについて
　　------------------
　　The cores are dual issue, and the two instructions issued per
　　clock cycle can be two scalar instructions, one scalar and one
　　vector instruction or two vector instructions.
　　[中略]
　　Each core has an L1 cache consisting of 32KB of instruction cache
　　and 32KB of data cache, along with 256KB of L2 cache. The L2
　　cache of these cores, the fixed function texture units, the
　　memory controllers, and the system interface are all linked
　　together by a 1024-bit ring bus architecture (512 bits in each
　　direction).
　　------------------

　- ベクトルユニットについて
　　------------------
　　The vector unit is particularly interesting. It is what Intel
　　calls "vector complete," meaning that you don't have to fill it
　　all up with one 16-part execution kernel. Rather, you can issue
　　up to 16 individual and separate execution kernels, one per
　　vector unit lane, which should help to more fully utilize all the
　　processing power of these cores. The vector units support
　　scatter/gather, and can use mask registers as a form of
　　data-parallel flow control. Fused multiply/add for up to three
　　arguments is supported, and the units operate on 32-bit integer,
　　32-bit floating point, and 64-bit floating point data.
　　------------------

　- マルチコア対応レンダリングパイプラインについて
　　--------------------
　　PowerVR's claim to fame back then was what they called Tile Based
　　Rendering—some call it Chunking, Intel calls it Binned Rendering.
　　The full frame is broken into hundreds of square tiles, usually
　　16x16, 32x32, 64x64, or 128x128 pixels in size. The primitives
　　for each tile are processed, and their depth values sorted and
　　stored into a "Bin Set" in off-chip memory (or in other
　　architectures, a special tile buffer).
　　--------------------
　- GPGPU応用について
　　--------------------
　　By incorporating fully cache-coherent x86 cores with virtual
　　memory, page swapping, and so on, Intel expects programming
　　Larrabee to perform tasks other than 3D graphics to be much
　　easier than on competing GPUs. You can just write native C or C++
　　code and run it directly on Larrabee, which Intel calls Larrabee
　　native mode.
　　--------------------
　　CUDAもOpenCLも不要なのが売りす。x86コアなので当然IEEE数値データフォーマット
　　わ共通に使えるとのこと。

Larrabeeのリリースわ2009-2010とのことすけど、2008年中にもサンプルわ配布されるとのことす。
http://www.eweek.com/c/a/Desktops-and-Notebooks/Intel-Details-Larrabee-Processor-Architecture/
　　----------------------------
　　The first of the Larrabee chips, which are destined for the
　　high-end PCs that use discrete graphics cards, will not arrive
　　until 2009 or 2010, although Intel is expected to release samples
　　starting in late 2008.
　　----------------------------
来年初頭にわ、評価も聞こえてくる筈ということで。

無駄にぺたぺた貼るな、URLと自分のコメントだけでいいよ

>>102
　　--------------------
　　無駄にぺたぺた貼るな、
　　--------------------
既に読んで判っていると思うすけど、元記事5ページの大作なんすけど。。。

だからこそだろ

Anandわ随分Intelに優遇されていると見えるす。たっぷり資料をもらって書いた大長編の
プレビュー記事わ、こちらす。
http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3367
でも新味があるのわ、パイプラインステージ数について直接コメント貰ったところ位す
かね。。。5段のオリジナルPentium程じゃ無いけれど、16段のSilverthorneよりはるかに
「短い」とか。
　　------------------------
　　Larrabee on the other hand is more Pentium-like to begin with;
　　Intel states that Larrabee's execution pipeline is "short" and
　　followed up with us by saying that it's closer to the 5-stage
　　pipeline of the original Pentium than the 16-stage pipeline of
　　Atom.
　　------------------------

[PATCH] Add initial POWER7 support
ttp://sourceware.org/ml/binutils/2008-08/msg00016.html

[PATCH-ppc 0/5] Add feature description for new VSX register set
ttp://sourceware.org/ml/gdb-patches/2008-07/msg00452.html

>>106
これわスゴいすね。
つまりVSXという128bit x 64のレジスタをサポートする新しい命令セットを定義して、
　PPC ISA: FPRを64個に拡張
　AltiVec: VSXレジスタの上32個を流用
ということすか。

>>103
>>106を見習え

>>108
この辺のスレッドをお勧めするす。黙々と貼るだけの場所で、ここより居心地が良いと思うす(笑)
http://pc11.2ch.net/test/read.cgi/hard/1158250417/
http://pc11.2ch.net/test/read.cgi/mac/1214461149/

私わ真っ平御免すね。。。

じゃ"------------------------"やめろ
というかお前が消えればおｋ

>>110
mjsnyksg

POWER7ネタがもう一件。
TheRegisterのPOWER7スクープ (http://www.theregister.co.uk/2008/07/11/ibm_power7_ncsa/)
8-coreという点だけわ、確認が取れたす。ソースわITJungleのRoss Mauriインタビューす。
http://www.itjungle.com/tfh/tfh080408-story01.html
　　-------------------------
　　TPM: We're not worried about Power7, but we all want to known its shape and feeds and speeds.
　　　　　I am just curious because I love the technology inside chips. Can you at least confirm that
　　　　　Power7 is an eight-core chip that the chatter is going on about?

　　RM: [Laughter] Yes.

　　TPM: Yes, you can confirm, or yes, it is an eight-core chip?

　　RM: Yes, I can confirm that. But I am not going to get into the frequency and the pipeline depth
　　　　　and size of cache and some really cool other stuff that we are doing. And the reason I am
　　　　　not going to do that is because I don't want to give our competitors a head's up. We're doing
　　　　　really cool stuff in Power7, and there will be a time to talk about that.
　　-------------------------
Morgan記者に感謝するす。

うざい

>>99
用語の解説がなんにもないのではっきりしたことは言えないが、ベクトルユニットはわりと特色があるっぽいな

後藤ちんのポンチ絵を見る限りでは、L1からベクトルレジスタへのパスがないし

>>114
VPUの模式図なら、Anandtechのが良いす。
http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3367&p=4

Vector completeというのはこれだけ読むとアレか、九大ハイパースカラというやつかね

Power(笑)
ゲーム機用か
IBM製の鯖なんか要らんわ

有難いことにIntelがSiggraphのLarrabee論文をアップしてくれているす。
http://softwarecommunity.intel.com/UserFiles/en-us/File/larrabee_manycore.pdf

>>115
ご丁寧に二箇所とも間違えとるw

諸元を見てびっくりするんだろうけど、なんか保守的でガックリきた

マイクロソフトが何を血迷ったのか、XPより重いOS（VISTA）で３D画面表示
だけ重い「MACモドキなGUI」を出したので、インテル入ってるが、超巨大な
2キャッシュ（４M・６M）が無いと、動作速度が遅くなる欠陥品を世に出した。

VISTAは、XPと違い、いつも３Dカードが動作しているので、その
消費電力は馬鹿にならない。エコとは、逆のOSである。

無意味なことにCPUを食うというのはおかしい！と思う今日このごろ。

>>120
意味不明　日本語勉強し直せ

適当に流し読みして、MSがCompiz並に派手な3Dデスクトップ for Vistaを出したのかと
wktkしてしまったではないか！どうしてくれる

XPでは、プログラムをロードした後「230MB」であったので「512MB」あれば、
動作可能であり、１GBあれば快適であった。

しかし、VISTAでは、プログラムをロードした後「800MB」であったので、
「１GB」あれば動作可能であり「２G」ないと動作が重い感じがする。

つまり、VISTAにしたことにより、メモリの増設は必要になり資源の無駄
と思った今日このごろ。

まあメモリがあったらあったで
SuperFetchとかいうアホ機能がディスク中の実行ファイルを片っ端から
無駄にメモリにロードする時間が長くなるんだがな

OS重くしないとCPU売れないよ　 by intel

IDに　CPU　が出たので記念パピコ
　

WIN９５より前の使えないOS

>Windows3.1では、プログラムをロードした後「4MB」であったので「8MB」あれば、
>動作可能であり、16MBあれば快適であった。

WIN９８系から、NT系になり堅牢な設計と格段に進化
>しかし、XPでは、プログラムをロードした後「230MB」であったので、
>「512MB」あれば動作可能であり「1G」ないと動作が重い感じがする。

XPと同じ基本設計
>しかし、VISTAでは、プログラムをロードした後「800MB」であったので、
>「１GB」あれば動作可能であり「２G」ないと動作が重い感じがする。

さほど意味の無いことにマシンパワーを食うというのは如何なものかと思います。

>>120
MAＣオタ共々巣に帰れ

ゲハ厨はしつこいのだけが取り柄ですから無理ですね。

Larrabeeすけど、牧野教授がこんなこと書いているす。
http://grape.mtk.nao.ac.jp/~makino/journal/journal-2008-08.html#4
　　-------------------
　　16-way SIMD で512 bit-wide なレジスタファイルにするならやはりポート数は減らすわけで、falu は
　　FMAにして 1R1W とかかなあ？ 16-wide で vector permute 命令なんてやってられないわけで。
　　-------------------
思うにLarrabeeわ8-bitや16-bit整数を強制的に符号拡張してレジスタにロードする機構が備わっている
("Numeric Convert"ユニット)すから、vector permuteの粒度わ常に32-bitす。8-bit x 16をサポートする
permuteユニットと32-bit x 16をサポートするpermuteユニットって、それほど規模わ変わらないんじゃ
無いすかね？

>>129
引き続きLarrabeeの話すけど、>>118の論文を読んでゆっくり考えてみたす。
結局Larrabeeわ、CELL/BEとNiagaraを詳細に研究して良いとこ取りを狙ったモノに見えるす。
ただ結果として仕様を盛りこみ過ぎているような感じが拭えないす。設計上の妥協って各コアの
クロックが比較的低い(論文中の例で1GHz)ところ位じゃないすか？

何となく、下記のような展開が裏にあるような気がしてきたすけど、どうなんすかね。。。

　　　良いとこ取りの全部入りで設計
　-> 結果的に消費電力大、スケーラビリティの限界も常識的範囲
　-> GPUだと競合他社も爆熱だし、典型的にTLPが保障された計算対象だな。
　-> じゃGPUで売り出そう

>>129
Larabeeのベクトルレジスタファイルは4R1Wの5ポートに見えるし、
上のどれかの資料に3ソースオペランド命令だと書いてあったので、
FALUはFMAだと思う

permuteユニットは配線の都合上、8bit->32bit単純に規模は4倍というわけにはいかない

ひょっとしたら上の二つは倍クロックで動かす、なんてこともありうるかもしれない

一方CELL/BEで経験を積んだIBMの方わ。。。というと>>106のVSXレジスタの仕様わ、明らかに
CELL SPEの統合レジスタを取り入れたモノす。
タイミングが最も重要なユニットを上手にケチることで、性能と低消費電力を両立させる模様す。
FPとベクトルのアーキテクチャレジスタを一気に2倍の64個にした。。。というのもCELL/BE、POWER6
とインオーダー型高性能プロセッサを設計した経験が生かされている模様す。

流石にCELL SPEと違って整数レジスタまで統合しなかったのも、何らかの反省が含まれているすかね。

昔の後藤記事でCPU以上の高クロックになるとか書いてあったけど
実際は1GHz程度なの？

>>131
　　--------------------
　　permuteユニットは配線の都合上、8bit->32bit単純に規模は4倍というわけにはいかない
　　--------------------
512-bit幅のレジスタを8bit x 64としてvector permuteするのに比べると、桁違いに単純にわ
なる。。。というだけの話す。
初代AltiVec搭載のPowerPC 7400わ220nmプロセスで登場したことを考えると、特に大きな
問題わ無いように見えるす。

>>133
1GHzが本当かどうかわ別にして、ショートパイプラインを謳っているすから、クロックが高くないのわ
確定す。

>>134
permuteユニットはクロスバースイッチみたいなものだと思っておけばいい

8bit x 64のpermuteと、32bit x 16のpermuteでは、
どちらにしても512bit x 512bitのスイッチが必要で、配線もあわせるとかなりでかい

スイッチの制御は6bitのデコーダー64個と、4bitのデコーダー16個の違いしかない

けっきょく規模は、8bit x 16 <<< 32bit x 16 < 8bit x 64といったところ

>>136
指数的なレベルで計算間違っていると思うすけど。。。

>>137
どこが？

>>136はちょっと微妙かなぁ。6bitの制御シグナルを64セット供給する
のって結構大変だと思うぞ。

「512bit x 512bit」は配線についてのみ言えば正しいが、配線ネックだろ
うから、まあ、いいか。

>>139
> >>136はちょっと微妙かなぁ。6bitの制御シグナルを64セット供給する
> のって結構大変だと思うぞ。

わしもそう思う

> 「512bit x 512bit」は配線についてのみ言えば正しいが、配線ネックだろ
> うから、まあ、いいか。

permuteユニットの場合は8bitや32bit単位のスイッチングをすればいいわけだけど、
ロジック自体はたぶんデータ1bitと制御1bitのANDを取っているだけだから、
規模ではあまり考えなくていいんじゃないかと思う

おおむね、8bit x 64と32bit x 16のpermuteユニットは、規模では2〜4倍くらいの違いじゃないかと思う

>>138
　　-------
　　どこが？
　　-------
x 512っていうのわ、各ビットの転送先が512通りあるから成り立つ話す。
permuteユニットの場合、16-way SIMDなら各ビットの転送先わ16通りしか無い(MSBなら各データの
MSBに向けてしかコピーされない)ことに注意すべきす。

もちろんpermuteユニットの回路規模の話わ>>139さんが書いているように配線がネックす。

>>141
ああ、いちゃもんつけるだけつけといて、後で他人の褌でなんとやらというやつか

それよりも重大な抜け落ちがあるんだけど気付かなかったようだね

>>142
最初の3行で桁違いな勘違いをしているヒトの文章を精読しろと要求するすか(笑)

>>143
>>137の時点で>>142の指摘をしろです

で、>>136にはうっかり重大な抜け落ちがあるんだけど、キミにわかるかい？

>>144
>>137の時点で>>141の指摘をしろです、だ

>>145
確かに勿体をつけるのわ、私の流儀じゃ無かったす。その点わ失礼したす。

「私の流儀」って・・・
ここは邪気眼スレじゃねーぞｗｗ

IntelやTSMCが好調な反面、ボリュームが出ない半導体製造企業わ色々とヤバそうす。
IBMの半導体部門も、先日のリストラに加えて10%の賃下げとか。。。
http://www.recordonline.com/apps/pbcs.dll/article?AID=/20080806/BIZ/80806024
　　-------------------------
　　ARMONK ― One month after signing a job retention deal with New York, IBM said today it
　　will cut the pay of 3,500 workers at their East Fishkill, Poughkeepsie and Vermont operations.
　　-------------------------

周知のニュースとわ思うすけど、Nvidiaが乏しい資金をはたいてTransmetaからLong Runのライセンス
を受けたとのことす。
http://pc.watch.impress.co.jp/docs/2008/0807/transmeta.htm
Larrabee登場までにGPUの電力効率改善が果たせるか、楽しみな話す。

Tegra等の携帯機器向けプロセッサのためだよ
いちゃもんつけられる前にあぶく銭渡しとく

Qosmio G50新兵器、SpursEngineがスゴすぎる件
http://ascii.jp/elem/000/000/157/157525/

>151
コストその他問題もあるんだろうけど、どうせならcellをちゃんと積んでほしかった

cellの応用はソニーが一番旺盛だったのに実際にやったのはIBMと東芝だなんてw

>>141
バイトごとのデータパスがたて並びだとして、横方向の配線が何本必要か
考えてごらんよ。
>>149
2500Mかぁ、トラメタの技術は微妙だけど、これぐらいのお小遣い程度の
金額だったら安心料としていいかもね。

>>126
次期OSはCPUの64bit化や8コア、16コア、グラボのSLI推進のため相当重いOSが来るぞ。

Windowsがアホみたいに重いのを延々と続けるつもりなら、モバイル系はLinuxに全部明け渡してくれや

http://www.geocities.jp/andosprocinfo/wadai08/20080809.htm

>>152
というか、パソコンの画面サイズで必要な機能（アップコンバート、etc）を
実現するのに、必要充分な数にしただけって事でしょ。

３Dゲーム用にはこのエンジンを使ってないみたいだし。

安藤さんいろいろ勘違いしてるぽいな

>>144
スイッチマトリックスからの出力をまとめるのに64入力のORが必要で
これが512本あるからリソース的にはおそらくクリティカルなんだが、その見積もりをしていなかった
昭和生まれのおにいちゃんはこういうマトリックスを見るとついワイヤードORと決めてかかるんだよね

制御シグナルは4096本で多いと言えば多いが、
データパスとは干渉しないからあんまりクリティカルではないと思う


というわけでMACオタ先生のツッコミが頂けなくて残念です

8ビット×256くらいあればAESのS-Box 1段がハード実装できます。

>>157
やっぱり所詮SPARCアーキ以外の知識は凡人クラスか

関係ないけど後藤の記事のスクラップで論文もどきでっち上げるトンデモ大学発見↓
http://mikilab.doshisha.ac.jp/dia/research/report/2008/1212/001/report20081212001.html

大学のレベルから考えれば卒論はそんなもんでしょ。
論文書いた子は知的照明グループに入ってるようだけど、多分何もできなくて、
しょうがないから適当にでっち上げた代物で卒業させてあげたんでしょ。

と、瞬間的にここまで思ったけど5月10日じゃそんなはずはないわなぁ。
こんなもん論文のくくりに入れたらいかんね。輪講資料未満。

これ論文じゃなくてまわりもちで書いてるレポートじゃないの。

http://cetus.sakura.ne.jp/softlab/software/spibench/jpgbench.html
http://image.blog.livedoor.jp/blv42/imgs/6/d/6d2f1720.jpg

どんなレポートなのかは↓ここに書いてある気がする

http://mikilab.doshisha.ac.jp/dia/research/report/report_sample/report20040407099.html

とりあえず>>164は同志社大学の学生さんにあやまったほうがいいな（笑

去年のSIGGRAPHで発表された、CELL/BE + RSXのグラフィックワークステーション"BCU-100"
すけど、SIGGRAPH2008でTerra softがYDLでサポートすることを発表したす。
http://www.terrasoftsolutions.com/news/2008/2008-08-12.shtml
　　---------------------------
　　Over the course of the past year, Terra Soft worked closely with
　　Sony to develop a version of the Yellow Dog Linux operating system
　　specifically for the Sony BCU-100. This board support package (BSP)
　　provides end users with a best-of-class, high performance Linux
　　OS that seamlessly blends ease of installation with the Cell/B.E.
　　SDK with full 3D support for the on-board RSX GPU.
　　---------------------------
これでハイパーバイザの壁さえ破れば、RSXの使い方自体わPS3 Linuxにも流用可能
ということかと思われるす。
参考までに去年のリリースすも書いておくす。
http://news.sel.sony.com/en/press_room/b2b/broadcast_production/display_systems/release/31008.html

いいかげんにしろや、ぼけ！

アーキテクチャ業界もネタ切れか
ISCAも地味な論文ばっかりだ

ReadWorldTech掲示板でTheINQのCharlie "Groo" Demerjianがx86デコードのオーバーヘッドについて
IntelのPat Gelsingerから聞いたという話を開陳しているす。
http://www.realworldtech.com/forums/index.cfm?action=detail&id=92556&threadid=92525&roomid=2
　　---------------------
　　I directly asked Pat Gelsinger what the decode overhead was for similar performance on x86 vs
　　ARM about 2 years ago. He said, in many uncertain terms, that it was within the range of 0-50%
　　power use, basically you take a 25% extra power hit.
　　The way it was worded was roughly "at 200%, it wouldn't be worth it, 150%, it would be tough,
　　100% perfect, and we think we can do it."

　　It sounded like they did some very extensive modeling of the power costs, and that lead them to
　　dump the ARM division. :) You will recall that they had a very good ARM division a few years ago,
　　so they knew exactly what it would take to compete.
　　---------------------
25-50%の電力効率の不利をIntelの技術でなんとかする。。。ということの様す。

IBMのハイエンドPOWER6サーバー、Power595のレッドブックが公開されたす。
http://www.redbooks.ibm.com/redpapers/pdfs/redp4440.pdf
文中でわPOWER6のパッケージわMCMと表記しているものの、Figure 2-30にあるようにプロセッサ
のダイわ一つで残りわL3キャッシュす。POWER4/POWER5のような大規模MCM
(http://journal.mycom.co.jp/news/2006/07/26/342.html)とわ大違いの廉価版をUNIXサーバーの
ハイエンドに持ってきた。。。ということになるす。
ローエンドのL3外付けチップわ別にして、ミドル以上で部品共通化を図っているすね。

ついでに見つけたPower 595の内部写真す。
http://server.ccw.com.cn/jssc/htm2008/20080416_408358.shtml

>>169の1U Cell/B.E.サーバー、BCU-100のムービー付プレスリリースす。
http://www.sony.co.jp/SonyInfo/News/Press/200808/08-095/index.html
　　----------------------
　　“ZEGO” コンピューティングユニット『BCU-100』の特長
　　　（1）高 速 処 理 化：
　　　　　・Cell/B.E.による230GFLOPSの高速処理と、RSX?による高速グラフィックス処理を実現。
　　　　　・高速メモリーXDR^(TM)のオンボード搭載。
　　（2）小型化：19インチラックの1U（ユニット）に収まるサイズで、省スペース化を実現。
　　（3）低消費電力化：高い演算性能を有しながら、消費電力330Ｗ以下を実現。
　　----------------------

ムービーの方を見ると、搭載されているXDRわ10個でECC付1GBということになるす。
参考画像わ同じくプロセッサあたり1GBのECC XDRを搭載したCELLブレード、BladeCenter QS21す。
http://content.zdnet.com/2347-9595_22-20212-20213.html?seq=1

ソニーの道楽か知らんが今更誰が買うの、これ。

もう1チップ化したのか
早いな

MACオタ、貼り方気をつけろって言ってんだろ
いい加減学習するか、どっかいけよ

東京天文台の牧野教授が、このリリースにいたく感銘を受けたらしく、『スーパーコンピューティングの
将来』を更新しているす。
eASIC社のリリース: http://www.easic.com/index.php?p=releasdetail&IdReleas=187
http://grape.mtk.nao.ac.jp/~makino/articles/future_sc/note066.html
　　-----------------------
　　フルカスタムのチップに比べると、面積効率では 5-8倍程度悪いことになります。消費電力への
　　インパクトが同じ程度だと結構大変ですが、そこがそれほど大きくなければ初期コストの違いの
　　ほうが開発プロジェクトにははるかに重要です。例えば GRAPE-6 程度に完全に専用化した
　　プロセッサを開発することも現実的な話になるわけです。机上の計算では GRAPE-6 チップに
　　比べると 10-15倍程度の回路規模になるので、動作クロックが5倍とすれば性能は 50-70倍で、
　　1.5-2 Tflops 程度です。消費電力は GPU のように 300W とかいうことはないわけですから、
　　かなり競争力があるものになります。
　　-----------------------
この手の製品やファウンダリ企業の技術革新で、アーキテクチャ勝負のファブレス企業が現れて
来るのわ楽しみなことだと思われるす。

>177
まだみたいだけど

>>165
そうは思ったんだけど、同じ研究室でちゃんと自分でやった
実験結果書いて綺麗にまとめてる学生もいるんだよね。
某ＨＧの母校（笑）だけに一目置いてたが、こうも取り組み方の違いって出るもんだな。


#いや、今更Cellは無いだろ。。。

>>181
　　---------------
　　#いや、今更Cellは無いだろ。。。
　　---------------
相変わらず視野が狭いすね(笑)
LarrabeeもCELL/B.E.向けコードを参考にして、真面目にキャッシュ制御命令を駆使しないと
悲惨なスケーラビリティになるすよ。

MFCによるDMA（笑）をどう参考にするの？
あれそもそもキャッシュじゃないじゃん。

そもそも、Cellに続いてLS採用したマルチコアなんて一つでもあったっけ？

>>183
　　--------------
　　MFCによるDMA（笑）をどう参考にするの？
　　--------------
設計段階でメモリブロックごとに、何をキャッシュに残し、何をストリーミングアクセスするか細かく
設定する手間わMFCプログラミングと変わらないす。

え？
それひょっとしてPentium ＩＩＩ時代からあるプリフェッチとノンテンポラルストアの話のこといってるの？
明示的コヒーレント制御とまったく関係ないんすけど。。。

>設定する手間わMFCプログラミングと変わらないす。

全然的外れ。
たとえばメインメモリからオンダイSRAMに先行ロードするにしても
prefetch*とspu_dmaじゃ全然勝手が違う。


プログラム側から見て常に仮想メモリを操作するアーキテクチャ（IAなど）
でのキャッシュコヒーレントを明示的にコントロールするために、

そもそもメモリ空間が独立だからコヒーレント制御しなくていい変態
アーキテクチャでのコーディングをどう参考になるのかって聞いたんですけど
話を逸らさないでいただきたいですな。
潰しが利かないテクニックなんて覚えてもしょうがないんですが。

Larrabee論文の共著者でもあるPat Hanrahan教授の研究室がCELL/B.E.に関してどういう仕事を
しているか調べてみることをお勧めするす。

Sequoia。。。

相変わらずプログラミングのに首突っ込むと話をそらすことしかできなくなるMACｦﾀｗ

たとえば
複数のコアでメインメモリ上からキャッシュ上にLUTをロードするとする。

キャッシュ型アーキテクチャ（要するにCell以外のすべて）は、
複数のスレッドで同じメモリ空間をロードすれば、MESIでいうところの「Shared」になる。
パフォーマンス低下を防ぐなら、必要な分だけコピーを作って別々のアドレス空間に
割り付けておく必要がある。
あるいはLarrabeeはそのへんの制御を明示的に抑制できるんかな？

SPUは自動的なコヒーレント制御はしないからそもそも小細工しなくていい。
むしろSPUがネイティブにリニアアドレッシングできるメモリ空間が狭いなど、別のところで面倒。
うん、全然求められるスキルが違うな。

>>188
　　-------------------
　　あるいはLarrabeeはそのへんの制御を明示的に抑制できるんかな？
　　-------------------
アドレスの属性を制御するのか？64-bitアドレシングを生かしてL2の一部を別のメモリ空間に
割り当てるのか。。。
　　-------------------
　　全然求められるスキルが違うな。
　　-------------------
スキル=人力コンパイラとしか考えられないすか(笑)

命令間のレイテンシ隠蔽のための方策も全然違う。
4Wayのマルチスレッドによりプログラム側から見たレイテンシを小さくしたのがLarrabee
片ややたら多いレジスタを駆使して同じ命令を並べるだけ（LSいくらあっても足りない）

何より未だにCellSDKのコンパイラがウンコなのはみんなわかってるって。

>>190
　　---------------
　　命令間のレイテンシ隠蔽のための方策も全然違う。
　　4Wayのマルチスレッドによりプログラム側から見たレイテンシを小さくしたのがLarrabee
　　---------------
4-wayマルチスレッドわロード・ストアの隠蔽だと思われるす。
ショートパイプラインが売り(多分クロックわ低め)すから、命令レイテンシわ隠蔽するまでもなく
小さいんじゃないすかね。
レジスタわ少なそうすから、後続命令への演算結果のフォワーディングがCell/B.E.より重要になるし。。。

>ショートパイプラインが売り(多分クロックわ低め)すから、命令レイテンシわ隠蔽するまでもなく
>小さいんじゃないすかね。

あらら、お気の毒様
浮動小数演算のレイテンシがどんだけ大きいか考えたことないのね。
x86でもそんな変わらんのよ。

まあCellのは特に大きいほうだと思うけど。


ｘ86の場合はレジスタ多くないからインオーダパイプラインで隠蔽しきれるレベルじゃないね。
加算や乗算で3クロックとか5クロックとかかかってたら8本ないし16本の論理SIMDレジスタで
どうインターリーブするか頭を悩ませることになる
が、見た目のレイテンシが1/4になるなら圧倒的に楽になる。

>>188
> パフォーマンス低下を防ぐなら、必要な分だけコピーを作って別々のアドレス空間に
> 割り付けておく必要がある。

LUTなら読み出し専用だろ？
Sharedになっても性能落ちないよ

更新もされるテーブルなら、性能低下は仕方ない
Cellだと…ちょっと考えたくないな、集中管理したほうがマシだろうな

>>193
まあ書き込み前提のテーブルならまた別の意味で設計を変える必要があるけどなー

あと、資料を読み間違ってなければLarrabeeのキャッシュって、L2は全体で
共有するので、遠い部分はリングバス経由でアクセスすることになると思ってるんだが
そーなるとなるべくリングバス使わないほうが速いよな？

キャッシュ容量少ないので、各L2断片ごとに置いて4コア16スレッドで共用するのが理想か。
いずれにしてもccNUMAみたいな最適化が必要になる。

LarrabeeにもおそらくmovntdqaみたいなL1をバイパスしてロードする命令が
あると思うんだが

もっかい読み直した。1コア4スレッドあたりで256KBか。
ここ訂正しとく

> 4コア16スレッドで共用
→1コア4スレッドで共用

>>192
　　---------------------
　　浮動小数演算のレイテンシがどんだけ大きいか考えたことないのね。
　　---------------------
まさか除算を愚直に行うコードでも書いているすか(笑)
仮にオリジナルのPentium Classicと同じだとするとパイプライン段数わ+2す。
ftp://download.intel.com/design/PentiumII/manuals/24281603.PDF (page 2-4参照)

>>192すけど、上の突っ込み以前の問題として
　　-------------------
　　が、見た目のレイテンシが1/4になるなら圧倒的に楽になる。
　　-------------------
これ大間違いのような気がするすけど。アンコアのレイテンシわ隠蔽されてもパイプライン内の
レイテンシをMTで隠蔽するのわ無理でわ？

はい？
4クロックサイクルでローテーションするならどう考えてもレイテンシは大幅に隠蔽できるぞ
もちろんスレッドごとにレジスタファイルを用意する（AtomでもそうやってるしたしかCellのPPEも）


たとえばこんなコードをインオーダで実行すると

addps xmm3, xmm4
subps xmm3, xmm2 ←addpsは3クロックのレイテンシだから、あと2クロック待たないといけない。

しかし4スレッドでインターリーブすれば、順番回ってきたときにはレイテンシ埋まってる。
積和算で8クロックのレイテンシと仮定しても、1スレッドあたりでは2並列のインターリーブで事足りる。
はい、馬鹿でもわかる解説終わり。

えーと、それとも頭が悪いようで？

断っておくと俺の言ってる命令間のレイテンシってのはデスティネーションに指定したレジスタが
後続の命令でソースとして再利用可能になるまでのクロック数のことだよ。
Intelは整数は伝統的に基本1クロックで済むようにしてるが浮動小数はどんなアーキテクチャでも長い。

威勢よかったのに返答が無いのは、Google先生に教えてもらってる最中なのか逃げたのかどっちなんだよ

おーい、まだー？
ひまー（笑）


> アンコアのレイテンシわ隠蔽されてもパイプライン内の
> レイテンシをMTで隠蔽するのわ無理でわ？

この謎の発言の真相はこうかな
「スレッドの実行が切り替わるタイミングわ、Itaniumのようにキャッシュミスしたときだけす（笑）」

→そんなんで4スレッドも用意する必要ないだろ

FGMTと考えるのが自然だし、いつぞの資料のL1がレイテンシ1（←！）, L2が10っていう怪しい数字も、
4で割った値とすれば辻褄が合うんだが


あとClassic Pentiumまでは必ずしもパイプラインの1ステージ＝1クロックではなかったな。
それに当時は平均命令長も短かったし。
2GHz前後で動作し3〜4オペランドのSIMD命令を等速で実行となれば、パイプラインに大幅に手は入るだろう。
Cellもふた開けてみるまでパイプライン何十段もあるなんて思わんかったしな

AtomがFGMTとか言ってるオタさんはそこら辺よくわかってません。

はしゃいでるところを申し分けないが、
Larabeeのコアのスレッドわソフトウェアで切り替えす

> Switching threads covers cases where the compiler is unable to schedule code without stalls.
> Switching threads also covers part of the latency to load from the L2 cache to the L1 cache,
> for those cases when data cannot be prefetched into the L1 cache in advance.
> Cache use is more effective when multiple threads running on the same core use the same dataset,
> e.g. rendering triangles to the same tile.

あとL1をスルーしてデータを取ってくる命令はないみたい。
読みこんだL1を次のパージの候補にする命令はある。

おまけに、ベクトルレジスタはどうもスレッド間で共有するような雰囲気があるぞ。

>>198
　　----------------
　　しかし4スレッドでインターリーブすれば、順番回ってきたときにはレイテンシ埋まってる。
　　----------------
それパイプライン化された命令限定す。
長レイテンシの命令を隠蔽するんじゃ無かったすか？加減算だけなら浮動小数点でもシングルサイクル
で終わるかと思うす。
>>199
　　----------------
　　デスティネーションに指定したレジスタが後続の命令でソースとして再利用可能になる
　　----------------
レジスタのリード・ライトに関係無く、フォワーディングネットワーク経由で利用可能になると思われるす。

上のがインテルの論文のやつ

ほかの記事に、コンパイラがストールしそうなところにスレッド切り替え命令を挿入すると書いてあったよ

>>203
ソフトウェアでってのがよくわかめ。
スレッド自身で他のスレッドに切り替えるの？

つーかURLplz

>>204
> 長レイテンシの命令を隠蔽するんじゃ無かったすか？加減算だけなら浮動小数点でもシングルサイクル
> で終わるかと思うす。

バロスｗｗｗｗｗｗ
スループット１をレイテンシ１だと思ってますなｗｗｗｗｗ

>>206
http://softwarecommunity.intel.com/UserFiles/en-us/File/larrabee_manycore.pdf

> スレッド自身で他のスレッドに切り替えるの？

そそ

>>201
　　--------------------
　　この謎の発言の真相はこうかな
　　--------------------
何を思いついて嬉しがっているのか良く分からないすけど、除算や平方根のようなFPの長レイテンシ
命令わ、内部で回帰計算を行う必要があるす。
特別にパイプライン化でもできない限り、MTで実効レイテンシが埋められるとも思えないすけど。。。

>>209
△除算や平方根のようなFPの長レイテンシ命令わ
○除算や平方根のような低スループット命令は

スループットサイクルとレイテンシサイクルを混同してる子と話をするのは無理だと思うんだが

>>208
てかおもっきしダウンロード済みのpdfだった
思うにFGMTと併用できない技術でもないんだが、逆に明示的なスレッド切り替えだけでしか
スイッチしないとか書いてある箇所ある？

>>211
> 思うにFGMTと併用できない技術でもないんだが、逆に明示的なスレッド切り替えだけでしか
> スイッチしないとか書いてある箇所ある？

ない
けどFGMT動作はナンセンスだと思うよ
FGMTでは平均的なレイテンシ削減にはなるけど、がっつりスケジューリングするには不向き

>>207
　　------------------
　　スループット１をレイテンシ１だと思ってますなｗｗｗｗｗ
　　------------------
古いコアデザインが回帰しているということで、PowerPC G4あたりのマニュアルでもどうぞ。
FMAをやるから加算のみでも1を乗ずる分余計にサイクルがかかるだけで、シングルステージ
で加算を行うす。
http://www.freescale.com/files/32bit/doc/ref_manual/MPC7410UM.pdf (Figure 6-3参照)
ところで、これのソースがあるならお願いするす。
>>201
　　------------------
　　あとClassic Pentiumまでは必ずしもパイプラインの1ステージ＝1クロックではなかったな。
　　------------------

>>210
　　-----------------
　　○除算や平方根のような低スループット命令は
　　-----------------
ベクトルデータを対象とするなら、パイプライン版除算ライブラリわ存在するすけど。。。　　

ソフトウェアパイプライン版除算の例す。
http://www.cs.ualberta.ca/~amaral/cascon/CDP05/slides/CDP05-enenkel.pdf

>>213
Pentiumは知らんのだが、80486のようにfully pipelinedでないものは、たとえばデコードステージに複数クロックかかる場合もある

>>214
痛々しいからこれ以上恥の上塗りをするのはやめて

>>213
それ、クロックレンジまでおもっきし回帰するんだが。
FP積和で4clkは流石だったがパイプライン段数を11段に増やした7450ですら
2GHzすら越えた実績がない。

Intelに限ればATOMでも単精度命令のレイテンシは3以上。

>>216 さん
　　---------------------
　　Pentiumは知らんのだが、80486のようにfully pipelinedでないものは、たとえばデコード
　　ステージに複数クロックかかる場合もある
　　---------------------
論理回路と模式図を同一視するのわ間違いす。CISCわ、そもそも命令をシングルサイクルで
実行するという考えじゃ無いす。

>>217 団子 さん
Silverthorneわ十分ロングパイプラインに分類されるコアかと。
それからe600系が2GHzの製品が無いのわ、デスクトッププロセッサ市場から撤退したという
理由だけす。

加減算後の正規化に最低でも1サイクル掛かるらしい

>>219
正規化無しに後続の依存命令へ結果をフォワードすることわ可能だと思うす。

レイテンシ1で？
どんなアーキテクチャだよ。

そもそもP5とP6パイプの段数の差の大部分はデコードやスケジューリングであって
Executeステージの深さは10年前から変わってない。

妄想甚だしい。

これまでのところダンゴ苦戦中っス

浮動小数命令をレイテンシ1でこなしてたアーキテクチャを示せよ。
低能マコの指摘するPentiumですらfaddで3。

「1サイクル」の意味をレイテンシのことだと勘違いしてたとしか思えんし
認めればこれ以上恥の上塗りにならねーぞ

>>223
　　--------------------
　　浮動小数命令をレイテンシ1でこなしてたアーキテクチャを示せよ。
　　--------------------
勝手に誤解して逆切れされても困るす(笑)

ところで>>213でお願いした『1ステージ＝1クロックではなかったな』のソースわ？

ああIEEE754非準拠ならいけるなんてのは論外な。
7450はvfaddもvfmaddもレイテンシ4。G5では8

日本語の「Intelアーキテクチャ最適化リファレンスマニュアル」にPen1〜Pen3まで載ってるが。

プリフィクスバイト食わせると必ずストールするし(笑)

これまでのところダンゴは煽り過ぎ、もっと落ち着いて恥ずかしくない発言を望むっス♪
そもそもこの手の論争は煽った側の負けっぽですよ。

黙れ透明あぼーん

>>226
段々と後付の言い訳が出てきたすね。検索してFP命令を持つDSPでも見つけた様すね(笑)
　　------------------
　　プリフィクスバイト食わせると必ずストールするし(笑)
　　------------------
これも苦しすぎるのでわ。。。

無理だしナンセンス

>>230
>>220

ちなみにAMD次世代22の#408に貼ったia32_opt.pdfそのものなんだが、
どういう発想で、より高クロックのLarrabeeでFPの加減算がレイテンシ1で済む
なんて妄想に至ったのか理解に苦しむな

1サイクルで浮動小数点加算をするマシンの話は読んだ覚えがあるけどな

ラッチをケチったんだと

トランジスタ世代だがな

団子前より太ったな
運動もしろよ
特に大腿部の筋力が弱ってると血液が下半身に溜まって脳に行かなくなるからな

つかP5のfadd/fsub/fmulはレイテンシっていうよりスループットクロックを含め消費クロックが3だ。
fxchで並列化・パイプライン化なんてテクニックはPProからだし。

1TFを叩き出すパイプラインの構造はPPro以降のそれからの逆輸入だろう。
P5に倣ってるのは非対称のパイプラインくらいだろ。

>>232
　　------------------
　　どういう発想で、より高クロックのLarrabeeでFPの加減算がレイテンシ1で済む
　　なんて妄想に至ったのか理解に苦しむな
　　------------------
誹謗も百回言えば信じてもらえて大勝利と(笑)
しかし将来引用されるのわ>>190-192な訳すけど。。。

もちろんLarrabeeのマイクロアーキテクチャがより明確になった段階で、的中している可能性もある
すから楽しみにすると良いかと思うす。

お前の妄言そこら中に貼ってやるだろうな。まあ気にしないんだろうけど。
マコタみたいな恥がない奴って最強だな。
IA32でFP加減算・乗算を3クロック未満のレイテンシでこなせたものは
未だかつて「ない」。

>>237
　　----------------
　　IA32で。。。
　　----------------
また言い訳追加。。。と(笑)

バカ丸出しだな


LarrabeeがIA以外の何だっての？
Pentiumの応用であることを根拠にFP演算は低レイテンシだと言ってみたり

そのPentiumが1クロックサイクルでFP演算をこなせないことを指摘したら話題そらしか。
厚顔無恥ってうらやましいよｗｗｗｗ

>>218
> 論理回路と模式図を同一視するのわ間違いす。CISCわ、そもそも命令をシングルサイクルで
> 実行するという考えじゃ無いす。

。。。

最初のころのSPARCは、

st rd, [rs1+rs2]

のように、3つのレジスタを読み出す命令は、レジスタファイルの読み出しポートが2つしかないので、二回にわけて読み出してた
つまり、レジスタ読み出しステージが2サイクルの場合もあるんだけど、これはCISCなのかな？

>>236
> しかし将来引用されるのわ>>190-192な訳すけど。。。

べつに間違っちゃいないけどね

> もちろんLarrabeeのマイクロアーキテクチャがより明確になった段階で、的中している可能性もある
> すから楽しみにすると良いかと思うす。

いまだにROBはx86用語ではないと認められないMACオタの言うセリフじゃないよなあ

まあいいよ
どのみち命令のレイテンシは短いに越したことはない

それはそれで、
単精度演算のレイテンシ6clkもかかるCell-SPUのコーディングテクが役に立たないことが示される

同じインオーダのAtomもHT使うことでかろうじて浮動小数演算の性能悪化を食い止めてるのが現実。

レジスタ8本(x64で16本だが)でレイテンシ3かそれ以上の命令を
スケジューリングするのは何のハード支援もなしでは現実問題無理。
OoO・レジスタリネームを削除した代わりに用意された
命令インターリーブの手段がHTだ。

>>240
　　-------------------
　　レジスタファイルの読み出しポートが2つしかないので、二回にわけて読み出してた
　　-------------------
特に不思議な話とも思わないすけど？
　1. 2ステージの動作と見做さなない理由わ？
　2. 現在、イシュー／ディスパッチからレジスタ読み出しに複数サイクルかかるアーキテクチャわ
　　　珍しくない http://www.research.ibm.com/journal/rd/516/le3.gif

　　-------------------
　　べつに間違っちゃいないけどね
　　-------------------
それを団子さんに説明してあげて欲しいモノす。

つか、Larrabieの場合はHTするくらいならそれぞれのスレッドの命令列をインターリーブして並べておけばいいんだよ

>>245
GPU用途でわ深く考えなくてもTLPわ保障されているすから、適当にスレッドを振り当てても良い
かと思うす。

>>244
> 　1. 2ステージの動作と見做さなない理由わ？

馬鹿じゃね？

3レジスタ読み出しの場合はインターロックがかかるし、
レジスタ読み出しステージを2段にしてパイプライン化したところで、レジスタファイルのポート数が足りなきゃ止まる。

> 2. 現在、イシュー／ディスパッチからレジスタ読み出しに複数サイクルかかるアーキテクチャわ

それはもう全然なんの関係もないから。

>>245
SIMDレジスタが1スレッドで128本でもあるならそうしたいところだが、
ModRMを引きずる限り8本、REXつけて16本がいいところ。

まあ引きずると決まったわけではないが、それはそれで
レガシーSSEの延長でもVEXエンコーディングでもない命令セットをどこのOpcode空間に定義するのよって問題も。

>>248
命令エンコーディングのことは知らんが、1次キャッシュのデータと直接演算できるから、案外困らないんじゃないかね。

>>246
> Cache use is more effective when multiple threads running on the same core use the same dataset,
> e.g. rendering triangles to the same tile.

とインテル自身も言っているように、適当なスレッドだとだめだろう。

いやメモリ間オペレーションは代々x86の伝統だし。
デコーダを複雑にもできないはずなのでModRM+SIB+DISPによるメモリアクセスを踏襲する可能性大。
必然的にレジスタは各8本ないし16本。
マスクレジスタは別にあるのかもしれないけど。

>>250
VPU命令は4オペランドで、メモリオペランドはソース限定なわけだから、
ModRMを踏襲しないんじゃないかなあ

マスクレジスタが別にあるのは間違いがない

AVXで真の4オペランド使えてるんだが。メモリオペランドがソース限定なのもAVXの仕様。

VEXエンコーディングを使う可能性高いな。
ほかにOpcode余ってるのは64ビットでUD化された命令空間だけ。

ああx64はXMMレジスタに引数を積むとかSSE2までの存在を前提に
ABIが定義されてるから、SSEのOpcodeを潰すという対応は無しね。
逆に言うとLarrabeeでも最低SSE2までは実行できると考えられ。

>>204
> 　　デスティネーションに指定したレジスタが後続の命令でソースとして再利用可能になる
> 　　----------------
> レジスタのリード・ライトに関係無く、フォワーディングネットワーク経由で利用可能になると思われるす。

MACオタは、他人の発言を曲解して、それが間違っていると指摘するから困るんだよな。
団子だって物理レジスタの話をしているわけではないだろう。

>>254
>>204わ、あなたが>>249で書いたことのメカニズムを説明している訳すけど。。。
　　-----------------
　　MACオタは、他人の発言を曲解して、それが間違っていると指摘するから困るんだよな。
　　団子だって物理レジスタの話をしているわけではないだろう。
　　-----------------
>>247。。。

＞フォワーディングネットワーク
これ予約機構のことかね？
Intel用語ではActive Register FileといってP6アーキのレジスタリネーミング機構の特徴の一つです。

結局LarrabeeはP5じゃないって言いたいんだな。

>>256
> ＞フォワーディングネットワーク
> これ予約機構のことかね？

間違ってはないが、ズレている
MACオタが言っているのは、演算器どうしをつないでいるデータの分配ネットワークのこと

>>256
あ、P5にも(パイプライン化された計算機にはすべて)フォワーディング回路はあるぞ

>>255
> >>204わ、あなたが>>249で書いたことのメカニズムを説明している訳すけど。。。

さすがにこれは完全に意味不明で、とっかかりもないのだが

249は
> GPU用途でわ深く考えなくてもTLPわ保障されているすから、適当にスレッドを振り当てても良い

キャッシュの効率が落ちるので、適当なスレッドにスイッチするのは良くないということ

> Cache use is more effective when multiple threads running on the same core use the same dataset,
> e.g. rendering triangles to the same tile.

同じデータセットを使うスレッドにスイッチするとキャッシュが効率的になるとインテルが言ってるだろ


フォワーディング回路については、団子がこんなにバカだとは思わんかった
すまん

まあ確かに有るね。
実レジスタファイルへの書き込みまでのサイクルには言及した覚えはないので
どのみちFUCKヲタの一人相撲に違いない

>>260
> 実レジスタファイルへの書き込みまでのサイクルには言及した覚えはないので

実レジスタファイルってアーキテクチャレジスタのことか？

ならやっぱわかってねーな
これはMACオタの勝ち

いやそもそもP5って何十もレジスタあったっけ？

つか#248966でいう何ページ目にかかれてることを論じてるの？

・Cellのスケーラビリティ
・PentiumはFP加減算1サイクル

流石に負けでいいよいろんな意味で彼は１等賞(笑)だろ

>>204とかさ
addpsはレイテンシ3サイクルかかると言ってる傍で
「加減算は1サイクルで済むす(笑)」

日本語通じないバカって素敵。

結局彼はx86を知らない

>>263
それについては知らん
君ら何を言っているのか理解しかねる

>>184
> 設計段階でメモリブロックごとに、何をキャッシュに残し、何をストリーミングアクセスするか細かく
> 設定する手間わMFCプログラミングと変わらないす。

だいたい正しい

>>185
> たとえばメインメモリからオンダイSRAMに先行ロードするにしても
> prefetch*とspu_dmaじゃ全然勝手が違う。

コーディングレベルでは楽だろうが、設計レベルでは大して変わらん

>>188
> むしろSPUがネイティブにリニアアドレッシングできるメモリ空間が狭いなど、別のところで面倒。
> うん、全然求められるスキルが違うな。

Cellで性能を出せるようなプログラムなら、Larrabeeでも同じようなプログラムになる
Cellでは手に負えないようなプログラムでも、Larabeeではコヒーレントキャッシュに助けられてそこそこ動くかもしれない

>>189
> アドレスの属性を制御するのか？64-bitアドレシングを生かしてL2の一部を別のメモリ空間に
> 割り当てるのか。。。

意味不明

おい1サイクルの件、逃げずに見苦しく弁解しろよ。

・ROBはIntel専門用語
・AtomはSMTではない

一等賞大好きだな
何冠王になればいいんだよ負ッケオタ

ModRMはさすがにそのまま通せるようにはしないと思うけどなぁ

>>264
>>204
> それパイプライン化された命令限定す。
> 長レイテンシの命令を隠蔽するんじゃ無かったすか？

他人の発言を曲解した上で攻撃するのがMACオタスタイルだけど
これは1レスで矛盾した発言してる

> 結局彼はx86を知らない

x86というか、MACオタの知識はトリビアレベルだね
体系だって勉強した形跡がない

>>267
ModRMは1バイト見ただけでSIB・DISPの有無および長さを判別できるから
実はそれなりに合理的。
基本命令がx86なのに別のフォーマットを用意する方がかえってデコーダが複雑になる。


あと命令長を判別しやすいのってフロントエンドの負担軽減のためには大事だからね。
AVXのVEXプリフィクスはModRMまでの命令長が即特定できるから結果的にデコーダにも優しい。

あ、要素単位で別々のアドレスにロード・ストアする命令については
かのレポートにSIMDレジスタの各要素値を使う的なことが書いてあるので、
ModRM+SIB+DISPの拡張は不要かと思われる。
従来IAと変えないといけないのはむしろLSUだ。

マスクストアってVMASKMOVPSの512ビット版なんじゃないかと思ったり。

Cellのアーキテクトは、「シンプルな要素をたくさん並べる」というありがちな原理主義に陥り、シンプルにしすぎてしまったわけだが
目標性能と使えるリソースが先に決まっていた以上、仕方のない面もある
とはいえ、いまだにまともなコンパイラ一つ用意できていないのは情けない

その点Larrabeeは手堅いアーキテクチャでまとめていて、インテルの現実主義的な姿勢がうかがわれる
もっともCellよりずっとリッチなチップゆえに可能なわけだが

ﾀﾞﾝｺﾞ・・田舎でなんか嫌な目にでも遭ったのか？

強いて言えば嫁がゲーヲタ腐女子

>>270
> マスクストアってVMASKMOVPSの512ビット版なんじゃないかと思ったり。

伝統的なベクトル機では、マスクは算術演算にも使えるし、
マスクベクトルがおそらく複数あることを考えると、フォーマットどうなってんのかわからんね

AVXはもう公開されてるの？

>>273
なんだとコラ死にくされ

おれなんて風俗嬢と天蓋の約束をのばしのばしにされて疑心暗鬼だ

AVXはIntelのサイトにバイナリフォーマットも含め公開されてる。
Larrabeeの512ビットSIMDとAVXの可能性は不明だが、
VEXの拡張フィールドにかなり空きがあることから
LarrabeeのSIMDそのものがAVXの512ビット版の先行実装という可能性も。

関連性ね

母「○○さんなぜ今年も一緒じゃないの？」
ダ（コミケットを優先されたとは言えねーしな・・・）
母（離婚間ヂかなのかしら・・・）
ダ・母・お爺ちゃん（・・・・・）

てな感じ？

MACオタ、貼り方気をつけろって言ってんだろ
いい加減学習するか、どっかいけよ

おまえが逝け

Intelが今年のVLSI Symposiumで発表したSOIメモリ(記事中でも出てくるすけど、AMDがライセンス
を受けたZ-RAMと同種のモノす)の解説記事す。
http://www.eetasia.com/ART_8800539466_499495_NT_1d62210a.HTM
　　---------------------
　　In its paper, Intel said: "The devices with 60nm gates show suitable memory retention, and, at
　　this dimension, a bit cell could be less than 0.01m2 in size, making it suitable for potential use
　　at the 15nm node.
　　There is also excellent agreement between device and simulation that allows prediction of
　　continued scaling to the 10nm technology node."
　　---------------------

IBM Journal of R&Dの次号が3Dダイスタッキングの特集す。
http://www.research.ibm.com/journal/rdpip.html

FBCを同種でくくると回路屋ががっくり来そうだな。

PentiumのFP加減算のレイテンシが1の人は鶏のように3歩歩くと忘れてしまえるんだね。
恥の記憶もなにもかも。



あ、他人の揚げ足取りのネタだけは覚えていられるようだけど

負ッケヲタ、なんか言えコラ

決着してないぞ何もかも。
別の話題を持ってくるのは、弁解なり反論なりしてからにしてくれ。

2、3年後に笑いのネタになるのはお前自身やぞ。
いや正確に言うとリアルタイムで恥の塊。

なあいい加減正面から反論しろや
俺はしつこいぞ。
技術なき技術論者はオレンジのごとく全力で糾弾する。

おはようございました

>>285
火病中に失礼すけど、
　　---------------------
　　オレンジのごとく全力で糾弾する。
　　---------------------
で、これわ新しい２ちゃん語なんすか(笑)

IBMおよびプロセス共同開発各社が22nmプロセスのSRAM試作の成功を発表したす。
http://www-03.ibm.com/press/us/en/pressrelease/24942.wss
　　- セルサイズ: 0.1um^2
　　- ゲート長: 25nm
　　- High-K/Metal Gate
　　- High-NA 液浸露光
　　- 300mm ウェハ
発表中にSOIが言及されていないことと、ゲート長がプロセスサイズより大きいことが気になるす。
ここ数年ゲート長ってプロセスサイズの半分程度じゃなかったすかね。。。

>>287
コードギアス

結局弁明出来ないんだなｗ

ジェレミア卿自重

>>289
　　-----------------
　　コードギアス
　　-----------------
ちょっと調べてみたすけど、当人火病の上にアニヲタなんすか。。。
>>273と言い、色々不幸を背負ってるみたいすね。

どうでもいい事に話そらして
肝心な事には何も言えないハッゲオタｗ

「早とちりでしたごめんなさい」とか絶対言わないからな
負け犬の遠吠えオタは

MACｦﾀの視点って明らかにマの視点じゃないんだよな。
それなのに無理して語ろうとするからボロが出る。指摘されると話をそらす。
SIMDをSIMMと言っちゃった人にそっくりだ。

>>294
　　------------------
　　「早とちりでしたごめんなさい」とか絶対言わないからな
　　------------------
それわ、色々恥ずかしい間違いを取り繕うために『PentiumのFP加減算のレイテンシが1』とか
訳の判らないことを叫び出すヒトのことすか？

>>295
　　----------------
　　MACｦﾀの視点って明らかにマの視点じゃないんだよな。
　　----------------
団子さんわ割りに例外すけど、プログラマでハードウェアやマイクロアーキテクチャを理解しよう
とするヒトわ珍しいす。こういうのに関してわ、教育が悪いすかね。。。

得られるものが理解にかかる時間と金のコストに見合わないからに決まってんだろ

負け犬の遠吠えやってる自覚は一応あるんだな。感心した。
まあ知識はSIMD＝SIMMの人と同レベル
森嘉朗がITについて語るくらいに聞く価値がない。

LarrabeeってIntel64には非対応なんだよね？　Atomですら対応してるのに。

まあレジスタが倍増するくらいしか性能貢献が無いし、メインメモリも64bit
が必要とは考えてない、って事なのかな？

でもPAEは効率が悪いって話だし、４GB迄で充分って判断なのか。

>>169, >>174の続報すけど、米国SONYのZEGO BCU-100のサイトす。
http://pro.sony.com/bbsccms/ext/ZEGO/ZEGO.shtml
リンクされているBCU-100の仕様を読むと、結構豪華す。
　　- XDR (w.ECC): 1GB
　　- on-board DDR2 (SCC経由接続): 1GB
　　- PCIe経由増設メモリ: max. 8GB
　　- 拡張スロット: PCIe x4, 1-slot
　　- 2 GigaEther
　　- 3 USB 2.0

>>300
　　----------------------
　　Larrabee’s scalar pipeline is derived from the dual-issue Pentium processor, which uses a
　　short, inexpensive execution pipeline. Larrabee provides modern additions such as multi-threading,
　　64-bit extensions, and sophisticated prefetching.
　　----------------------
ソースわ>>208

MACオタが勉強家なのは間違いないんだよな
ネットからいろいろ記事を拾ってきてくれるし
その情熱を体系だった学習に振り向けて、アーキテクチャの教科書を一冊通読してくれるといいんだが
そうすりゃROBがx86用語だなんて言わなくてもすんだのにね

ついでにFP加減算が低レイテンシなんて恥ずかしい発言もね

「間違えました。」の一言すら何で言えないの〜

脳味噌が不自由なの〜？

>>268, >>303
あなたが自分の弟子に『体系』とやらを強制するのわ、結構な話す。しかし、
　　--------------------
　　x86というか、MACオタの知識はトリビアレベルだね
　　体系だって勉強した形跡がない
　　--------------------
　　--------------------
　　そうすりゃROBがx86用語だなんて言わなくてもすんだのにね
　　--------------------
その論法だと論文でGCTという用語を使って発表するIBMのアーキテクトわ『体系だって勉強をした
形跡がない』ことになるすけど(笑)

私の書き込みわ前世紀から２ちゃんねるやmegabbsに残っている訳すけど、それなりの的中率が
あるのわ、ある『体系』に基づいて情報を整理しているからす。
曰く『勝ちに不思議の勝ちあり、負けに不思議の負けなし』というのわ、科学的思考としても間違って
いないかと思うすけれど。。。

>>288
> ここ数年ゲート長ってプロセスサイズの半分程度じゃなかったすかね。。。

Intelのプロセスを例に挙げると
　65nmプロセス → 35nm
　45nmプロセス → 30nm
というように、以前のようにゲート長を短くすることができなくなりつつある。

http://www.intel.co.jp/jp/business/technologies/focused-tech/process-rule/index02.htm
> 65nm のプロセス技術で製造されたトランジスターのゲート長は 35nm

http://www.intel.co.jp/jp/business/technologies/focused-tech/process-rule/index04.htm
> 45nm プロセスのゲート長は 30nm

それを考えると22nmプロセスのゲート長が25nmだったとしても、それほど
おかしくはない。特に省電力をターゲットにしたプロセスであればなおさらだろう。

誰とは言わないが「リーク漏れ」の人なんかには死んでも分からない話だな

>>307
コメント感謝するす。
一方、TGDailyによるとIntelから今回の発表に関して突っ込みが入っているそうす。
http://www.tgdaily.com/content/view/38941/135/
　　--------------------
　　"Indeed, this is the smallest SRAM cell that has been demonstrated, but producing a single
　　cell is merely an exercise in lithography scaling. The announcement admits that they only
　　have demonstrated a 22 nm SRAM 'cell', not a 22 nm SRAM 'array' of any given density.
　　A single SRAM cell has 6 transistors in it. Intel's 32 nm SRAM array, which we announced
　　back in September, has 290 million cells or bits, and a total of 1.9 billion transistors. IBM
　　has yet to report a large working 32 nm SRAM array as Intel did last September. Intel's 32 nm
　　technology will use our 2nd generation of high-k + metal gate transistors."
　　--------------------
最近のIEDMの発表わ、Intelの歪みシリコンの発表が量産とほぼ同時に行われたように、現実性の
高いモノが多かったように思うす。競争相手に情報を漏らさないという要素が大きかったのが
原因の様に思われるすけど、今回の発表わプロバガンダ的要素が大きいすかね。。。

頭痛が痛いです

>>309
まあ、Intelより先に発表するってことに意味があるのかもね

先に先手を取って先制するす。

よう団子

そうやって時間が経つのわ時間の問題す。

>>306
> その論法だと論文でGCTという用語を使って発表するIBMのアーキテクトわ『体系だって勉強をした
> 形跡がない』ことになるすけど(笑)

お、ついにGCTがROBだと認めたかwww

MACオタはIBMがいまだにメモリをストレージと呼びたがるくらいの、超有名な独自用語大好き会社であることも知らないようだ

>>306
君が意図的に引用から外した

> その情熱を体系だった学習に振り向けて、アーキテクチャの教科書を一冊通読してくれるといいんだが

これはどうなのかい？
ちゃんと一冊通読した？
そもそも教科書持ってる？著者と書名は？

ただプライオリティ制御やってるだけの非対称FGMTをSMTと呼んだり
フロッピーをディスケットと呼んだり


すべて任帝が悪いニダ

このエミュレータ再現性低いな

MCPをOSと呼ぶ暴虐非道

OoO（Intel語でいうDynamic Execution）を搭載したCPUを
IBMのPPCとIntelほかのx86しか知らなかったが故の勘違いす

>>302
64bit拡張はSIMD命令だけらしい話もあるけど。

Intelのソースでないと確証が持てないよね。

>>321
と、大元のpdfはIntelのか。

そうなら単純に信用したいところだが、Pentium互換ってのが気になる。

x64互換って意味ではXMMレジスタはある可能性は高い。

VectorレジスタがそのまんまXMMの512ビット版の気がするが。




そこでまさかのYamhill命令セット採用ですよ

SSEはついてないと思う
似たようなユニットを二つも用意する理由はない

x86CPUとしての互換性を考えると微妙な気がする。ましてやIntel64をサポートしてるなら。

http://journal.mycom.co.jp/articles/2008/08/13/siggraph02/001.html

>>324えーっ

x86には汎用整数だけで8ビット・16ビット・32ビット・64ビットの命令があるけど、
ALUもそれぞれにあると思っちゃう方？
必要なところだけマスクすればいいんだよ。
現状Core 2やAtomだって128ビットSIMDユニットでMMXやx87浮動小数命令を扱ってるわけで。

とりあえずVectorレジスタがXMM/YMMのスーパーセットでありさえすれば
リソース面での面倒はないと思ってるが。

SSEとの下位互換性はとってくるだろうし、逆に「サポートしないメリット」は無いに等しい。

プレフィックス付けたりModRMのregまで使ったりしてやりくりしてたような
もともと狭いOpcode空間だから、潰して別の命令を割り当てるのも非現実的。
レガシー命令に依存したコード資産をサポートしつつ、
AVXで確保したVEXの拡張フィールドを使って新命令を利用していくほうが無駄がない。

SSEとLarrabeeのVPUではデータパスがかなり違うし
そもそもVPUには整数演算命令がない

> そもそもVPUには整数演算命令がない
整数の符号拡張つきロード・ストアがあるのに演算命令はないのか？
どこの脳内Larrabeeですか？


P5命令セットまでに互換レベル落ちちゃうと、
ゲルたんの言うCellに対する強みなんてなくなるんだよね。
なによりx64はSSE2までのSIMD命令は基本命令セットに含まれる。
互換が強みなのに互換を否定したらその時点でCell以下ですよ。
AtomですらSSSE3までサポートできる。
つまりSSE*をサポートしないことで節約できるTr数や消費電力など多寡がしれてる。
どのみち主役はVPUなので、最悪遅くとも動けばいい。

Larrabee公開資料のVPUについての説明
(PDFの4ページ)
> which execute integer, single-precision float, and double-precision float instructions.

Larrabee: A Many-Core Intel(R) Architecture for Visual Computing
ttp://intel.wingateweb.com/US08/published/sessions/VCTS001/SF08_VCTS001_100s.pdf

P.9
> Vector instructions support
>
>　- Int32, Float32 and Float64 data

すまんすまん
明日デートでいろいろ妄想してたんだ

でも、SSEと違ってLarrabeeのVPUは1次キャッシュをバイパスしてロードできないぞ

根拠はブロックダイアグラム？
なこと言ったらPenrynやNehalemのダイアグラム図を見てもやっぱり同じ感想を言うと思うぜ。
細かい動作まで矢印で書かない。

それにL1キャッシュをバイパスってのはあくまでキャッシュラインのエントリを
上書きしないって意味であって、L1上のデータバスを通過しないって意味ではない。
そもそも本当にバイパスするかどうかは演算結果そのものに影響しないので、
普通のL/S同様に振る舞う実装があっても何も問題ない。

>>333
http://softwarecommunity.intel.com/UserFiles/en-us/File/larrabee_manycore.pdf

の3.2章を見る限り、L1をスルーする命令はないと考えるのが自然

> そもそも本当にバイパスするかどうかは演算結果そのものに影響しないので、

マルチプロセッサの場合はメモリコンシステンシーとの兼ね合いで微妙なんだよ

今更ながら、4スレッドで命令インターリーブするぐらいなら
レジスタの本数４倍にしてくれたほうがよくね？
４サイクルで命令共有するってのはハードウェア単純に
できるけど。GPUとかGRAPE-DRとか。

IDFがあったのにわす野郎がなにも貼らないな

ふと妄想したことがあるんだが、
単精度FPUが一基しかないCPUでSSEを
マイクロコードでエミュレートすると、
スループットもレイテンシも4という
ある意味使い勝手の良い（こんな表現するのは
アセンブラプログラマぐらいかもしれないが）
アーキテクチャができるわけだ。

残念ながらそれだと加減算3-1なら6-4、乗算5-1が8-4くらいになるだけですな。
>>334
むしろPREFETCH*やMOVNT*がそのまんま使えそうな記述があるんだけど気のせい？
繰り返すけど機能ブロック間の矢印がないからこの命令はサポートしないなんて憶測は無意味。
Intelはいまだ矢印を見ただけでサポート命令が推測できるようなダイアグラムを出したことはない。
L2あるいは外部バス-レジスタ間の矢印がないと言うならSSE4.2まですべて使えるはずのNehalemのブロックダイアグラムにすら無い。

IntelはP6〜NehalemのStoreユニットが資料によって1基構成だったり2基構成だったり、
ブロック図を正確に書かない。

だから後藤は勿論その記事をカンニングした大原や安藤が「Nehalemでストアユニットが増えた」とか勘違い記事を書くわけだ。



既存SSE命令をサポート「しない」ことの根拠は何もないんだよね。
むしろ64ビット命令セットサポートと書かれてるだけでも
x64基本命令として取り込まれたSSE*をサポート「しなければならない」根拠たりうる。

>>338
矢印矢印って何なんだ
おれはブロック図のことなど一言も言ってないぞ

> 既存SSE命令をサポート「しない」ことの根拠は何もないんだよね。

インテルの論文から
> The cores support the full Pentium x86 instruction set so they can run existing code including operating system kernels and applications.
あえてPentium命令セットをフルサポートしてます、と書いてるから、
素直に読めばPentiumPro命令以降はフルサポートはしないんだろう

逆にSSEをサポートするメリットが何も思いつかない
いったい誰が使うんだ

> むしろ64ビット命令セットサポートと書かれてるだけでも
> x64基本命令として取り込まれたSSE*をサポート「しなければならない」根拠たりうる。

そんなことはないだろう
x64命令のサブセットだけ実装しても「64ビット命令セットサポート」と堂々と言える
繰替えすが、x64命令フルサポートならインテルはそう書くだろうよ

で、3.2を読んでも
ノンテンポラルロード・ストアが「無い」根拠なんてどこにも書いてないんだが。
むしろプリフェッチ命令が存在すると明言されてる以上、
残したいラインのローカリティを最大限保証するノンテンポラルムーブ命令が存在するのは必然性がある。

x64カーネルはXMMレジスタの退避・復帰をするし、CなどのABIでもXMMを引数として取るようになってる。
x64とSSEは不可分だし、XMMを512ビット化するだけでこと足りる。
まあ有るとも無いとも明言されてないことだからいいけど。

>>327
｜現状Core 2やAtomだって128ビットSIMDユニットでMMXやx87浮動小数命令を扱ってるわけで。

そうなの？

この手のリソース共有化したのは、Nanoがお初みたいに思っていたのだが。

NVIDIAｘTrancemeta

>>342
ttp://download.intel.com/jp/developer/jpdoc/ia32.pdf
ずっと前から共有してるのに今更分離する必要はないわな。

＞団子
そなの？最後の１語まで答がそろわなきゃ次の演算始められないなら
6-4だけど、最初の１語が得られた段階で見切り発車するようにすれば
4-4にならね？

>>342
大原氏の記事を信じている人がまだいたのか

Fall Processor Forum 2004 - Centaur、CN Architectureを発表
ttp://journal.mycom.co.jp/articles/2004/10/07/fpf1/index.html
> AMDやIntelの場合、FPUとSSEユニットは完全に独立しているので、
> どうしても回路の肥大化に繋がる訳だが


インテルの資料を見ると、上記が明らかに間違いであることがわかる

Pentium(R) III プロセッサの実装条件
ttp://download.intel.com/jp/developer/jpdoc/impliment_j.pdf
Page.9
> 小型のダイで高速動作を実現する効率的な実装
> Pentium III プロセッサでは、x87 乗算器はパックドFP乗算器に統合されました

インテル(R) PentiumR 4 プロセッサの マイクロアーキテクチャ
ttp://download.intel.co.jp/jp/developer/jpdoc/2001q1_art02_j.pdf
Page.12
> FP/SSE 実行ユニット
> FP 加算器は、1クロック・サイクルに1回の拡張精度 (EP) 加算、1回の
> 倍精度 (DP) 加算、または2回の単精度 (SP) 加算のいずれかを実行できます。
>
> FP 乗算器は2クロックで1回の EP 乗算、あるいは1クロック・サイクルで
> 1回の DP 乗算または2回の SP 乗算を実行できます。

なんかk8あたりの資料で、（数字は正確ではないけれど）
addsdが3-1でaddpdが4-2、でも下位の64bitは１クロック早く
使えるようになるみたいな記述があったような。

ああ上位と下位は依存関係ないからその意味では完全に隠蔽可能だな。確かに。
NetBurstの倍速ALUにおけるレイテンシ0.5のトリックがまさにこれだった。



で、ライター連中のなかでLarrabeeがSSE非互換って言ってるのは見るに
「誤答」だけなんだが、どうなんかね？

資産を継承したい有用なコードほど、P5みたいな古いCPUでの動作を切り捨て、
SSE等モダンな命令を駆使して保守されてる可能性が高い。
逆にP5までで止まってる保守されてないコードなんて、持ち越せてもメリット無いだろ。
MMXからSSE*のコード資産の移行は、両命令の共存はもちろん、データを橋渡しする命令を用意することで
緩やかに行われた。AVXにおいてもVUPPERZEROとかの補助命令を用意し、段階的移行を促進する方針。

データレベル並列化の需要の大きい分野ですでに圧倒的に普及させてしまったSSEを、
いきなり「動作すら許さない」なんてのはいくらGPUを兼ねるとは言え
高い後方互換性を強みとするIntelのx86戦略としては、ふつうはあり得ない。

http://pc.watch.impress.co.jp/docs/2008/0822/kaigai461.htm
CtはSSE系命令だけでなく、Sandy Bridgeの新ベクタ命令「Intel Advanced Vector Extensions (Intel AVX)」、
Larrabeeの新ベクタ命令「Larrabee New Instructions(LNI)」、さらに将来の命令もサポートする。

とまあ、案の定俺が言ったことそのまんまになりました。

互換こそ強みってのは皮肉にも後藤自身が説明したことなんだけどな。
彼は解釈に一貫性がないようで。


LarrabeeのSIMDはVEXの予約空間の一部を用いた512ビット版AVXってのはほぼ確定かな。
逆にそれ以外、無理なく割り当て可能なフィールドは無いだろう。

>>350
　　-------------------
　　案の定俺が言ったことそのまんまになりました。
　　-------------------
(笑)
それわ、それとして、さほど時間もかからない筈すから、過去を振り返えってISAのドキュメントが
公開されるまで勝利宣言わ待った方が良いのでわ。。。

勝利とかｗｗｗ
そんなものは求めていない。
最適化屋に必要なのはディベートではなく理想のCPUアーキテクチャなんだよ。
まして何言われても持論の間違いを認めない誰かさんみたいなバカが勝者(笑)なんて
当人以外思っちゃいない。

Ctで書けばLarrabeeと同時にマルチコアSSE(AVX)のコードも完成するわけだ。
これでnon-SSE, non-multicoreなコードに比べてGPUで100倍速くなったとかいう
クズ論文がこの世から消滅してくれる。

>>350
それはいいんだが、LarrabeeがSSEをサポートしていることを示唆するところはないと思うよ

>>353
でもさ、Ctで書いただけだと激遅で、Larrabee+Ctにくらべて10倍速い！
とかいうのがでてくるんじゃないかと思う。結局Nativeで書けよっていう。

http://pc11.2ch.net/test/read.cgi/jisaku/1214999146/299
299 名前：,,・´∀｀・,,）っ[sage] 投稿日：2008/08/19(火) 21:44:42 ID:wyv3H8Wc
負け犬の遠吠えやってる自覚は一応あるんだな。感心した。
まあ知識はSIMD＝SIMMの人と同レベル
森嘉朗がITについて語るくらいに聞く価値がない。


「SIMD＝SIMMの人」

誤爆失礼しました

逆に「動かない根拠」を提示してくれ。動くべきという根拠は示してる。
あ、後藤は想像に任せるとたまにとんでもない解釈をやるから却下。

まあ決め手はこの辺かな
・LNIは既存命令のOpcodeの共存を考慮したSSEの延長上の命令群。
・3オペランド拡張はAVXのVEXプレフィクスを使うことで実現でき、
しかも拡張フィールドがかなり余ってる。
→LNIはAVXの派生命令セットと考えるのが妥当。
・Intelには上位命令のサポートにあたり下位命令のサポートを打ち切った前例がない。
　→SSEからLNIのゆるやかな移行も考慮すべき
・マスク・シャッフル機構も備えるよりワイドなSIMDユニットで128ビットのSIMDをサポートできない理由がない。


あとは、デコード部だが
スカラ部がPentium命令完全互換と言ってることが、むしろ確信させる要因となる。
つまりデコード盲腸であるx87すら使えるということ。
x87超越関数みたいなマイクロコードROM容量を圧迫する命令を削らないで
SSEみたいな比較的コストの高くない命令群のデコードをサポートできない
技術的理由がないからね。

もちSSEはVPUでやればよく、P5世代といわれるスカラパイプ自体に大きく手を入れる必要はない。
もちろんVPUでは小回りが利かない一部のSSE命令をマイクロコードで実装することもできる。
SSEはレガシィ扱いなので多少遅い程度なら問題ない。動くことが重要。


スカラ側がノーマルP5＋αってのとベクタ側でのSSE命令のサポートは、何ら矛盾しない。

OS含め「あらゆるコードが動く」って言ってるしね。

XMMレジスタがない64ビットなんてのもありえない。
x64非互換の新たな基本ISAを定義する必要が生じてしまう。
LNIは汎用IAでのサポートをも見越した命令群だと説明してる傍らで
自らの互換戦略と矛盾することを敢えてやる合理的理由がどこにあるかね？

>>358
団子はSSEがあったらいいナと言う話をしているんだが(それには同意するよ)、
おれはLarrabee固有の実装ではちょっと難しいかもしれないという話をしているんだ
だから噛み合わない

団子は、下のLarrabeeでSSEをサポートしたくない技術的な理由に反論すべきだ

> ・マスク・シャッフル機構も備えるよりワイドなSIMDユニットで128ビットのSIMDをサポートできない理由がない。

LarrabeeのVPUが性能向上のためによりゆるやかなメモリコンシステンシモデルを採用している可能性が捨てられないし、
そうするとSSEと互換性を維持するのはそれなりのコストがかかる


どうでもいいことだけど

> x87超越関数みたいなマイクロコードROM容量を圧迫する命令を削らないで

配線レベルでできあがっているものから、ハナクソみたいな規模の回路を削るメリットはなんにもないし、
新規ユニットの設計の引き合いに出すのも不適切

>>359
なんだかなあ、団子はLNIとLarrabeeを混同している

> SSEがあったらいいナ

ないとx86の互換性戦略として矛盾する
> LarrabeeでSSEをサポートしたくない
お前の願望は聞いてない
ゲルジンガーの言葉のほうが説得力がある。

> LarrabeeのVPUが性能向上のためによりゆるやかなメモリコンシステンシモデルを採用している可能性が捨てられないし、

捨ててください。

> そうするとSSEと互換性を維持するのはそれなりのコストがかかる

何故？と言う質問はさておき
GPUとしての効率のために後方互換と言うメリットを犠牲にしたら
x86を選んだ意味そのものが否定されるよね。


・Larrabeeに移植して高速化できる可能性が高いx86コードほどSSEに依存している。
・SSEを排除したら64ビット拡張はx64との互換性がなくなってしまう。

性能の為なら基本ISAを分断するような問題すらあってもかまわないかのような前提でのあんたの仮説に価値はない。


べつに速く動けとは言ってない。
1命令10クロックかかってでもとにかく動くことが大事。

>>361
団子もMACオタに負けず負けず嫌いのようでww

> ゲルジンガーの言葉のほうが説得力がある。

> x86を選んだ意味そのものが否定されるよね。

> 性能の為なら基本ISAを分断するような問題すらあってもかまわないかのような前提でのあんたの仮説に価値はない。

> 1命令10クロックかかってでもとにかく動くことが大事。

ぜんぶ団子の好き嫌いじゃん

おれは、出来るか出来ないかの話をしているんだよ
〜べき、とか、〜が大事、とか、〜に価値がある、といった話ではない

>>361
> > LarrabeeのVPUが性能向上のためによりゆるやかなメモリコンシステンシモデルを採用している可能性が捨てられないし、
> 捨ててください。

反論できないからってこんな要求まですんなよ

ttp://pc.watch.impress.co.jp/docs/2008/0822/kaigai461.htm
＞Intelは、LarrabeeのCPUコアは、PC向けCPUほど高いシングルスレッド性能は持たないが、
＞OSを走らせるには充分な機能を備えていると説明する。
＞「Larrabeeコアは非常に高機能で、ほとんどどんなコードも走らせることができる」とBill Mark氏は語る。

これ素直に読んだらSSE動くと捉えるだろ。
MMXならまだしもSSEが「ほとんどどんなコード」に入ってなかったら酷い話だ。

根拠のない「可能性」を語るあんたほど感情的なもんはないよ

SSEをサポートしないのはこれまでIntelのとってきた方針と矛盾するし、
しないことで起きる問題のほうが甚大だ。

AVXのマニュアルなんかに目を通せばx86における
バイナリコードを含むコード資産の継承についてIntelの思想が理解できる。

>>364
ようやくまともな意見が出てきて安心した

SSE未サポート説を唱えるバカ連中は
「SSE抜きの64ビット拡張作ったから64ビットWindowsをもう1バージョン作ってね」
なんて通ると思ってるのかね。Yamhillプランすら踏みつぶしたMSに。

SSEの互換を切り捨てることで得られるメリット（あるのか？）にどんな幻想を抱いてるのか
さっぱり解りかねる

>>364
> ＞「Larrabeeコアは非常に高機能で、ほとんどどんなコードも走らせることができる」とBill Mark氏は語る。
> これ素直に読んだらSSE動くと捉えるだろ。

いや、既存のGPUと違って、いろいろなコードが動くという意味だろ
既存のx86バイナリをそのまま動かせるとは読めないね

もし既存のx86バイナリを文字通りそのまま動かせるんだとしたら、
なぜここで「既存のx86バイナリをそのまま走らせることができる」と言わないのかね
せっかくのセールストーク中なのに

>>365
> 根拠のない「可能性」を語るあんたほど感情的なもんはないよ

根拠は何度も挙げてるだろ
「SSE的なメモリコンシステンシモデルを採用すると、Larrabeeの性能の足を引っぱる」
だ

これまでのインテルの方針は理解しているし、これからも続けるだろうが、
角を矯めて牛を殺すようなことはしないだろう、と言ってるんだよ

Larrabeeなんて高々一つの実装なんだよ
それよりも、メモリコンシステンシモデルを含めたアーキテクチャの定義のほうがはるかに重要だ

それはあんたが趣味でASIC組んでやってくれ。
1個人の願望をIntelに求めるな。

>>368
> 1個人の願望をIntelに求めるな。

お前が言うな(AA略

それにしてもSSE必要派はなんなんだ
いったいどういう局面でSSEが必要になるんだ
LarrabeeをWindows PCにしたいのか

そろそろスルーよろ。＞粘着君以外

>>370
そうだな
インテルのポリシーはおれも知っているから、技術的な反論以外はもう書かないでくれ

＞ウィークコンシステンシ

つか逆に、x86って常にL/S順序は一貫してたっけ？
じゃあ{m,l,s}fence命令は何のためにあるの？


SSEなんて殆どレジスタに作用する命令だし
VPU演算結果出力の下128ビットだけをXMMレジスタリに書き込むだけで良いはずなんだが。
なぜそれを無理と言い出すのか理解不能だったんだがようやく理解できた




x86命令セットを何も知らんのだろ？

>いや、既存のGPUと違って、いろいろなコードが動くという意味だろ
>既存のx86バイナリをそのまま動かせるとは読めないね

これは苦しいな。
ほとんどどんなコードの意味には既存のx86バイナリも含む様々なコードとしか読めないけど？

XMMレジスタを一切読み書きしないx64用OSはおそらく存在すらしないな。

>>367
＞なぜここで「既存のx86バイナリをそのまま走らせることができる」と言わないのかね
俺もこれはちょっと思った。けど勘ぐりすぎかなと思って素直に捉えることにした。
ただ、「そのまま動く」と言ってない理由にx64で切り捨てられた命令群や、
MMXみたいなもう使う理由のない命令は流石に対応しないという意味に思えたもんで。

やっぱり売りとしては今あるSSE類を使った並列化可能なプログラムはそのままララビーでも実行できて、
その上で拡張レジスタで処理した方がさらに速くなるという方が自然だと思う。
特にx86のコード資産を最重視してるインテルが新規に市場を奪おうとしてるのにメジャーな命令を外すとは思えない。
技術的な話でできるかできないかなら、団子の言うようにできない理由はない。

たしかにララビーのベクタユニット見るとSSEなんか必要ないと思うけどね。
でも今は性能追求よりも普及を目指す段階だし、ベクタが独立してることからもゆくゆくは外されるかもしれない。

盲腸に近いMMXやx87fpがいまだサポートされていることを考えれば
Intelのバイナリ互換信仰は相当根強いと思うけどね。

>>372
> ＞ウィークコンシステンシ
> つか逆に、x86って常にL/S順序は一貫してたっけ？

実装はしらんが、sequential cocnsistencyではないJK

> SSEなんて殆どレジスタに作用する命令だし

ああ、そこは関係ないから

LarrabeeにはScatter/Gatherがあるだろ、
1命令で16要素のメモリアクセスするから、スレッド数にあわせて4段のパイプラインだと、
全部で64アクセスをバッファにためないといけない

それをSSE的にフェンスするとなると、下手すれば全スレッドが止まる

珍説の動機はそんなことか
ずいぶんくだんねーな。
そりゃシリアル化が必要なところでは使わなきゃしゃーないし
SSEが使えないとする理由にはなり得ない。



P6、NetBurstのときも異常に遅い命令があって、最適化マニュアルにて使用非推奨にしたことはあった。
でも#UDにした命令はいまだかつてないんだよね。

SSEサポートしても意味ないだろ
既存のコード走らせても、たぶんC2Qなみか
それ以下だろうから

それとも、SSEのあらゆる命令を使うと自動的にフェンスの副作用が起きるとでも思ってるのか？
x64で標準仕様となってるXMMレジスタとスカラ/SIMD命令が使えなくなる理由ならえらい迷惑な勘違いだぞ？

フェンスなんてそもそも頻繁に使う命令じゃねーよ。
マルチスレッド環境での共有変数の読み書きには必要ではある。

>>378
VPUのほうはメモリアクセスを全く順序づけないのが簡単なんだ
どうせベクトルデータだし、VPUが排他制御する必要はなんにもない

ところがVPUをSSE対応にするとなると、フェンスの全停止以外の解決はそれなりのリソースを食うんでね

>>380
違うつの
フェンスに対応したメモリアクセスユニットが割高につくという話だ

お前、ハードとソフトのコストもごちゃまぜにしてるぞ

>>380
> フェンスなんてそもそも頻繁に使う命令じゃねーよ。
> マルチスレッド環境での共有変数の読み書きには必要ではある。

そりゃPCなんかのアプリの話だ
GPUだと小さなスレッドがいっぱい走ってる
依存関係はほぼないが、「ほぼ」というのが曲者だ

ここ見るまでメモリフェンス知らなかったw
16要素のレジスタ関節アドレッシングで
フェンスなんてやってられないよな
論外だろ
セマフォみたいなのに使うのもいみふめい

>>382
同期ってメモリアクセスレベルで取らなきゃいけないの？
もっと低コストな方法はないものか

>>379
動くことに意味があるんだよ。
遅いとは言ってもx87よりは速いのは確実だし、動かないのは論外。

Intelは「緩やかな移行」の手段を提供してきた。
新命令に最適化して効果が大きい部分をまず先に重点的に新命令に書き換える
という選択肢が得られる。それがコード資産の継承の最大の意味。

いきなり全部書き直しだと、CellやCUDAに対する強みにならない。

>>385
Cとか処理系を提供すれば
バイナリ互換なんて関係ないよ
シングルスレッドはATOM程度なわけだから
ベクトル拡張に合わせて書き直さないと
何にも使えないはず

CUDAほどきつくなくても、データ構造とかを
明示しないと性能出ないのは明らか
書き直さないで動かす人いないでしょ

フェンスの副作用のない命令までなんで禁止しないといけないの？
SSEにはベクトル要素毎に独立にメモリアクセスするようなLS命令はない。

シリアル化が必要なところで明示的なフェンス制御命令はどのみち必要だ。
SSEを禁止する理由にならない。

だいたいに16要素の独立ロード・ストアを等速で同時にこなせるわけがないだろJK

マスクを駆使して最大16回L/S発行するだけかもしらん。もちろんパイプラインはストールする。
キャッシュライン縛りの兼ね合いもあるし、
アセンブリレベルの生産性の向上には寄与するかもしれんが
スループットは最初から期待できない。

CPUは高速化のための新命令追加だけじゃなく
既存の命令も高速化されてる
だから部分最適化というか、一部新命令追加でも速くなる

いまどきSSEなんざtrapかけてosでｴﾐｭれば良いだろ。互換云々いうなら。

>>388
フェンスの必要性じゃなくて、それ実現のためのハード量の問題じゃね？
トランジスタが無限で、クロックに影響なきゃ
どんな命令だって追加するさ

あるいはいよいよﾋﾞｯﾄが足りねぇから再去り宛てとか。ｹﾞﾗｹﾞﾗ

ISA互換だけならエミュるとか、マイクロコードで実相とかなんでもいいんだよな
ただ速くないのに互換性があっても
グラフィックスや数値計算じゃ意味がない
バイナリ互換だけが売りで、この手の用途で
成功したアーキなんかないだろ、たぶん

>>393
68030 -> CPU32とかPPC ->405のfpとかあるんでないかい?

ところでstoreはするーのか

あれ、うけねぇなぁ…

フォルトはおせーし、あ〜あ時代は繰り返すな…

>>395
すまんです
おれの知識がたりないのでピンとこないです
寝ます

そろそろIntelもx86どうにかしようと画策してるんじゃね？
今はうまくやってるが、今後もそうとはかぎらんわけで

x96とWin32を互換Boxに追い込めれば、ブランニューのアーキテクチャをつくれるのにな

シリアル化が必要なところで明示的なフェンス制御命令はどのみち必要だ。
SSEを禁止する理由にならない。

だいたいに16要素の独立ロード・ストアを等速で同時にこなせるわけがないだろJK
おそらくマスクを駆使して最大16回L/S発行するだけ。もちろんパイプラインはストールする。
キャッシュライン縛り（64か128バイト単位？でのデータ移動）の制約もあるからリッチにするだけ無駄。
アセンブリレベルの生産性の向上には寄与するかもしれんが。

>>377
＞LarrabeeにはScatter/Gatherがあるだろ、
＞1命令で16要素のメモリアクセスするから、スレッド数にあわせて4段のパイプラインだと、
＞全部で64アクセスをバッファにためないといけない

1命令を1クロックサイクルでこなせるなんてどこにも書いてないし、
小さなデータでも常にキャッシュライン単位での移動になるから
LSUだけを化け物にしたところで>>399の指摘どおり内部バス帯域が
付いていかない。

複数クロックかかるマクロ命令だろう。



>>379
80:20ルールといって、パフォーマンスのボトルネックは
コード全体の2割以下のモジュールという経験則がある。
で、20のうちでも、LNIに置き換えることによってスループットを
引き上げることが出来る箇所はおそらく現状SSEで実装されてる
コード部分でもごく一部だ。

SSEはもちろんAVXにもスカラ命令が存在すること自体、ベクトル化が
出来る箇所が限られてることの現れだ。
で、LNIに置き換えて効果の見込めない、スカラだったり、
2〜4並列程度で十分な箇所は、SSEのコードのまま残してもいい。

市場のCPUがAVX以降の命令への完全移行にともないレガシー部分は
ゆくゆくは全部置き換えることになるだろうが、効果の少ない
部分は後回しにしたり放置したりできる。

SSEを非互換にしたりすると、SSEを使った部分を最初から全部書き直す
羽目になる。
これはIntelの互換戦略としてあり得ない。

>>366
>>364 の参照先の記事で
> ●Intelは新言語拡張「Ct」をLarrabeeのために準備
               :
>　CtはSSE系命令だけでなく、Sandy Bridgeの新ベクタ命令「Intel Advanced Vector
>Extensions (Intel AVX)」、Larrabeeの新ベクタ命令「Larrabee New Instructions
>(LNI)」、さらに将来の命令もサポートする。

と書いてあるから Larrabee は将来ではなく最初から SSE を搭載しているように読める
けれど、Larrabee で Windows を走らせる意味が果たしてあるかというと全くないように思う。

GPUのようなものすごい多コア化は Windows と一般アプリの高速化にはあまり寄与しないし、
一般アプリや OS と GPU とではメモリアクセスのパターンが全然違うのでこれまた効率が
犠牲になるし、ただでさえメインメモリの帯域不足が問題視されているのに更にそれに
GPU のような帯域食いが載ったらもう。

>>400
Larrabeeのscatter/gatherは、1キャッシュラインあたりに1サイクルかかる
16データ全部が同じなら1クロックで済むよ

> LSUだけを化け物にしたところで>>399の指摘どおり内部バス帯域が
> 付いていかない。
> 複数クロックかかるマクロ命令だろう。

君も団子もだけど、どうしてそういうところでケチくさいのかなあ

リストベクトルなんて有名な性能ボトルネックじゃん
リソースの投入し甲斐のある箇所だよ、ベクトル機みたいにね

結局のところHPC向けにx86互換って部分は武器になりうるんだろか
その分野の人達は性能が出るなら物には拘らない、に対する回答を特に聞いてない気がする
ULPC以下の分野にはブラウザ使うならx86以外あり得ないってところを強調してるけど

>>402
お前がボトルネック分析もできない馬鹿だということはよくわかった。
もうこの話題に関わるな。知識レベルはMACヲタ以下。

リングバスが双方向で計1024ビットと帯域が解ってるだろ。
L1,L2のキャッシュラインが1エントリ128byteだとして、
リングバスに流せるデータスループットは双方向で理論上最大1line/clk程度
無論メインメモリの帯域はそれを下回るだろうし全コア分のトラフィックが
集中することを考えると、1コアあたりで使える帯域は限られる。

1コアにLSUを複数積むことで得られるパフォーマンスゲインなど
限りなく無い。

しかも、おまいの仮説（妄想）では「SSEのサポートが困難になる」わけだろ？
消費電力も増える→シンプルなコアの集積でスループットを稼ぐアプローチと矛盾

よってリソースの投入し甲斐とやらは、無いと断言できる。


つーか、LSUは消費電力が大きい部位でな、
Nehalemですらデータロード・命令フェッチは最大16バイト/clkに抑え込んでる。
Loadユニット2本、32バイト命令フェッチにしちゃうと消費電力が馬鹿みたいに
上がると中の人は説明していた(*1)。

10％の性能向上のために30％も消費電力増加するアプローチは採用しない。
それが今のIntel。

*1) 実際Phenomはこの拡張をやった結果爆熱化してクロックが上がらず
結果的に同世代プロセスルールのCore 2と比較しても低性能になってる
結果として理にかなってる。

うはｗｗｗ鳥に化けたｗｗｗｗ

逆に考えてごらんよ。
HPCの分野はGflopsの値が高く出るlinpacのように極めて単純な
構造のﾌﾟﾛｸﾞﾗﾑに適したﾊｰﾄﾞ構成やﾁｭｰﾆﾝｸﾞ技術に特化しすぎて
実分野では性能も出ない信頼性も低い金物を税金つぎ込んで作って捨てて、
儲からない袋小路にはまって抜けだせせなくなった。
ま、いわゆる古いタイプの大企業の研究所のお為ごかし研究成果に周りが騙されただけとも言えるが。
うっかりそれに関わったきまじめなソフト屋はデスマによって優秀なﾔｼから潰されて死体累々。
適当にサボったヤシしか生き残らず、そのうち事業は誰にも相手にされなくなった。
逆にインテルやIBMのpowerなんかもそうだけれど、金になるコンピュータ事業のありかた、
儲かるﾊｰﾄﾞとは何かを追い求めた結果として、儲かって次のﾊｰﾄﾞを設計する資金を稼ぎ、
その資金をつぎ込んで速くて良くできたCPUを作り、そのプラットホームの元でソフト産業の
裾野を展開し共存共栄した。
そういった事業の指向を選んだ結果儲かって、Core2のようにリストも速い良くできたCPUを
設計することができた。
原因と結果を見間違えちゃいけないぜセニョール。

ダンゴって、相手はだれでもいいからファビョってネットで喧嘩売るのが生き甲斐なのね

throughputさえ上げれば性能が上がると
良く聞かされたお為ごかし

そういやIA-64はもう終了と言って良いのかな
cache容量増やしても性能上がらず社内のcore2に負け
メルセドの子孫の墓標はどこぞに立ったのかな
結局、何だったんだあのEPICって

>>403
ジョブの時間短縮が桁違いぐらい得られればどこにでもマンパワーで移植を試みるよ。
実際の所は最高性能の領域と超低消費電力の両端では一番の壁は物理法則によるSiプロセスの限界だし。簡単に言えば物理法則内での実現可能性＞＞＞できたものの使いやすさ。

この場合、物理限界は関係ないかと

>>409
予定では
2008後半　Tukwila
2009-2010　Poulson
2011？　Kittson

>>404
> リングバスが双方向で計1024ビットと帯域が解ってるだろ。

リストベクトルの話で、なんでいきなりリングバスが出てくるんだ？？
1,2次キャッシュはどうした

> つーか、LSUは消費電力が大きい部位でな、

だからSSEのメモリコンシステンシーのサポートをしたら、ただでさえデカいLSUがますますデカくなるって言ってんだろ

> だからSSEのメモリコンシステンシーのサポートをしたら、
> ただでさえデカいLSUがますますデカくなるって言ってんだろ

だから、そもそもLSUを複数搭載しなきゃいい話だろ。
帯域的にも1クロック1アドレスの解決で充分であって
それ以上を求めなければ破綻し得ない。
お前の願望前提での理屈に価値はない。

L/S順序のシリアル化はマルチスレッドにおける同期処理に必要不可欠だし
それによってフリーズする可能性があるってのは、シリアル化のせいではなく
実装に問題があるから。
シリアル化を禁止すれば良いってのはプログラミングをわかってない人のおばかな発想。

だからお前の話は本末転倒だ

>>406
ベクトルカルトの妄想ストーリーもここまでくると正直きもい

水平加算みたいな単純な命令すらPenrynでもいまだに複数のマイクロ命令に分解してるんだよな。

リッチ過ぎる命令が案の定複数クロックかかりますなんてのはIntelのお約束。

その意味、1クロックでこなせるに違いないなんて期待を抱いた時点で負け。


メモリフェンスが害悪？ならデコード時にNOPと解釈しちゃえばよくね？
＃心臓病の予防のために心臓を摘出したいと言い出す頭がアレな人を見ているような気分

つーかさ
・P5はもともと純CISCである
・Larrabeeの1コアあたりのTDPはAtomに毛が生えた程度

以上を踏まえると複雑な命令はマクロ実装で複数クロック実行にして
回路は極力シンプルに抑えることは当然なんだよな

1コアにLSUを16基積むのが当然とか、どこのスパコンプロセッサだよ。
1コアだけで150Wだと思ってないか？

しまいには、メモリフェンスが邪魔だとかｗｗｗ
SSEそのものが邪魔だとかさらにはx64命令セットとの互換性がなくていいだとか

自己の妄想や願望ありきで、それに立ちはだかる常識を片っ端から否定していく姿勢は
MACヲタ以上ですよ。
自分の思い込み自体が間違っているとは微塵も思わないところが彼を超越している。
MACヲタは間違いを指摘されると誤魔化したり敗走する程度には浅知恵や羞恥心はあるが
彼にはそんな思考すらない。脳みそアメーバ級。

ちなみにCellはCellで、「DMAブロッキング」という方法でL/S順序のシリアル化を
やるようになってる。必要な機構です。
メモリL/Sのシリアル化が使えなければ、マルチプロセッサにおける
マルチスレッドプログラムの設計を困難にする。
LSUを16基積むことで性能向上を得る云々以前に、マルチコアCPUとして死活問題。

>>414
> 帯域的にも1クロック1アドレスの解決で充分であって

だからLarrabeeは違う実装だといってるつの
本家の論文くらいちゃんと読め
リストベクトルの場合、同じキャッシュラインに乗るデータは異なるアドレスをまとめてロード/ストアするんだってば

インテル論文
> The speed of gather/scatter is limited by the cache, which typically only accesses one cache line per cycle.
> However, many workloads have highly coherent access patterns, and therefore take much less than 16 cycles to execute.

＞リストベクトルの場合、同じキャッシュラインに乗るデータは異なるアドレスをまとめ＞てロード/ストアするんだってば
　
もちろんそれは読んだ上で電波君かまってるんだよ。
マスキングとロード･ストアを1サイクルでこなしても「最大」16クロック
書き込み対象のキャッシュライン数分のクロックがかかると。

SSEの*fenceと干渉する云々の妄想は、おそらくはLSUを32ビット単位で
16基積むという彼の思い込みが前提なんだよね

↓で、16クロックかかるんならこんな必要ないじゃん

> LarrabeeにはScatter/Gatherがあるだろ、
> 1命令で16要素のメモリアクセスするから、スレッド数にあわせて4段のパイプラインだと、
> 全部で64アクセスをバッファにためないといけない

>>414
> シリアル化を禁止すれば良いってのはプログラミングをわかってない人のおばかな発想。

だから、SSE的なシリアル化はいろんな意味でコストが高いといってんの
シリアル化はSSE的なフェンス以外の実装もある

>>416
団子よりバカ

>>417
> 以上を踏まえると複雑な命令はマクロ実装で複数クロック実行にして
> 回路は極力シンプルに抑えることは当然なんだよな

普通は、特にこんな新アーキの場合は要求性能が最初に決まるんだよ
本末転倒

>>419
> おそらくはLSUを32ビット単位で16基積むという彼の思い込みが前提なんだよね

勝手に想像しておれを叩かないでくれ…
せめて引用して叩いてくれ…

>>420
> ↓で、16クロックかかるんならこんな必要ないじゃん

？？意味がわからん
リストベクトル命令もパイプライン化されてるだろJK

当初の主張は
「LarrabeeではSIMD整数演算をサポートしてないからSSE互換でない」
だったんだよな。もちろん間違いだった。

LarrabeeがSSE対応だとどうしても困ることがあるようで
何か重大なトラウマでもあるのかと思いました。

>>422
> 「LarrabeeではSIMD整数演算をサポートしてないからSSE互換でない」

これが間違いだってのはすぐに認めたぞ>>332

団子が言ってるのはID:cV9nKmLjの事だろう。

＞普通は、特にこんな新アーキの場合は要求性能が最初に決まるんだよ

06年くらいから掲げられてたのは既存SSEコード資産の互換なんだが。

＞？？意味がわからん
＞リストベクトル命令もパイプライン化されてるだろJK

お前の脳内の「常識」（笑）など聞いてない
最大16サイクル云々はレイテンシではなくスループットサイクルだ。
レイテンシだとレジスタ→L1間でも＋3サイクル程度は少なくともかかる。

>>425
> 最大16サイクル云々はレイテンシではなくスループットサイクルだ。
> レイテンシだとレジスタ→L1間でも＋3サイクル程度は少なくともかかる。

またわけのわからんことを

レイテンシ > スループット

ならパイプライン化されてるんだよ馬鹿め

VPUのリストベクトル命令は、ナイーブな実装なら難しくないんだよ
ただ、リストベクトル命令の途中でページフォールトが起きて、ハンドラ内でフェンス命令を実行すると死ねる

スループット16clkの意味わかってるの？
16サイクル後まで後続命令を発行できないってことだ。

>>428
> スループット16clkの意味わかってるの？
> 16サイクル後まで後続命令を発行できないってことだ。

なんだよ、団子もMACオタと大差ない理解じゃん

お前が誤解してるからそう思うんだよ。
お前の思う「理想」を捨てて客観視しろよ。

IntelがL/Sのサイクル数を言うときは基本的に最大スループットだ。
スループットサイクルは、Intelの資料上の定義では
理想状態で命令をN回連続実行しかかった合計クロック数をNで割った値（Nは充分大きい数）

「最大16サイクルかかる」ってのは1度発行してから次に同じ命令を発行するのに
文字通り最大16クロックサイクル待たされる。

パイプライン化されてるってのはスループット1ですむってこと
１つLSUの発行ポートを最大16サイクルにわたって占拠するのをパイプライン化とは言わない
リストL/Sが連装LSUによってパイプライン化されてるなら「16クロック以内」
じゃなくて「1クロック」って書くだろうよ。

これは憶測でもなく事実を根拠とした考察


パイプライン化されてるに違いないなんてのは「願望」というか「妄想」
それありきの連想はやっぱり妄想の域を出ない。

ステージサイクルが1-1-3の三段パイプラインのスループットとレイテンシを考えてみな

くどいけど、L/S順序のフェンスをすると止まるような危険な実装なら
やめるべきなのはフェンスではなく連装化のほうだ。

フェンスに「SSE的」もくそもない。
もともとマルチプロセッサを考慮して用意された命令だ。
フェンスはマルチプロセッサ・マルチスレッドでの
効率的な同期処理において「絶対に必要不可欠」なの。
代替手段などあり得ない。

それともIntelはお前の我侭聞いてくれる会社にでもなったの？
リストI/Oだけの性能（笑）のために10年前から続けてきた
フェンス機構の設計を見直させることは無理だと思うけどね。

つーかレイテンシとスループットの概念がわかってないのはMACヲタの専売特許だぞ
彼のキャラをパクんな

>>415
core2のリストを誉めた結論に対して、どう縦読みしたらベクトル崇拝と受け止られるんだお…

>>432
連装ってなんだよ
おれの発言を捏造しないでおくれ

メモリの順序づけなんて、データ依存関係があるところだけでいいんだよ
フェンスなんて大ざっぱすぎる

ちゃんとした教科書には、メモリコンシステンシモデルの意義が書いてあるはずだが
慌ててぐぐった表面的な知識を披露してくれなくてもいいよ

だからお前の妄想はいらない

こんなに盛り上がってるのに誰かさんがこのスレにこないなぁ

>>433
また『見えない敵』と戦っているすか(笑)
誹謗中傷に勤しんでも、過去の恥ずかしい記録わ消えないすけどね。。。
http://pc11.2ch.net/test/read.cgi/jisaku/1209622524/834
　　-------------------
　　834 名前：,,・´∀｀・,,）っ 投稿日：2008/07/12(土) 14:55:55 ID:cL+fyQY2
　　　　ゲルたんが言うんだ。
　　　　今年発表されたAVXがSandyBridgeとLarrabee共通の新命令であることは自明。
　　-------------------
http://pc11.2ch.net/test/read.cgi/jisaku/1174309818/396
　　-------------------
　　396 名前：・∀・）っ-○◎● 投稿日：2007/04/19(木) 21:00:02 ID:6E1sFwXl
　　　　フェッチ帯域が16バイトのままだと思いたがる方が、電波でしかない。
　　-------------------
次に恥をかきそうなネタわ、Sandy BridgeでFP演算器これすかね？
http://pc11.2ch.net/test/read.cgi/jisaku/1194499453/844

>>438
IDFの資料に夢中で、こっちのフレームに付いていけてないす(笑)

おれは必ず技術的根拠を挙げて話をすすめているのにフレーム扱いは心外だ

ロックを獲得したのを保証してからクリティカルセクション内のデータをメモリアクセスさせるのがacquire
CS内のメモリアクセスが完了したのを保証してからロックを解放するのがrelease
これがフェンス命令のコンシステンシモデル

しかし例えば、無関係な二つのCSに入る場合でも
互いのacquire/releaseが他方のメモリアクセスをブロックするよな
無関係なCSなので本来は不必要なブロックだ
つまりフェンスより緩いモデルがあると言うこと

自CSに属するアクセスだけブロックする提案は、80年代から論文がいろいろ出ている

さらに、CS内のあるワードについて最後の書き込みがされれば、
そのワードについては、次にCSに入る事が保証されているプロセッサは、ロック獲得前でも自由に読めるよな

これがデータフロー的解決

>>431
団子たんにはこれの返答がほしいな…

それはともかく

ららびーのロードストアユニットってリストベクトル対応だろ
けっこうなOoO-nessを持ってると思うが
少なくとも途中でストールしたリストベクトル命令を追い越せるほうが
マルチスレッド性能がでるぞ

>>442
例えば、ストリーミング処理で
入力のロックを獲得するために
出力のロック獲得やデータアクセスまでブロックされるということ

>>443
後続の命令は2クロック待たされる。
それはパイプラインとして体をなしていない。

必ず3かかるのがわかってるならステージを3分割して分散処理させたほうがいい。

でも3かかる処理がたまにしかこなくて普段は1で済む処理を
こなすというならアリ。


でだが、ベクトル要素毎のL/Sは、LSUが一個しかないのに
16クロック待たされるって事実が気に入らないの？

ベクトルL/S命令投入の1クロック後に常に即次、
命令を投入できるようにしたいならLSUが16本連装されてないと無理なんだよ。
16キャッシュラインの書き込みに16クロックかかるだけなら
キューイングを深くする必要自体がないんだよ。








ところでLarrabeeは4段パイプラインだと本気で思ってるやついるの
この馬鹿以外に

>>445
さんきゅ
帰ってから反論する

フェンス命令必須論も展開しといてください

さて、団子げっとー（嘘


> 帰ってから反論する

願望ありきで「論」をなしてないからはっきり言って無駄。
おまいの願望にはTDPとダイ面積の制約の中で効率を上げるアプローチ
つまりできるだけシンプルでなければならないという視点が欠落してる。






Larrabeeのパイプライン段数を推測するにはいくつかヒントがある。
いつぞの古いIA32最適化マニュアルを参照、P54Cは5段のパイプラインとなっていることがわかる。
そしてデコーダは1バイトOpcodeに最適化されており
2バイト以上の命令は、先頭からOpcode終端までのバイト数分だけ使う仕様になっている。

で、このP54C型のデコーダだと、LNIはOpcode終端までの長さは4バイト
（3〜4 Register Operandの実現のためVEX 3byteエンコーディングを使うと仮定）
つまり4クロックかけてデコードとかになるね。
でも、これだとベクトル積和算がいくらリッチだろうと額面どおりのスループット
出せるわけないんだよね。

つまり、LNIをデコードできる側は少なくとも、モダンなCPU並みにリッチなデコーダを
備えている必要がある。もちろん相応に段数が増える。
更に、P54Cと比べてLarrabeeの動作クロックレンジは10倍以上になる。
1GHzを超えるCPUって軒並みパイプライン段数は10段以上になるんだよね。
参考までに同じインオーダで2issueパイプラインのAtomで16段。

で、更に4スレッドのマルチスレッディング。
4つのスレッドから代わる代わる命令をフェッチしないといけない。
Pentium 4のNorthwoodは20段だったパイプラインが、HT有効にするだけで1段加わった。
少なくとも1段は増える・・・かもしれない。

さて、Larrabeeのパイプラインは何段？


誤答はこういう思考実験もなしにP54Cを引き合いに出して「短いパイプライン」なんて
言ってるが、こいつ本気でバカだろうと思うよ。
非対称パイプラインであること以外P54Cとは別物といっていいと思うよ。。

http://pc11.2ch.net/test/read.cgi/jisaku/1217915128/

まあGPUとしては論外だな。
俺は既存ｘ86/x64 OSがそのまま動きSSEの資産も引き継げる
Cellもどきとしての需要のほうしか期待してないからどうでもいいんだが



パフォーマンスゲインに寄与するとは思えないような命令1, 2命令の高速化のために
既存の有用な命令200命令以上を使用禁止にしろといってるバカ約一名はまったく話にならん。

わかった
団子たんがららびーに何を期待するかは勝手だ

それはいいから、フェンス命令が必要不可欠ではないという主張に反論してくれ

反論も糞もねー
コードを示せ


むしろお前の書いたマルチスレッド化プログラムでも示してもらおうか
そいつの性能をみてお前の主張の技術的妥当性とやらを判断してやろう

zipでうｐれ

タイムリミットは24時間以内

100パーセント当たる予言をしてやろう。
Larrabeeのサポート命令はSSE2までは完全に確定。フェンス命令もそのまま使えます。
なぜなら資料の読み方も知らないバカの妄想にＩｎｔｅｌは付き合わないからだ。



つーかpopcntなんかののスカラ拡張命令も使えることは示唆されてるね。

LarrabeeはGPUとして以外にNehalem Xeon-MPのソケットそのまま刺さるモデルが
以前から提示されてたよ。
でもこれができるのはバイナリ互換が前提だろうから
SSE4.2までコンパチの線はありうる。

>>447
　　------------------
　　Larrabeeのパイプライン段数を推測するにはいくつかヒントがある。
　　------------------
自慢げなところ失礼すけど、既にAnandがインタビューで質問した記事を紹介済みすけど。。。
>>105
　　==================
　　5段のオリジナルPentium程じゃ無いけれど、16段のSilverthorneよりはるかに 「短い」とか。
　　==================

お題：LNIにおけるスカラ浮動小数命令

AVXのv****{ss,sd}をそのまま使いまわせね？
→ついでだからAVX全サポートすればよくね？

未だ早い。

ソフトが付いてこれないうちの実装は、単なる無駄飯食いにしかならん。

通りすがりの者だが
並列コードを生成するのは今時自動並列化コンパイラなりOpenMPコンパイラの役目だぞ
いまさらpthreadやWinthreadで直書きなんて滅多にしないし…
まさかアセンブラでわざわざ書くって話か？ごくろうさんなこった。
アセンブラで記述しても並列化スケーラビリティーに貢献無いから。

しかしなぜ空間内の座標の様に特に向きとノルム・次元を持たない
配列内の数値の並びもひっくるめてベクトルと書くかね

お呼びでないから帰れ

お前も呼んだ覚えはないが

>>d2JZ+pHY
DRF0みたいなものに言及するのはちょっと議論の方向がずれてると思うよ、
それでsyncやfenceより実装が楽になるわけじゃないでしょ？scatter/
gatherのconsistencyはそれはそれで面白いネタだが。

>>団子
SSE互換の有無については、結局願望レベルの根拠しか無いわけで、それで
他の人間を罵倒するのは下品。

>>447
Larrabee = P54Cベース説には、根強いものがありそうだな。
http://news.cnet.com/8301-13924_3-9985097-64.html
実ハードの動作周波数もわからんことだし、これも否定する根拠はなか
ろう。もしかすると、IBM ResearchのguTSからPower6につながる、ショート
パイプ＆高速クロック路線を追いかけようとしたのかもしれないし。
http://researchweb.watson.ibm.com/journal/rd/446/allen.pdf

>>456 お呼びでない

>>460
・OpenMP
これ割と性能タコだよ。
ゲームで言うとオブリビオンはOMPを使ってるが2コア程度までのスケーラビリティ
ロスプラは独自のマルチスレッドエンジンで高いスケーラビリティを得られてる。
アセンブラの利点は外部公開しない関数のコールのABIを好き勝手できることにつきる。
Cじゃ組み込み関数で頑張っても値のSIMDレジスタ渡しすら制限されるからね。

SSEサポートは願望じゃなくて、64ビット拡張をサポートする以上SSE2までは不可分なんだよ。
あとは歴史に照らし合わせた観測だよ。
・*fence命令
同期用命令に問題が有るなんて言ったら突き詰めれば
LOCKプリフィクス廃止しろとかそういうレベルになって
もはやx86を選んだ意味がないとかさ。
性能以前にまずコード資産だ。そこはゲルジンガーも言及してる。

・クロックレンジ
1.8〜2.5GHzと公表されてる。

ちなみに4GHzと言われてた時は32コアで各コア4DP/8DPだから
128ビットのFADD,FMUL各1基と見られてた。Atomみたいな。

・スキャタ／ギャザ
アクセスするキャッシュライン単位分だけクロックかかるって判明してるわけだし
「性能がすごすぎてSSEと共存できない願望」は既に打ち破られてるんだよね

複数キャッシュラインに作用する命令はアドレス下位からだな。
スキャタ・ギャザの場合、敢えて順序づけをするならLSUでの評価順で充分だ

・メモリコンシステンシ(笑)
つかFXSTORE/FXLOADみたいな全レジスタを退避・復帰の命令ですら
フェンス命令の副作用なんて起きないんだが

キューイング？なにそれ頭悪いの？的な。
メモリコンシステンシの問題なんてそもそも気にしなくていい

FXSAVE/FXRSTRでちた

>>460
やっと理解してくれる人が出てきてくれた(泣)

団子がフェンスは必須とうるさいので、話題がずれてしまった

リストベクトルの途中でページフォールトした場合、ハンドラ内でSSEのフェンス命令は実行できるのか？
アトミックなリストベクトル命令なんて実装も性能も悪化する
が、VPUをSSE互換にすれば、そうせざるを得ない

もちろんMMXユニットをSSE化すれば問題はない

VPUではフェンスではなくて、軽くて直接的な同期機構を用意するんじゃないかと思う
まあ願望レベルだけど、他のGPUにはいろいろ付いていた

いずれにしろ、アーキテクチャ定義の時点で厳しいモデルにすると、後々まで尾を引く
互換性に心をくだくゲルたんにとっても不本意の極みだろう

Larrabee固有の実装でSSEがないことのデメリットのほうを甘受するんじゃね？

ページフォルト(笑)とかｗｗ

新命令を用意して旧命令は非推奨にするってのがIntelのやり方だな
SSEに属する2,3命令のために200命令を越えるSSE*全体や、それに依存するx64基本命令セットまで禁止すべきというのはあり得ない解決手段。
2issueでストールしまくりのP5パイプラインをベースにしてる時点で1コアあたりの性能は妥協してると気づくべき。

旧命令を使ったら正常に動かないようなきついマイクロアーキの実装をすべきというのは
Intelとしては聞き入れない願望だし、まずこんなスレなんか見てない
だからやりたきゃ自分でASIC組んでろって言ってるの。
願望より現実を見ろ。
ハードもソフトも作らない奴のご高閲には価値はない。

IA32の実装においてLCPストールとかRAWハザード問題とか
継ぎ接ぎだらけの命令セットが災いしていろいろな弱点を抱えてるのは
確かなんだよ

根本から弱点を克服するにはx86命令セットそのものが病巣であり
後方互換の柵を捨て0からISAを定義するしかない。
でIntelが実現したのがIPFだ。

だがそれがどうなった？あの現状だ。
市場は後方互換を強く望んだ。


Larrabeeがx86をベースにした時点で、性能のために過去の資産を諦めるべきという思想は基本的に拒絶している。

「今までの命令も使えます。でも新命令使えばより速くなりますよ」
これだよIntelがx86で一貫してやってるのは

>>467
> ページフォルト(笑)とかｗｗ

(笑)にwwまでつけるところを見ると、
ページフォールトがアーキテクチャ設計においてどれだけ厄介なものか知らないようだな
やはりMACオタ並みの理解か

そして団子は己の願望を鸚鵡のように繰替えすのみ

>>460
　　--------------------
　　IBM ResearchのguTSからPower6につながる、
　　--------------------
下記のリンクで著者の名前を見比べれば判ると思うすけど、guTS/Rivinaのグループわ
ダイナミックサーキットによる高速化を研究していて、その後CELL/B.E.の設計に携わっているす。
消費電力削減を重視してスタティックサーキットで設計したPOWER6とわ関係無いす。
　- ISSCC98 プロセッサセッションプログラム: http://www.isscc.org/isscc/1998/digest/FP15.htm
　- IBM Joural R&D CELL特集号: http://researchweb.watson.ibm.com/journal/rd51-5.html
　- IBM Joural R&D POWER6特集号: http://researchweb.watson.ibm.com/journal/rd51-6.html

余談すけど、Intelも今回のIDFでNehalemでわ完全スタティック化したと語っているす。
http://intel.wingateweb.com/US08/published/sessions/TCHS001/SF08_TCHS001_100t.pdf (p.30参照)

>>469
だからIA64にでも夢みてろよ
x86であること自体が性能に対する最大の妥協であり同時に利点だ
トランジスタあたりの性能はおそらくCellに劣る。
それで一部でも後方互換を捨てたらゴミにしかならない。


ページフォルトなんて問題になるならとっくの昔に破綻してる

お前が無知なだけでx86は1命令で複数のアドレスに作用する命令なんて大昔から存在してるからな。
スキャタやギャザの命令追加ごときで何で今更ページフォルトとかメモリコンシステンシ云々の問題になるのか。

これからもSSEで組めますよって言ってるのに
これまでSSEで組んだものは動きませんよなんて
互換性あるのかなあ。

>>472
> お前が無知なだけでx86は1命令で複数のアドレスに作用する命令なんて大昔から存在してるからな。

やっぱりわかってねーな
ストリング命令なんかは最初からアトミックな動作をしなくていいんでね

movsb,movsdなんかはREPプリフィクスを付けてCでいうmemcpyを1命令でやるもので
VCなんかではmemcpyを未だにこの命令に展開する。
でも今じゃSSE*を使った実装と比べてもゴミ性能。
さらにキャッシュを汚しまくるからストリームを扱うようなプログラムでは
パフォーマンスに著しく悪影響を与える。

でも残してるんだよ。もちろんLarrabeeにも載るんだ。

同期のときにたまに使うかどうかのフェンス命令なんかより
memcpyのほうがよっぽど高頻度で使われる可能性高いからね。
こんな命令がごろごろあるのがPentiumでありx86。

SSEの資産が使えないと必然的にPentium時代の資産を使う羽目になるけどどうよ？


SSEをくだらない理由で否定するならx86そのものを否定しないといけなくなるよ。

べつに団子に恥をかかせるのが楽しいというわけじゃないんだが

> でも残してるんだよ。もちろんLarrabeeにも載るんだ。

そりゃスカラ命令だから残すだろう

> SSEの資産が使えないと必然的にPentium時代の資産を使う羽目になるけどどうよ？

資産って何だよ
ToHeartでも遊ぶのか？

既存のSIMD命令200命令以上と共存できない実行スタイルの実装の命令を搭載したい理由って何？

後藤すら「SSEの延長でOpcodeさえ重ならなければ既存命令命令と共存できる」と訳してるのに

なに？Opcodeをオーバーライドでもするの？死ぬの？

16のキャッシュラインの読み書きには16クロックの間
LSUを使うと言ってるのはIntelなんだけど
それっ既存命令とどう違うの？
というより、どう違ってほしいという願望があるの？
お前の見解がIntelと一致してる確信はあるの？
またその根拠は？

性能云々はいいよ。
Intelが性能を優先して互換を捨てたCPUの末路は全て知ってる

>>477
> 既存のSIMD命令200命令以上と共存できない実行スタイルの実装の命令を搭載したい理由って何？

おれの話をちょっとは聞けよ

LNIとSSEは共存できるよ

「Larrabeeでは」コストが高すぎて共存させないだろう

ということ

>>477

> 16のキャッシュラインの読み書きには16クロックの間
> LSUを使うと言ってるのはIntelなんだけど
> それっ既存命令とどう違うの？

10のキャッシュラインで済む場合は、10クロックで済むとも言ってるよな

> お前の見解がIntelと一致してる確信はあるの？
> またその根拠は？

あるけど団子にでも理解できるような説明は難しい
おいおい説明する


ところで団子よ
scatter命令で、最初のアドレスはオンメモリ、二番目のアドレスはページテーブル外だったとするよ
そうすると、最初の要素はメモリにストアされていると思うかね？

64ビット拡張は載るって言ってるのに？
先行して64ビットのコード資産を蓄積してる本命のHPC市場を捨てるのか？
SSE抜きは既にx64ではない。



ああLSUを変態にする前提でのコスト問題は無意味。
変態である前提が既に成立してないし。

>>480
> 64ビット拡張は載るって言ってるのに？

どのみちアドレスが32ビットでは足りないからね

> 先行して64ビットのコード資産を蓄積してる本命のHPC市場を捨てるのか？

市場は捨てないがコードは捨てる

> ああLSUを変態にする前提でのコスト問題は無意味。
> 変態である前提が既に成立してないし。

お前、人の話を聞く気がないのなら
> LSUを使うと言ってるのはIntelなんだけど
こんな話を持ちだすな

どうでもいいけど両方ちゃんとコテトリつけとけよ

>>482
つけないのがおれの主義

ページフォールトハンドラ内では当然共有データのページテーブルを更新するだろう
なのでフェンス命令は必ず実行される

さて
scatter命令で、最初のアドレスはオンメモリ、二番目のアドレスはページテーブル外だったとする
最初のデータをメモリに反映してしまうと、一部だけストアされた中途半端な状態でフェンス命令を実行することになり、意味論的に誤った動作になる

scatterの全てのメモリアクセスをバッファリングしておいて、すべてのアドレスがページインした状態を保証してからバッファを書きだすと
意味論的には正しいが、バッファリングのコストと、実際のストアまでの余計な遅延がある

>>479
＞ 10のキャッシュラインで済む場合は、10クロックで済むとも言ってるよな

それは一度も否定してない。
やることはシャッフル＋MASKMOV*みたいなもんだろ

＞ scatter命令で、最初のアドレスはオンメモリ、二番目のアドレスはページテーブル外だったとするよ
＞ そうすると、最初の要素はメモリにストアされていると思うかね？


妄想は勝手だが空論

それはプログラミング・リファレンスが公開されてからだな。

ページアドレス境界をまたげる仕様になってるか、
そもそも命令の仕様すら俺は知らない。
知ってるなら最低でも命令ニーモニックくらいは知ってるだろ？
だからお前は妄想前提だと言ってるの

例えばだが、L/S先に指定するアドレスはR/M＋SIB＋DISPに対するオフセットとして
そのオフセット値は前後○バイト以内


なんて制限のある仕様だったらどうする？

＞ > 先行して64ビットのコード資産を蓄積してる本命のHPC市場を捨てるのか
＞
＞ 市場は捨てないがコードは捨てる

無理だな。
HPC用に用意されるソケット版はXeonとプラットフォーム互換で、QPIで相互インターコネクトされる。
むろん、混成も考慮されてる。
OSを含めx64のコードがLarrabeeで実行できるだろう。

OSも含めLarrabee専用に書き直すのか？
それができるならx86の64ビット拡張は今頃AMD64とYamhillで分裂してるよ。ばかめ。

>>485
> ページアドレス境界をまたげる仕様になってるか、

ページ境界をまたげないリストベクトルがどれだけ実用的か、使った経験があるキミならわかるだろ？
x86のページサイズは4KBだったな
ジャイアントページにまけてやってもいいぜww

>>486
> HPC用に用意されるソケット版はXeonとプラットフォーム互換で、QPIで相互インターコネクトされる。

だからそれはLarrabeeじゃねえって何度も言ってるだろ

Larrabeeのx86命令互換性でモメてるみたいすけど、論文でわ要リコンパイルと書いてあるす。
完全互換でわ無いんじゃないすかね。。。 (p.10, 6.1節参照)
　　-------------------------
　　Central to Larrabee Native programming is a complete C/C++ compiler that statically compiles
　　programs to the Larrabee x86 instruction set.Many C/C++ applications can be recompiled for
　　Larrabee and will execute correctly with no modification.
　　-------------------------

>>487
良い答えだ。

4KBなら64byteのキャッシュラインなら64エントリ相当だな。
案外その範囲内かもしれないよ？


おっと、断定してかかるのは命令の仕様が判明してからにしな。

>>488
　　-------------------
　　だからそれはLarrabeeじゃねえって何度も言ってるだろ
　　-------------------
ネタバレ度が高かった"Tera Tera Tera"プレゼンに登場しているすから、あながち間違いでわ無いす。
しかし、あの構成図でもXeonと混在させていなかったのわ注意点なのかもしれないす。

>>488
ソケット版もGPU版も同一コア設計の派生物だ。
資料くらい全部目を通せ。

>>487
canとmustの違いって知ってる？中学生くん。

>>489
混在が無理なら無理でOSをLarrabeeで動かせる仕様でないといけないけどな

レス番が2つずつずれた

>>494
この場合の"can"わ、頭の"Many"と対応して『リコンパイルしても動かないプログラムが存在する』
ことを意味しているす。

ついでに言えば、最初のパラグラフの"statically compiles"というのわ、"-axP"のような形で
汎用x86コードと最適化コードが混在できない可能性があることを示している可能性もあるす。
その場合、どういう原因でそうなるか良く判らないすけど。。。　64-bitしかサポートしないとか？

ｰQax*はブランチする命令を吐くぞ
専用コードを吐くのはｰQx*

>>496
微妙に意図が伝わっていない様す。
勘違いでなければ、ブランチでコードパスを分けるという当たり前の手法が
『使えない可能性がある』というのわ、何が原因か？という疑問なんすけど。。。

"Larrabee x86 instruction set"という聞き慣れない言い回しも微妙すけど、過度に
妄想を逞しくするのわヤメておくす。

どいつもこいつも可能性を前提とした断定はやめんかｗｗｗ

動かない可能性のあるコード・・・
AESやCLMULは現行ICCで先行対応してるけど、
たしかにLarrabeeでは未対応かもしれないね

ICCは独自のCRTスタートアップにCPUID値によって関数テーブルを追加する

LarrabeeはFamily=5だとして
x64としては今まで存在してないパターンだから例外になるとか？
32ビットだけどLinuxはFamily=6だとCMOVが無条件で使えると判断する
一部互換メーカーのCPUで使えないとかのバカ仕様だったことがあるが似たような問題かな？




x64非互換だといきなり「対応OSがない」。
じゃあIntelがOSを用意するの？

Linuxなら対応するかもしれないが、それならそれで
kernel.orgあたりにそろそろコードがあがってないといけない。

ICCは独自のCRTスタートアップにCPUID値によって関数テーブルを追加する

LarrabeeはFamily=5だとして
x64としては今まで存在してないパターンだから例外になるとか？
32ビットだけどLinuxはFamily=6だとCMOVが無条件で使えると判断する
一部互換メーカーのCPUで使えないとかのバカ仕様だったことがあるが似たような問題かな？




x64非互換だといきなり「対応OSがない」。
じゃあIntelがOSを用意するの？

Linuxなら対応するかもしれないが、それならそれで
kernel.orgあたりにそろそろコードがあがってないといけない。

>>499
　　------------------
　　LarrabeeはFamily=5だとして
　　x64としては今まで存在してないパターンだから例外になるとか？
　　------------------
確かに『リコンパイルが必要』と明記される理由わ、その程度である可能性もあるす。

HPC Platform Building Blocks
http://sylphys.ddo.jp/upld2nd/pc3/src/1219569702512.jpg

でさ、scatter/gather命令の仕様なんだけどさ

A：命令列に16要素すべてのアドレスを含める
B：ZMMレジスタの各32ビットにアドレスのオフセットを入れて実行ステージで評価する。
C：それ以外

Aはx86の命令長は15バイトという規格上限を超えるだろうし1要素4ビットくらいに
圧縮して無理やり収めても命令フェッチ帯域の制限に引っかかって遅くなりそう。
だからB案かなと俺も思ったんだけど、たかが2命令のために用意する機構としては
Execute段でやる作業があまりに高価すぎる。スモールコアに収まりきるのか？

でさ、よくよく調べるとIntel曰く、これらの命令の目的は「AoSとSoAの相互変換」と説明してる。

AoSってのは構造体配列のことね。こんなの
struct Dangoyasan { int a; float b; Double c; } umee[1024];

で、どうやらscatter/gatherの役割はこんな構造体から各要素のたとえばaだけを取ってきて
Vectorレジスタに格納したり、逆に格納したりすることなんだよね。

構造体のサイズと、要素のデータサイズさえデコード時点でわかれば、
そもそも16個独立にアドレスを指定できる必要はないんだ。

(Prefix) Opcode ModRM (SIB) (DISP8|32) (imm8)
という従来のSIMD命令の命令エンコーディングの延長でいいじゃないか。

AoSの先頭アドレスをR/M＋SIB＋DISPで指定。
imm8でメンバのサイズと構造体のサイズを指定する。

この仕様ならマイクロコードROMの参照だけで、必要なマスクを生成でき
Executeステージで評価する必要がなくなるので負担も軽くなる。

で、imm8のうち2ビットで、データのサイズが8bit/16bit/32bit/64bitかを扱う。
残りを構造体サイズとし、6ビットを割り当てる。1〜64バイトを表現できる。
構造体は4バイトアラインメント前提だろうから4〜256バイトとしてもいいかもね。

とすればどうやら取得範囲は4KB以内にすら収まっちゃいそうですね。
ページフォルトは起こったとして1回起きるか起きないかだね。
確率的にrep movs*よりもページフォルト頻度は少なそうだ。


さて、SSEを禁止にしたい理由（笑）ってなんだっけ？

>>503
　　---------------------
　　struct Dangoyasan { int a; float b; Double c; } umee[1024];
　　---------------------
double matrix[i][1000][1000] といったアクセスにも使う様す。

>>503
とりあえず、定ストライドアクセスはリストベクトルとは呼ばない

インテル論文 3.3
> Instead of loading a 16-wide vector from a single address,
> 16 elements are loaded from or stored to up to 16 different addresses that are specified in another vector register.
> This allows 16 shader instances to be run in parallel, each of which appears to run serially,
> even when performing array access with computed indices.

最後の行重要

>>504
Array of Arrayね。そっちもあったか。
けど、そんなでかい配列どうやって扱うんだ？

要素のサイズは、それごとにOpcodeを割り当てれば
imm8が丸々浮く。それでも8ビット。足りるか？

immを32ビットにすればいい？デコーダの解釈が難しくなる。
SSE4やAVXですらimm32をとるSIMD命令は存在しない。

オフセットはどこまでいけるみたいな情報あった？

>>505
で、[リストベクトル]の単語はどこに出てくるのかな？

*fenceでシリアル化すると起きる問題について聞きたいな
LSUがメモリにアクセスする順で順序づければいい話だよな。
なんの問題があるの？

ああ、それより固定ストライドでない証拠おねがい。

どっちにしてもSSE非互換にしなければならない理由がないがな。
絶対互換でなければならない理由は説明した。x64の件ね。

x64非互換の64ビットってある意味ではCellより厄介な代物になるってことわかってる？
Cellの場合、OSが直接触るのはPPEだけで、良くも悪くも64bit PPCのISAだけだったからそのまま動いた。
SPEもファイルシステム扱いするだけでよく、それで最小限の対応で済んだ。
OSを1から書かなきゃいけないってのは、PCでの失敗は約束されたようなもんだ。

SSEに対応しないというのはお前が思っている以上に深刻な問題を起こす。


「*fence使っても問題のない仕様にすればいい」という発想に
君はいつ切り替えてくれるの？
IntelはSSEを禁止することなど最初から考えてないと思うけど。

>>506
>けど、そんなでかい配列どうやって扱うんだ？

そんなでかい配列www

>>507
> で、[リストベクトル]の単語はどこに出てくるのかな？

もしかして団子はリストベクトルを知らない？？


>>508
頼むから人の書き込みを読んでくれよう

> *fenceでシリアル化すると起きる問題について聞きたいな
>>484

> ああ、それより固定ストライドでない証拠おねがい。
>>505

>>505よく読んだら吹いたｗｗｗｗ

> インテル論文 3.3
> > Instead of loading a 16-wide vector from a single address,
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　~~~~~~~~~~~~~~~~~
これ訳してみて。


あとなんか言いたいことあるなら聞くよ？

>>506
　　-------------------
　　オフセットはどこまでいけるみたいな情報あった？
　　-------------------
4-byteの筈す。(p.4参照)
　　===================
　　16 elements are loaded from or stored to up to 16 different addresses that are
　　specified in another vector register.
　　===================
『各要素の4-byteオフセット？を持った、別のレジスタを元にアクセスする』とあるす。

読めば判るように32-bitアドレシング可能であれば、固定ストライドである必要わ無さそうす。

> > *fenceでシリアル化すると起きる問題について聞きたいな
> >>484

君が*fence命令の動作をよくわかってないことがよくわかった。
仕様書嫁っていってもわからないんだろうね。
オープンソースのx86シミュレータがあるから動きをトレースしてごらん。
なんなら君の思う仮想scat命令を実行できるように改造して実行してみればいいよ
根本的な間違いについてわかるから。



あと、
とりあえずマルチスレッドプログラム書いたことがないことがわかったよ。
タイムリミットも過ぎたし。

>>510
> > > Instead of loading a 16-wide vector from a single address,
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　~~~~~~~~~~~~~~~~~
> これ訳してみて。

16要素幅のベクトルを一アドレスからロードする「かわりに」、


> あとなんか言いたいことあるなら聞くよ？

今だいぶ恥かしいでしょ

>>511
＞各要素の4-byteオフセット？

ここは4バイトフルに使うかはわからんよ。
AVXの仕様書見てても、シャッフル命令でなんで各要素のビットをフルに使う仕様にしないの？
みたいなのはあるからね。vpermil2psとかかなりスカスカになってる。
各要素値を評価する命令があるってことは、つまりvpermil2psみたいなリッチなシャッフル命令も
同時にサポートされる可能性も高いね。2命令のためとしては無駄すぎるから。

で、あの電波さんの件

CPUID命令って、CPUのバージョンやベンダー名、対応命令を取得するだけでなく
副作用としてフェンスする効果もある。
CPUIDからeax:edx:ecx:ebxを汚さず、フェンス機能のみを使うのが、*FENCE

*FENCEが動作に干渉する命令は当然CPUIDを使っても干渉する。

各命令の動きはこのへんが詳しい
http://download.intel.com/jp/developer/jpdoc/IA32_Arh_Dev_Man_Vol3_i.pdf


LarrabeeレポートにはPentiumの全命令をサポートするとあるから
CPUID命令も当然載るわな。

改めて聞くけど、なんでSSEを禁止しないといけないの？

>>513
勝利宣言はいいからさ、

団子のLarrabeeでは、scatter命令の実行中にページフォールトが起きたら、当該命令の実行はキャンセルされるの？されないの？
それとフェンス命令は低コストで共存できるの？
できるならそのメカニズムは？

ページフォルトで命令キャンセルなんて聞いたことがない

>>514
　　---------------------
　　今だいぶ恥かしいでしょ
　　---------------------
ちゃんと論文読んでない団子さんも悪いすけど、ちゃんと>>503の『B案』で正しい推測をしているす。
私わ今回のフレームの展開を良く把握してないすけど、この段階で論文の記述を教えてあげない
のわ、あなたも単に議論が下手なんでわ？

7.4. シリアル化命令
IA-32 アーキテクチャでは、いくつかのシリアル化命令を定義している。これらの命
令は、前の命令がフラグ、レジスタ、メモリに対して行う変更のすべてが完了し、バッ
ファに入っているすべての書き込みがメモリに排出されてから、はじめて次の命令を
フェッチして実行することをプロセッサに強制する。例えば、制御レジスタ命令に対
してMOVを使用し、制御レジスタCR0に新しい値がロードされて保護モードがイネー
ブルにされると、プロセッサは常に、保護モードに入る前にシリアル化命令を実行し
なければならない。このシリアル化操作によって、プロセッサが実アドレスモード
だったときに開始されたすべての操作が完了してから、保護モードへの切り替えが行
われることが保証される。

次の命令はシリアル化命令である。
･特権シリアル化命令 − MOV（制御レジスタへの）、MOV（デバッグレジスタへ
の）、WRMSR、INVD、INVLPG、WBINVD、LGDT、LLDT、LIDT、LTR。
･非特権シリアル化命令 − CPUID、IRET、RSM。
･非特権メモリ・オーダリング命令 − SFENCE、LFENCE、MFENCE。

>>517
　　---------------------
　　ページフォルトで命令キャンセルなんて聞いたことがない
　　---------------------
普通にページフォールトわ割り込みの要因す。

あまりにも普通の話なので、ソースわWikipediaす。
http://ja.wikipedia.org/wiki/%E5%89%B2%E3%82%8A%E8%BE%BC%E3%81%BF

ミスアラインメントロード・ストアやってればページをまたがる事だってあるはずで
何でそれが問題なのかね。

>>518
> ちゃんと論文読んでない団子さんも悪いすけど、ちゃんと>>503の『B案』で正しい推測をしているす。
> 私わ今回のフレームの展開を良く把握してないすけど、この段階で論文の記述を教えてあげない
> のわ、あなたも単に議論が下手なんでわ？

B案で(捨てたとはいえ)正しい推測をしているし、おれも散々この論文は引用しているから、
団子が誠実ならこの論文は読んでいるはずで、実際に読んでいるだろうと思っていたのだが

> > > Instead of loading a 16-wide vector from a single address,

議論の勝ち負けに目が眩んでこんな英文すら読めなくなっているのをひやかしているだけだよ

まあ、団子やMACオタ相手に議論する立場にもなってみてくれww

>>523
CPUIDについて弁解よろしく

再三書いているようにこのフレームの展開を把握してないすけど、問題になっているのわ
下記のどれなんすか？
　・メモリページの境界
　・TLBミス
　・ディスク上の仮想記憶へのスワップ

>>525
> 　・ディスク上の仮想記憶へのスワップ

一般的な、ページフォールトの話
scatter命令の実行中でページフォールトを起こすとどうなるか？という話だ

>>523
　　-------------------
　　MACオタ相手に議論
　　-------------------
いま議論しているつもりわ無いし、名乗らない以上、記憶にも無いす。どの話の名無しさんすか？

>>526
　　------------------
　　一般的な、ページフォールトの話
　　------------------
一般的にと言われても、上から順番に重篤度が全然違うような。。。

CPUIDから逃げるな

CPUID命令も禁止！メモリをシリアル化する命令はすべて禁止！

って言っていいよ。
それ既にx86じゃねーけどよ

>>529
団子さんにも>>525のどれをイメージしていたか教えて欲しいす。

CPUID命令も禁止って言い出しても、それはそれで笑えるからいいや
SSEも*fenceだけ禁止にすればいいんじゃねって話になるけど

>>528
まあ、ROBを理解していないMACオタの言うことだから大目に見てやるけど

そもそもROBというものはページフォールトを正しく扱うためにあってだな…

>>531
っていうか
rep movs*でもいちおうアドレス空間全部舐めれるわけだよな？
スキャタ・ギャザー命令も結局rep mov*でも舐めれる範囲のメモリの一部にアクセスするだけだろ？
スキャタ・ギャザー命令だと何で干渉するのか俺はいまだに理解できない。

CPUID命令の効果な〜に？>>533

>>534
だからストリング命令は遅いだろ

CPUIDについて答えてよ

*FENCE禁止してもCPUID発行してもメモリオーダリング制御やっちゃうけど、どう思った？

答えられないだろ？


だから最初に言ったんだよ
「効率のためにx86アーキテクチャ禁止！」
っていう羽目になるって。

>>538
意味がわからん
とりあえず主語を書いてくれ

*FENCE命令を発行することによりスキャタ・ギャザ命令の発行に障害を与えるなら
それはCPUID命令を発行しても同じということ。

*FENCE命令を禁止するためにSSE全部を禁止しろっていうなら
CPUID命令を発行できるPentium ISA自体全部禁止になる。

＞だからストリング命令は遅いだろ

ならスキャタ・ギャザーも遅ければいいじゃん？

>>542
> ならスキャタ・ギャザーも遅ければいいじゃん？

ベクトル機の経験くらいはあるかと思ったが…

>>533
　　---------------------
　　ROBを理解していないMACオタ
　　---------------------
キチガイのヒトの『シリコンの質』を真に受けちゃったお馬鹿さんすか。。。たしか当分出てこない
と宣言してたのでわ(笑)
http://pc11.2ch.net/test/read.cgi/jisaku/1209622524/592
　　=====================
　　592 名前：Socket774 投稿日：2008/06/20(金) 19:32:03 ID:jH6om3H6
　　　　1〜2年後には笑い飛ばしに来てやるから、まこの気が変わってないことを祈るよ。
　　=====================

IA32のVol.3読んだことない子相手にしても無駄なんだけどさ

パイプライン段数分バッファに貯めないといけない(>>377)とか言ってる時点で
シリアル化時のパイプラインの動作をまったく理解してないし




ゴミの栄光の勘違いの歴史ダイジェスト

>>377
> 1命令で16要素のメモリアクセスするから、スレッド数にあわせて4段のパイプラインだと、
> 全部で64アクセスをバッファにためないといけない

>>420
> リストベクトルなんて有名な性能ボトルネックじゃん
> リソースの投入し甲斐のある箇所だよ、ベクトル機みたいにね

>>420
> ？？意味がわからん
> リストベクトル命令もパイプライン化されてるだろJK

>>543
そもそもの前提としてLarrabeeはベクトル機である必要がない。

「Larrabeeはベクトルコンピュータだ！」と思い込みから「SSEは禁止！」への飛躍はさすがだったよ。



さっさとCPUIDは禁止って言ってよ早く

CPUIDも使えない！って言ってもいいんだけどね。
それを、MACヲタが言ってた既存のディスパッチコードが正常に使えない？云々の理由にしてしまう手があるよ。
それはそれで論外な気がするけど。





なんかレスに勢いがないぞ？

ひょっとしてこれ顔真っ赤にしながら読んでる最中？
http://download.intel.com/jp/developer/jpdoc/IA32_Arh_Dev_Man_Vol3_i.pdf

>>545
> パイプライン段数分バッファに貯めないといけない(>>377)とか言ってる時点で

そんなことは言ってないが

> 1命令で16要素のメモリアクセスするから、スレッド数にあわせて4段のパイプラインだと、

これは一例だよ…
まあ、わかりづらかったかな

>>546
> そもそもの前提としてLarrabeeはベクトル機である必要がない。

…

>>547
> 「Larrabeeはベクトルコンピュータだ！」と思い込みから「SSEは禁止！」への飛躍はさすがだったよ。

団子の理解力のなさはアーキテクチャの話だけじゃないのか

「VPUをSSEコンパチにするのは大変なので、アーキテクチャの要件には含めず、Larrabeeでは実際に実装もされないだろう」
という話

>>548
GPUや数値計算でCPUID命令が最内ループに出てくるんならね…

>>548
火病っても>>503-514あたりの書き込みわ消えないすけど。。。

> >>545
> > パイプライン段数分バッファに貯めないといけない(>>377)とか言ってる時点で
>
> そんなことは言ってないが

自分の書いたレスを透明あぼーんでもしてるの？頭悪いの？
↓
> LarrabeeにはScatter/Gatherがあるだろ、
> 1命令で16要素のメモリアクセスするから、スレッド数にあわせて4段のパイプラインだと、
> 全部で64アクセスをバッファにためないといけない





＞GPUや数値計算でCPUID命令が最内ループに出てくるんならね…

最内ループに使わなければOK
はい？それは*FENCEでも同じことだな。そもそもどれもそんなに高頻度で呼ぶ命令ではない。

疲れたから今一度、「IntelがSSEを使えなくしたい」（とお前が思い込んでいる）理由を、
CPUID命令が存在することを前提に纏めておいてよ。

質問を変えようか？
俺が指摘するまで、CPUIDにはFENCE命令と同じ副作用があることを把握していたか？

> LarrabeeにはScatter/Gatherがあるだろ、
> 1命令で16要素のメモリアクセスするから、スレッド数にあわせて4段のパイプラインだと、
> 全部で64アクセスをバッファにためないといけない


これが馬鹿だなーって言った理由は、パイプライン段数の問題じゃないよ。
段数分のアクセスのバッファ（笑）そのものが必要ないからだよ。
フェンス時の動作を正しく理解してるならね。


SSEが実装されるまでCPUIDの副作用はフェンス目的で使われてきたし
SSEが使えないならCPUIDでフェンスするだけの話なんだよ。

>>553
　　-------------------
　　段数分のアクセスのバッファ（笑）そのものが必要ないからだよ。
　　-------------------
相変わらず揉めてる内容が理解できないすけど、未完了のロード/ストア命令わキューに
詰め込まれて、一杯になってしまうとパイプラインを停止せざるを得ないという話じゃないすか？

CPUID命令がメモリから設定値を読むとも思えないすからLSQに関係あるとも思えないすけど。。。

>>554
命令がフェッチされてからリタイヤするまで後続命令がパイプラインに投入されないモードになるから。
パイプラインがパイプラインでなくなる。

しかも、そのスキャタ・ギャザー命令の実行自体、LSUが１基だから2つ以上のキャッシュラインに同時にアクセス
することはできないし。
フェンスしようがしまいがキャッシュライン単位で逐次ストアすることには変わりない。
マクロ命令だろうからデコード自体も相当遅いだろうし。

リストベクトル（笑）幻想って何だったの？死ぬの？

>>555
　　------------------
　　命令がフェッチされてからリタイヤするまで後続命令がパイプラインに投入されないモード
　　------------------
ご存知のようにPowerPCでもMSR等の特殊レジスタを読み書きする命令でわ、そうなるす。
ユーザープログラムに使われる普通の命令とわ、話が別でわ？
　　-------------------
　　しかも、そのスキャタ・ギャザー命令の実行自体、LSUが１基だから2つ以上のキャッシュラインに
　　同時にアクセスすることはできないし。
　　-------------------
そういうレイテンシを隠蔽するためのマルチスレッドとユーザー制御のスケジューリングなんだと
思われるす。

ピーク性能ではGPUメーカーには太刀打ちできないんだから、
既存コードの移植のし易さを全面に押し出さないと勝てる要素がない。
そもそも移植性を無視して性能重視するならx86継承するはずないし、
殆どのコードが動くしOSも走りますよというくらいなんだからSSE命令は必ず解釈できるようにするだろ。

もしSSEフルセットが載らなかったらララビーは沈没するだろうし、
ベクトルユニットの実験台でしかありませんてメッセージだろうね。

＞ご存知のようにPowerPCでもMSR等の特殊レジスタを読み書きする命令でわ、そうなるす。
それはIntelにも専用命令がある。特権命令だけど

＞ユーザープログラムに使われる普通の命令

CPUIDって特権命令じゃなくてユーザーモードで使えるんすけど。。。

フェンス機能はあくまで副作用だけど、当時はCPUID以外にフェンスする命令がなかったので
副作用を生かして同期をとることが推奨された。
*FENCEは目的を絞った命令なのでCPUIDを使うより高速。

>>557
　　----------------------
　　殆どのコードが動くしOSも走りますよというくらいなんだから
　　----------------------
『殆どの』の範囲わ判らないすけど、OSわSIMDどころかFPUも使用しないす。
逆に新レジスタを定義してしまうと、タスクスイッチの際にレジスタの内容を退避するための変更が
必要になるす。

>>558
　　-----------------
　　当時はCPUID以外にフェンスする命令がなかったので副作用を生かして同期をとることが推奨された。
　　-----------------
PowerPCのeieio, sync, isyncの類なのわ判ったすけど、こちらわメモリのオーダリングが最初から
緩いす。
x86でインオーダーのLarrabeeコアでも必要なんすか？

>>552
CPUID等の直列化作用のほうをVPUには緩めると思う
が、直列化以外の意義のないフェンス命令はナンセンス

>>554
> 命令がフェッチされてからリタイヤするまで後続命令がパイプラインに投入されないモードになるから。

> マクロ命令だろうからデコード自体も相当遅いだろうし。

こんな性能的にクリティカルな命令をそう言ってくれるとは、メーカーの設計者が泣いて喜びそうだ

>>560
メモリのオーダリング制限に関する資料す。
http://www.u-aizu.ac.jp/~minyi/course/paraarch2003/amano-3-2.pdf

>>559
AVXのYMMレジスタはXMMレジスタを引き伸ばすことで対応してるね。
OS側は大幅な変更は必要ないはず。
Intelの公表が早かったのも良し。


しかし基本命令に組み込まれちゃった命令はその限りじゃないよ。SSE2まではx64の基本命令だ。
「64ビットなのにXMMレジスタがありません」は変更どころの問題じゃなくなる。
XMMがあることを前提に組まれてたコードモジュールが使えなくなるわけだからね。

>>563
　　---------------
　　OS側は大幅な変更は必要ないはず。
　　---------------
僅かな変更でも動かないことに変わりわ無いす。
　　---------------
　　「64ビットなのにXMMレジスタがありません
　　---------------
それだけならSSE"2"わ不要で、SSEで良いのでわ？

>>561
CPUID等の直列化作用のほうをVPUには緩めると思う

それは絶対に無理ですね。
ユーザーモードで唯一マシン特殊レジスタにアクセスできる命令というか
特権命令をユーザーモードに開放したようなもんだから。
主作用がマシン特殊レジスタへのアクセスである以上、フェンスの副作用は必ず発生する。



まあできるとして
フェンス命令から直列化作用を消す→nop命令として扱う
ってすれば、SSEを禁止しないといけない理由なくなるよ？



そもそもフェンス命令なんて頻繁に呼ばないからパフォーマンスに影響するわけないだろ

ところでSSE『禁止』とかいう話わ、どころから出てきたすか？　単にサポートされないかも
しれないという話じゃ無くて。。。

>>564
OSのバイナリコードの中でSSE2コードを使ってないことが保障できるならね。
現行のコンパイラはx64では無条件でarch=SSE2スイッチが入る

>>567
　　-------------
　　現行のコンパイラは
　　-------------
既出のように(>>489)、Intel自身が要リコンパイルと書いているす。

>>565
> 主作用がマシン特殊レジスタへのアクセスである以上、フェンスの副作用は必ず発生する。

だからそれはスカラユニット的には、従来通りでよろしい

> フェンス命令から直列化作用を消す→nop命令として扱う

これこそ互換性がないぞ…

MMXユニットを拡張してSSEユニットにするという話なら十分あり
あくまで、VPUでSSEを実装するのが難しいんじゃないかという話だよ

>>566
団子の妄想

ただ、LNIのメモリコンシステンシーモデルはSSEよりも緩める可能性が高いとは考えている
最初に厳しいモデルを定義しちゃうと後で苦しむからね

実装は別

>>568
それはそれでIntelがコンパイラを提供しないOSは市ねということになる

もっとも新しいOSであるVistaですらSSE2を使っていないのわ、C3をサポートしていることからも
判るす。
http://www.viatech.co.jp/jp/products/processors/
　　------------------
　　800ＭＨz以上のVIAプロセッサは、Microsoftによって Windows Vista Capable PCにおける
　　プロセッサ オプションとして承認されています。
　　------------------

>>569
＞だからそれはスカラユニット的には、従来通りでよろしい

スカラもベクタもフロントエンドステージは共用なんだけど？
そもそもデコードどころかフェッチもしないうちににスカラかベクタかわかるの？頭悪いの？
それ以前に特殊レジスタアクセス時に投入できるとか


> > フェンス命令から直列化作用を消す→nop命令として扱う
>
> これこそ互換性がないぞ…

SSE非対応CPUを考慮したコードでは、CPUIDは同期用として使われてる。
CPUIDから副作用がなくなればそれこそ互換性がなくなる。


> ただ、LNIのメモリコンシステンシーモデルはSSEよりも緩める可能性が高いとは考えている

考えるな。お前の考える常識はx86の非常識

> 最初に厳しいモデルを定義しちゃうと後で苦しむからね

厳しいモデルの塊x86へようこそ。
もうどこ手を入れてもボトルネックだらけだよ。
LNIでどうしようと基本命令セットに厳しい制約がある。

x86を選んだ時点で制約を受け入れるしかない。

>>571
C3はP6命令すらサポートしてないし。
P5互換でもWindowsは動くな。

>>570
　　---------------------
　　それはそれでIntelがコンパイラを提供しないOSは市ねということになる
　　---------------------
gccで問題あるすか？オープンソースだし。
http://oss.intel.com/en-us/projects/
　　=====================
　　Intel is also engaged in the Open Source Development projects for tools such as Java
　　Harmony, GCC optimizations and Eclipse.
　　=====================

>>571
それは32ビットだからだろ。
64ビットじゃありえない。
ちなみに486なんかは2000あたりから切り捨てられてる。CPUIDやRDMSRは使えることが前提。

CMOVもSSE2も基本命令セットだから存在してない。
命令が増えるはカーネルだけの対応でいいけど、減るのはカーネルだけじゃ済まされないからね。

ベクトルマシンへの願望は、IA64ベースのItanee（仮）でも出るときにやってくれ

厳しいモデルとは言うけど厳しいのはそれ以前にダイサイズとTDPの制約ですので。
後になって1コアをこれ以上拡張する改良を加えるくらいならコア数を増やすだろうしね。

×CMOVもSSE2も基本命令セットだから存在してない。
◎CMOVもSSE2も基本命令セットだから、SSE2やCMOVを使わないx64のCPU実装は存在してない。

>>575
　　----------------
　　64ビットじゃありえない。
　　----------------
元々FPU使わないすから、x87がSSE2に置き換わっても影響無いす。
　　----------------
　　ちなみに486なんかは2000あたりから切り捨てられてる。
　　----------------
http://jp.youtube.com/watch?v=nUH7eTwFbRs

>>578
いや動く云々はいいけどさ。
32ビットならLinuxはi686でビルドされたやつは586以前では動かない。

本当にSSE*が動かなくてOSが動かない可能性があるのは64ビットでの話。

つーか彼はフェンス命令が100命令に1回程度でも呼ばれると思ってるのだろうか？
そんな論外だろ。

不必要に同期を行わないのはどんなCPUでも同じ。
Larrabeeじゃなくてもね。

どのみちストールしまくるLarrabeeよりむしろ4issue OoOのCore 2なんかのほうが影響は大きい。

なんという三つ巴の争い。


いいぞもっとやれ。

>>572
> スカラもベクタもフロントエンドステージは共用なんだけど？

それが何か問題なの？
VPUのメモリアクセスについては、CPUIDや他の命令は必ずしも逐次化しない
ということなんだけど

> SSE非対応CPUを考慮したコードでは、CPUIDは同期用として使われてる。

そんなコード、Larrabee動かしてどうしたいだよ
やっぱToHeartか？

> 考えるな。お前の考える常識はx86の非常識

そうでもなくてね、x86もどんどん緩めたじゃん
そしてごく微妙な条件下では互換性がない

>>576
> 厳しいモデルとは言うけど厳しいのはそれ以前にダイサイズとTDPの制約ですので。

一文で矛盾したことを言うなあ
ダイサイズやTDPの厳しい物理的な制約があるから、モデルのほうを緩めたいという話なんだよ

>>580
> つーか彼はフェンス命令が100命令に1回程度でも呼ばれると思ってるのだろうか？

100命令というのは大袈裟にしろ、同期命令がフェンスしかなければ有り得るね、GPUなんだし

ダンゴ：火病
MACｦﾀ：自爆
名無し：行方不明

いつもの流れか

>>582

＞> 厳しいモデルとは言うけど厳しいのはそれ以前にダイサイズとTDPの制約ですので。
＞
＞一文で矛盾したことを言うなあ
＞ダイサイズやTDPの厳しい物理的な制約があるから、モデルのほうを緩めたいという話なんだよ

矛盾してないよ。
モデルを緩めたところでLSUが1基しかないのが律速要因になるし、
性能を上げるには相応にトランジスタが必要になる。

1コアあたりの性能を上げるためにトランジスタ使うならコア数を増やしたほうがスケールメリットがある。
だから緩める意味がない。

>>582

同期に*FENCEを使いたくないだけ？
*FENCE以外の命令を追加して*FENCEを非推奨命令にすればいいじゃん。
何が悪いの？

ヴぁか

今からSIMDやるのに128ビットのSSE*があるのにMMXを使わなくていいように
実装されてるから必ず使わなければならないなんてことはないの。

既存のフェンスに変わる命令があるなら実装すればいい
しかし既存命令を無効化する必要はどこにもない。

むしろ新命令の実装の都合で既存の命令を廃止しないといけないことのほうが「厳しいモデル」だと思うんだが。

>>585
あんまりバカバカ言わない方が良いと思うすけど。。。

既にこの記事読んでいるとわ思うすけど、素養が無いために技術的予測わ怪しいことこの上ない
後藤氏でも、こう書くからにわオフレコのソースが存在する可能性もあるす。
http://pc.watch.impress.co.jp/docs/2008/0811/kaigai458.htm
　　----------------------
　　LarrabeeとPentiumは、基本のストラクチャーが同じというだけではない。Larrabee CPUコアの
　　命令デコーダがサポートするx86命令セットも、基本は標準的なPentium世代のx86命令だという。
　　MMX Pentium以降のMMX/SSE系の拡張命令は、サポートしないと推測される。
　　----------------------

>>584
> モデルを緩めたところでLSUが1基しかないのが律速要因になるし、

勝手な願望を言うな
SSEのメモリコンシステンシモデルを実装するには、データパス上にさらに大きなバッファが必要になるんだよ
具体的には、16要素すべてのアドレスが例外を起こさないことを保証するまで、自身と後続のメモリアクセスを待たせるためのバッファだ
ハードウェアコストが嵩む上に、足を引っ張るLSUがさらに遅くなるんだ

>>585
> *FENCE以外の命令を追加して*FENCEを非推奨命令にすればいいじゃん。

ハードとソフトの話をごっちゃにすんな
何度言わせるんだ

>>587
> Intelは、Larrabee拡張命令のフォーマットの詳細については明らかにしてない。
> しかし、想定できる点がいくつかある。まず、命令フォーマットはデコードしやす
> いものでなければならない。x86命令のデコード時の複雑さの多くは、x86命令
> が可変長であることに起因している。この問題を軽減するためには、Larrabee
> 拡張命令を、固定長にすることが望ましいと推定される。

まあこの読みは同感だね。
2issueパイプラインでは命令の切り出しってのがネックになる。



ただし文字通りの固定長なんてありえんわけで。
ModRMまでを固定長にするって言う意味なら、現実的。
そしてそれにはAVXのVEXエンコーディングを採用するのが合理的。
3レジスタオペランド拡張にも対応できる。
ある意味でAVXとLarrabeeはつながってるという俺の読みの方向は正しいわけだ。


ちなみにModRM+SIB+DISPはx86の基本命令スタイルとして組込まれてるものだから、
LNIで使わなかったところで効率がよくなるものでもない。
いまさら依存しない方法を考えるよりは依存したほうが効率がいい。
ちなみにModRMを見ただけでSIBの有無とDISPの有無・長さが判明するから
可変長といっても解析はしやすい。

>>588
＞SSEのメモリコンシステンシモデルを実装するには、データパス上にさらに大きなバッファが必要になるんだよ

まだ言うの？

メモリコンシステンシ遵守で走ってるときは1命令が完了するまで次の命令はフェッチできない。
バッファなんて必要ない。

>>588
　　---------------------
　　16要素すべてのアドレスが例外を起こさないことを保証するまで、自身と後続のメモリアクセス
　　を待たせるためのバッファ
　　---------------------
Larrabee論文でわ、メモリアクセスだと時間がかかりすぎるので、Scatter-Gatherわキャッシュ上
のデータに限定する様にも読めるす。
p. 4.参照(傍点MACオタ)
　　=====================
　　The speed of gather/scatter is limited by the cache, which typically only accesses "one cache
　　line" per cycle.
　　=====================
p.11参照
　　=====================
　　The non-contiguous data elements can reside anywhere "in the large on-die cache," without
　　suffering memory access penalty.
　　=====================
キャッシュミスしたら例外発生させて、その後プリフェッチ命令でキャッシュにデータを入れるような動作を
するのかもしれないす。

バッファなんて実装されてたらL1リード・ライトのレイテンシが長くなります。
もしくはパイプラインステージにバッファリングを組み込むのかな？

SSEをサポートするIntel CPUでレイテンシが大きいことは確認できません。
パイプラインにも確認できません。

「バッファ」の存在はどこで知りえた情報なんですか？
Intelの資料にもないしAgner氏の解析にもそんなものはありません。

ベクトルマシンの常識ですか？残念ながらx86での常識ではありません。

>>583
ﾜﾛｽｗ

>>590
> メモリコンシステンシ遵守で走ってるときは1命令が完了するまで次の命令はフェッチできない。

どうしてそう性能を落したがるのかなあ

> バッファなんて必要ない。

まあ、命令発行は止めたとして
1つめ、2つめの要素は無事にストアできて、3要素目で例外が起きたらどうすんの？

>>590
　　-------------------
　　バッファなんて必要ない。
　　-------------------
4-byteしか必要なくても、メモリ／キャッシュのアクセスわ32-128-byteのキャッシュライン単位
すから、見た目よりたくさん必要かもしれないす。

>>583
無知をどうしても認めないやつを説得しようとしてるんだ
疲れて寝るもの許してくれ

ｽﾙｰするのかもしれねぇよﾆﾔﾆﾔ

＞　　16要素すべてのアドレスが例外を起こさないことを保証するまで、自身と後続のメモリアクセス
＞　　を待たせるためのバッファ

>>591

ていうか、フェンス中の例外についてもVol3読めばわかることなんだけどな
資料読まない人なんだろう

定ｽﾄﾗｲﾄﾞの命令増設か…line fillに頼らないのかねぇ

>>595
　　--------------------
　　3要素目で例外が起きたらどうすんの？
　　--------------------
こういう話題が出るから>>525で質問したすけど、回答わ無いすね。。。

仮想記憶のスワップなら、キャッシュアクセスと桁違いのロスなので成功データも廃棄で良いす。
TLBミスでも廃棄で良さそうすけど？

>>601
> TLBミスでも廃棄で良さそうすけど？
実装にも夜のだろうけど、例えばosにtrapさせてｴﾐｭる等etc

>>591
> The non-contiguous data elements can reside anywhere "in the large on-die cache," without suffering memory access penalty.

これは4MB?のローカル・ノンローカル含めたL2全部のどこにあってもペナルティがない、という意味だよ

>>603
　　-----------------
　　L2全部のどこにあってもペナルティがない、
　　-----------------
L2に無かった場合を書いていないという話す。

>>595


＞どうしてそう性能を落したがるのかなあ

だからそれがx86としての伝統だ。SSEから加わったものではない。
SSEが厳しいんじゃなくてx86が厳しいんだよ。
SSEを排除すればいいなんて生ぬるいもんじゃない。

Larrabeeにベクトル機のフィロソフィを求めるな。
Intelはお前の夢はかなえてくれない


> まあ、命令発行は止めたとして
> 1つめ、2つめの要素は無事にストアできて、3要素目で例外が起きたらどうすんの？

ページフォルト程度なら、例外をトラップして特権部に制御が移り、解決したらまた再開。
アクセスバイオレーションの類はこの限りではない。
ってなんでx86のシステムプログラミングの仕様を読まないで勝手な妄想をするの君は。

>>601
>>526で回答してるだろ
仮想記憶やスワップだけじゃないんだよ
copy-on-writeとかあるだろ

> 仮想記憶のスワップなら、キャッシュアクセスと桁違いのロスなので成功データも廃棄で良いす。

成功データも廃棄するのはいいとして、ストアしてしまったものを巻き戻すためにバッファが必要だろ

>>599
　　--------------
　　フェンス中の例外についてもVol3読めばわかる
　　--------------
自信があるなら、ページ数と引用の一つも示す心の余裕が欲しいすね。。。

>>604
> L2に無かった場合を書いていないという話す。

書いてないということを根拠に

> キャッシュミスしたら例外発生させて、その後プリフェッチ命令でキャッシュにデータを入れるような動作を
> するのかもしれないす。

こんな画期的な主張をしないでほしい

>>605
>>606にも書いたが、scatter命令は全部巻き戻すの？中途半端にストアしたまま例外ハンドラに行くの？

>>604
512ビット双方向のリングバスなら、L1のロード・ストア帯域と一致するからね。
L1とL2は等速なんだろうね。
「L2で帯域を取り合わない限りは」確かにペナルティはなさそう。
もちろん待機中は該当スレッドはストールはするだろうけど



>>607
これで3回目だったかな
何べん貼ればわかってくれるかな？彼
http://download.intel.com/jp/developer/jpdoc/IA32_Arh_Dev_Man_Vol3_i.pdf
日本語だから読めるだろ。
あえて引用はしない。全部目を通せ。要点は・・・全部だ。

>>606
　　--------------
　　仮想記憶やスワップだけじゃないんだよ
　　--------------
例外処理でカバーできない異常動作わクラッシュさせれば良いかと？

>>609
　　---------------
　　要点は・・・全部だ。
　　---------------
説明できないってのわ、通常理解していない証拠と受け取られるすけど。。。

例外トラップの仕組みは深く知りたければx86のLinuxのソースでも読んでもらったほうがいいと思うんだ。
資料読んでわからないならね。

>>610
？？
ページフォールトが起きるのは、仮想記憶以外にcopy-on-writeなんかもあるって言ってんの

まあ、ページフォールトじゃなくてメモリアクセス例外だけど、precise interruptが必要になるという点では同じ

>>611
例外については5章、マルチスレッドの同期命令については7章
でも全部目を通したほうがいいよ。

部分的な知識だけでいいみたいな甘い考えだから、つまらない思い込みで自爆するんだよ君は

>>612
わかったわかった勉強しとくから

>>606にも書いたが、scatter命令は全部巻き戻すの？中途半端にストアしたまま例外ハンドラに行くの？

頼むからこれに答えてくれよ団子さん

おぼろげに言い争いのネタが理解できた気がするす。
要するにscatter-gatherが複数メモリページに跨った場合に、
(1)団子説
　　x86のメモリオーダリング、かつインオーダー実行だから、後続命令わ単純に止まる
(2)名無しさん説
　　性能を考慮してページ単位でのオーダリングしか保証されないweak-orderingを採用しそう

という議論なんすか？

>>616
(1)はそう
(2)は、Larrabeeではどうか具体的にはわからないが、SSEよりは弱いだろう

で、(1)であっても、scatter命令が中途半端にストアしたところで例外を起すかもしれないが、
その時は
・ストアしたところを巻き戻すのか？
・それとも、中途半端にストアしたままにしとくのか？
ということを>>606で団子に問いただしている

VPUでSSE命令を実行させるとなると、SSEのメモリアクセス命令はVPUのLSUで実行せざるを得ない
つまり、VPUのLSUはweak consistencyに対応させないといけない

x86のストリング命令の場合
「命令の途中からの再開」
を許しているが、そのかわりとても遅い

>>617
　　-----------------
　　・それとも、中途半端にストアしたままにしとくのか？
　　-----------------
Larrabeeわ各コアのL2を全体で共有キャッシュとして扱うために、下記のようなL2間転送機構が
あるす。(p.3参照)
　　=================
　　Data written by a CPU core is stored in its own L2 cache subset and is flushed from other
　　subsets
　　=================
同じ仕組みで書き込まれたデータを単純に消さずに一時保存するのわ可能に見えるす。

転送というよりリネーム機構というべきすかね。。。

ストリング命令と同じだと言う仮定で、書いちゃった処理は巻き戻さないだろ。
ハンドラに飛んでも、戻ってきて同じところから再開すればいい。

アクセス違反例外ならまあ戻らないだろうね。
C++でいうcatchブロックあたりに飛ぶか、例外処理考慮してなければプロセスごと落ちる
もちろん書いちゃったものは戻らない。



余談だけど、MMXやSSEにaddps [mem] xmm1 見たいな命令がないよね。
仮説として複数マイクロオペレーションで実装する場合に問題になるから。
命令実行中に何らかの例外が発生した場合し、復帰した場合
最初のオペレーションから二重にやりなおすことなっても結果が変わってしまうことがないことを
保障できるのは純粋なストア命令くらいしかない。

EIPは退避復帰できるがマイクロオペレーションレベルでは無理だからね。
同じストア命令なら、二度書きしてもメモリに書く値は同じだから問題ない。

スキャタやギャザーは二度読み・二度書きになっても問題ないものに属すると思うが。

>>619
> Each CPU has a fast direct access path to its own local subset of the L2 cache.
> Data read by a CPU core is stored in its L2 cache subset and can be accessed quickly,
> in parallel with other CPUs accessing their own local L2 cache subsets.
> Data written by a CPU core is stored in its own L2 cache subset and is flushed from other subsets, if necessary.

どう見てもコヒーレントキャッシュの動作の説明です
ありry

>>622
物理的にデータが記録されるメモリセルわ変わっているすけど？
コヒーレンシを保つだけなら、移動させる必要わ無いす(笑)

>>623
> 物理的にデータが記録されるメモリセルわ変わっているすけど？
> コヒーレンシを保つだけなら、移動させる必要わ無いす(笑)

意味がわからん
移動させるなんてどこに書いてる？

>>621
> 命令実行中に何らかの例外が発生した場合し、復帰した場合
> 最初のオペレーションから二重にやりなおすことなっても結果が変わってしまうことがないことを
> 保障できるのは純粋なストア命令くらいしかない。

そのためにストアバッファやリオーダバッファがあるんだが…

>>624
"flush"かと。

>>626
データはCPUコアのローカルL2に書き込まれ、他のコアのL2から削除される

普通のコヒーレントキャッシュじゃん

>>624
ついでに"Cache Affinity"で検索してみて欲しいす。

>>627
LarrabeeのL2わ、共有キャッシュであることを思い出すべきす。

>>628
何の関係が？

>>629
共有キャッシュ？
何が共有されてるの？

インオーダ命令にROBはねーよ。

MMXやSSEはストアを伴う命令は不慮の例外トラップで中断して
最初から同じ命令を実行することになっても
メモリに書き込む値が変わらないことを保証できる命令しかそもそも無いので
バッファリングや巻き戻しなんてする必要がない。
一度書いてしまった値と同じ内容を二度書きしてもなんの問題もないだろ？

IAにストアバッファなんて最初からないし、あった試しがない。
SSEのメモリコンシステンシモデルが厳しい云々は無知ゆえの完全な言いがかりだ。

>>630
深夜なので頭がボケるのも仕方が無いと思うす。
　　----------------------
　　データはCPUコアのローカルL2に書き込まれ、他のコアのL2から削除される
　　----------------------
しかし、もしこんなことを普通にやっていたら二つのコアで同じメモリ領域に書き込むようなコードで
データのピンポンが発生することに気付く筈なんすけど。。。

>>631
> インオーダ命令にROBはねーよ。

インオーダ命令？プロセッサのこと？

まあROBとは呼ばないが、投機実行するなら似たようなバッファは必要

> MMXやSSEはストアを伴う命令は不慮の例外トラップで中断して
> 最初から同じ命令を実行することになっても

その手の命令は、例外チェックが済むまでバッファリングして、データを書き込まないけどね
1アドレスだけチェックすればいいから楽だ
外部割り込みなら、命令が中断されることはない

> 一度書いてしまった値と同じ内容を二度書きしてもなんの問題もないだろ？

あるんだけどなw

>>632
コヒーレントキャッシュなんだから当たり前だ…

>>632
invalidate方式のコヒーレンシプロトコルならそれが普通の動作だが。

>>633
> 外部割り込みなら、命令が中断されることはない

命令実行中には、外部例外が発生しないということ
命令の完了まで待ってから発生する

>>633
お前はx86無知なんだから黙ってろ。
ストアバッファがあるというなら資料を示せ。
お前の発言はねつ造ばかりだ。


例
movaps [mem],xmm1
addps xmm1, xmm2

Core2あたりならストア後続の命令に追い越しで次の命令を実行できるが、
レジスタリネーミングで別の物理レジスタを割り当てそこにストアする。
前のストアが完了するまではxmm1を書き換えないことが保証される。
インオーダならそもそも追い越し不可能。
xmm1が何か別の値に書き換えられる要因はない。
書き込み中にページフォルトになってももう一回やり直せばいい。

LarrabeeはVPU部に限れば1issueだから追い越しどころか同時実行すらありえない。
だからこそ厳しくも何ともないんだよ。
ストアのバッファリングが必要な命令は存在しない。
メモリコンシステンシはきつくもなんともない。

>>636
> ストアバッファがあるというなら資料を示せ。

ftp://download.intel.co.jp/jp/developer/jpdoc/2001q1_art02_j.pd
Pentium4だけどいいかい？
11ページあたりとか

> LarrabeeはVPU部に限れば1issueだから追い越しどころか同時実行すらありえない。

追い越しするためのスケジューリングやらマルチスレッディングだが…

>>637
不可。Pen4のストアバッファはお前の思ってるのと役割が違う。
強いて言えば描画のWバッファリングと同じようなもん。

同じスレッドの同じ命令列はインオーダ実行インオーダ完了だ。
同期をとらずに別々のスレッドから同一のアドレスに書き込んだ値は保証されない
だからこそ保証がほしい場合に同期が必要。

HTは、むろん別スレッドなら追い越しは可能だ。

破棄できるストアキューイング機構という意味ではCore2にもAtomにも存在しない
ストアデータを破棄しなくていい命令しかそもそもサポートしてないからな。

AtomはSSSE3まで実装してるけど4W以内。
SSEのコンシステンシモデルがどう厳しいって？
フェンスしない限りコンシステンシを保証しないからめちゃ緩いんですけど。

フェンス命令によりコンシステンシ遵守しようとしまいと
SSEのストア命令により書き込んでしまったデータを例外発生時に巻きもどす必要は全くない。

斜め読みだけど...
ららびって GPU でしょう。
GPUの方はすごい狭いSRAMにアセンブラコード載せてて、
もちろんIOとか割り込みとかなくて、システム管理コードなんて
一切無いわけで、その対抗と思えば、OS乗るっても
BlueGeneやCray XTシリーズの計算ノードで使っているような
Lightweight Kernel Linuxくらいじゃない？
その前提なら SSE のありなしは命令セットの縛りではなくて、
Intelがトレードオフを考えて決めることだと思うよ。
BlueGeneだってPPC4x0に外付けでベクトルユニットつけてるしさ。
まあ、あれはIOがあるから、コンシステンシに手を抜きすぎて
BG/Lで酷い目にあってBG/Pで改善してるけどね。

なので、基本的にはSSEについては Intel の発表待たないと
わからないし、団子さんは勇み足なのかな？と思う。
のだが、何かマイクロな論争になっていて、しかも団子論理の
方が正しいので、読んでいて困る(笑

パイプラインの管理論理って滅多に外に発表されないのだけど、
たいてい、ROBとかストアバッファとかとは別になってるよ。
キャッシュミスしたらwaiting ringに突っ込んでエントリ外したりとか
色々やるからね。
で、ROBはレジスタのフォワーディング、ストアバッファは
ロードストアのフォワーディングに使われる。
こっちはデータパスなので、外に発表される。
で、割り込みだけど、ROBから完了するときに出るのね。
μOPがどれに対応してるか判定するとか、分岐予測した命令で
例外でちゃまずいよねとか、理由はいろいろ。
ともかくそうなってる。ほんでストアバッファはROBの外にある。

まあそれはともかく、ららびでSSEありなしってソースあるんだっけ？

彼の思うSSEがサポートできない理由は、彼はSSEのストア命令は巻き戻しが必要だと勘違いしているから。
実際にはそんな動作は求められてない。
マルチサイクルで実行されることも考慮し、ストア命令が例外で中断しても再開時に最初から実行すればいい命令だけしかない。
むろんフェンス命令を使ってもその動作はかわらない。
フェンスがやるのはあくまで命令間の順序保証だけでストアのバッファリング云々は妄想。


SSE対応の根拠は64ビット対応。
x64はCMOVやSSE2は拡張命令ではなく基本命令。
Intelの旧称EM64TということであればSSE3までが基本ISA。
SSE非対応なら64ビットISAの分断を意味する。
しかしOSメーカーはそれを許すはずもなく、Yamhillの悲劇再びだな。

SSEをサポートしない合理的理由がない以上するでしょ。

>>641
> で、ROBはレジスタのフォワーディング、ストアバッファは
> ロードストアのフォワーディングに使われる。

ストアバッファは、投機的ストアのバッファリングにも使われるよ
対応するROBエントリが解放される時に、ストアバッファのデータが実際に書き込まれる

投機的ストアはやらない実装もあるけどさ

だいたい、まだ発表されてないのに、あるだのないだの言っても意味ないだろ
ある場合とない場合で分けて話すればすむ話。

無理にあるとかないとか断言しても、「ぼくのかんがえたかいじゅう」の話と一緒で
他人に聞かせるような話じゃないってくらいは理解してくれよ

団子的に、scatter命令で、部分的にストアされた状態で例外を起した場合、
この命令は中途半端に実行されたとしか言いようがない
「中途半端に実行された」を、命令実行が完了したとは到底言えないし、まったく実行されていないわけでもないから、
これがx86のweak consistencyモデルと馴染まないのは明らか

> まあそれはともかく、ららびでSSEありなしってソースあるんだっけ？

ない
後藤ちんの推測記事では、SSEどころかMMXもないことになっている

>>641
> で、ROBはレジスタのフォワーディング、ストアバッファは
> ロードストアのフォワーディングに使われる。

すまんね
インテルもAMDもROBにレジスタの投機的状態を持たせてないと思ったが
それはともかく、

> ストアバッファは、投機的ストアのバッファリングにも使われるよ

バッファした投機的(というか、コミットされていないストア全般)ストアのフォワーディングに使われる、だね

>>642

> フェンスがやるのはあくまで命令間の順序保証だけでストアのバッファリング云々は妄想。

バッファリングしているからこそフェンスで順序保証する必要があるんですけど

>>645
で、どうしてもSSE命令を実装したい場合、VPU命令のメモリアクセスはSSEのフェンス命令の対象外にするしかない

しかしVPUでSSE命令を実行するとなると、やっぱりVPUのLSUをweak ordering対応にしないといけない

>>641
> のだが、何かマイクロな論争になっていて、しかも団子論理の
> 方が正しいので、読んでいて困る(笑

団子は、おれが言ってもないことを捏造して繰り返し主張するので困る

>>647
> インテルもAMDもROBにレジスタの投機的状態を持たせてないと思ったが

これは勘違いかも
Pentium4はROBエントリに、コミットすべき値ではなくレジスタマップを持っていたと思うが、ほかのは違ったかも

In-order実行もそうだが、旧い技術への巻き戻しが多いな。

回帰大作戦ってか。

電圧スケールのマージンがどんどん狭くなってしまうという問題には、LongRun2
あたりを使いたい感じだな。

Atomの省電力技術も搭載したNehalem
http://pc.watch.impress.co.jp/docs/2008/0825/kaigai462.htm
｜●フルスタティック回路化のトレンドに乗るNehalem

投機を絶対しないからインオーダなんだが。
投機は命令発行ポートが沢山あり、それをなるべく遊ばせない為の機構。
1〜2issueで投機やる意味がない。


もちろん分岐予測による投機だけなら1〜2issueのP5でも効果はあるし、実際やってるが、
インオーダだから分岐命令のフラグ確定までに後続命令が実行されないことが保証できるから
ストアバッファなるものは不要。

アグレッシブな投機にトランジスタ使うくらいならコア数増やした方がマシだからな

VPU側は1issueだから同じスレッド間での命令発行順は常に保証できる。
フェンス命令を使おうが使うまいが、ね。
スレッドが別なら同期命令を使わないかぎり同じアドレスへの書き込みが正常に行われることは保証しない。しなくていい。

インオーダでSMTのAtomでもストアバッファなるものの存在は確認できないな。ちなみにAtomも分岐命令を追い越した投機実行はしないし。

>>651
｜45nmプロセスで、パワースイッチを実現したIntel。しかし、Kumar氏は、この技術が今後もそのまま通用するわけでは
｜ないと指摘する。「22nmプロセスで同じことを行なうことは難しく、22nmでは全く異なるソリューションが必要になる
｜だろう」とKumar氏は語る。

32nmではオケって話かな。

まあ自分の経験でも有ったけど、その時の外部条件でのみ絶妙な方法で問題を
解決出来た事例があるが、お陰で外部条件を改版する足枷になったわな。

45nmのままでも大幅にプロセスを改版するとヤヴァイ気がするが、それは入ら
ない（要らない？）とIntelは判断したって事なんだろうな。

>>652
> VPU側は1issueだから同じスレッド間での命令発行順は常に保証できる。
> フェンス命令を使おうが使うまいが、ね。

命令発行順と命令完了順の区別をつけてくださいよお願い

依存関係が解決できればインオーダ実行・アウトオブオーダ完了はありうる。
Atomでは部分的にこれを実装してる。
もちろん、追い越して完了すると困る依存関係があればストールする。


Intelが未だに実装した試しがない機構は投機ストア。
投機ストアがあるなら確かに「破棄のできるバッファ」にため込む機構の
実装が必要だろうけど、電力効率的に実用性がなさすぎる。
リッチなアウトオブオーダ機構を削り単純化すればコア数を数倍に増やせるというフィロソフィがまずLarrabeeにある。
その意味でPen4など無駄の塊。
だからNetBurstを見てIA32の全てを知った気になってるバカは手に負えない。

>>655
そのインテルが実装したことのないという投機的ストアだが、

scatter命令だと1命令で事実上投機ストアになるって言ってんの

ならねーよバカ

>>656
scatter命令の途中で例外が起きる
1) 途中まで実際にメモリに書き込んでしまう→weak consistencyではなくなる
2) 例外が起きた時点で巻き戻しする→ストアは投機的

お前が1派ならフェンス命令の非互換性を認めろよ

mfenceには途中まで書いてしまうことを禁止する機能なんてねーよ。
機能を捏造するな屑

フェンスの役割は「命令の」実行順序の保証であってメモリアクセス時の例外が起きないことまでは保証しない。
ページフォルトを考慮し二度書きになっても「いい」ような命令しかストアには無い。

>>660
> フェンスの役割は「命令の」実行順序の保証であってメモリアクセス時の例外が起きないことまでは保証しない。

これが団子の理解でいいんだな

んじゃもう何にも言うことはない

いいえIntelの仕様です。

アーキテクチャの教科書を通読したことのない団子が、インテルのマニュアルを誤読しているということか

もしかしてメモリフェンスもインテル用語と思っているんだろうか

誤読してるのはお前だけ。
Pen4のマイクロアーキテクチャしかマニュアル目を通したことがなく、CPUIDの動作仕様すら知らなかったイケヌマがほざけよｗｗｗ
ペタヘネとか古典すぎるしベクトル機のフィロソフィも役に立たない。


つかとりあえずアドレスが確定した上で書き込むのは投機ライトとは言わない。
ページフォルト程度ならバッファリング云々の機構なしでもリカバリーできる。
仮想アドレッシングの仕様は20年以上前に決まった。

>>664
> つかとりあえずアドレスが確定した上で書き込むのは投機ライトとは言わない。
> ページフォルト程度ならバッファリング云々の機構なしでもリカバリーできる。

これもあとあとコピペしていいかい？

どうぞどうぞ。

>>666
もう一つ聞いとこ

>>665は、インテル固有の話なの？
それとも一般的な話？

というかね、団子が一般論は知らないと告白するなら、そっちについては勘弁してやろうと思うんだ

>>641
そろそろちゃんと読んだ頃かな？
斜め読みというエクスキューズはいいからさ

その上で、よかったら

> フェンスの役割は「命令の」実行順序の保証であってメモリアクセス時の例外が起きないことまでは保証しない。
^^^^^^^^^^

> つかとりあえずアドレスが確定した上で書き込むのは投機ライトとは言わない。
> ページフォルト程度ならバッファリング云々の機構なしでもリカバリーできる。

この団子論理の擁護をお願いね

>>669
あ、下線部がずれた

「実行順序」の保証、ってところ

とりあえずフルセットのx64命令セットであることは確定。

http://www.itjungle.com/tlb/tlb080508-story02.html

What Intel wants to stress--and what software developers are
surely going to love to hear--is that Larrabee is a complete
X64-style core: It has context switching and pre-emptive
multitasking, virtual memory and page swapping, and fully
coherent cache memories across the memory hierarchy in the chip.
I am not certain if that means Windows and Microsoft Word will
run on it, but Intel sure wants to imply that they will.

CPUIDの動作についていい加減に弁解が聞きたい。
おっと、フェンスしない実装なんてのはありえないからな
CPUIDのフェンス作用は規格としてドキュメント化されている。

オーダリング強制の緩さって面では
L/Sの特定命令に限定してリタイアするまでブロックする*FENCEのほうが、
全命令がリタイアするまでブロックするCPUIDなんかより緩いといえる。

CPUIDを使ってしかフェンスできないほうがパフォーマンス上致命的なんだが。

でもさ、マルチサイクルのストア命令の実行中にいくら例外が起きようと
書き込みを巻き戻す必要は「ない」。
rep movs*が良い例。例外起きてもそのまんま。SSEでももちろんそう。

フェンス命令の仕様何で読まないで勝手な妄想するか理解に苦しむ。

>>671
　　--------------------
　　とりあえずフルセットのx64命令セットであることは確定。
　　--------------------
もしかして、英語で書いてある情報わ全部真実に見えるすか？

mov ecx,10000000
rep movsd
mfence

↑こんなコードで実行中に例外が起きるとして、バッファ(笑)は何エントリ必要か答えてね。

>>673
おれの言ったこと覚えといてくれよ

「CPUID等の逐次化作用は、VPUメモリアクセスには完全に適用されるわけではないんじゃないか？」

と予想してるつっただろ

> rep movs*が良い例。例外起きてもそのまんま。SSEでももちろんそう。
>>675

rep付きストリング命令は、「命令の途中からの再開」を許す極めて例外的な命令なんだよ
その代償に遅い

「ライトバッファオーバーフローシステムクラッシュする」
なんて珍回答に期待

>>674
そうだよな、言ってることはMACオタや団子レベルの自分勝手な予想だよな

> What Intel wants to stress

だってよ、プププ

で、まこたんはコヒーレントキャッシュの動作を勉強したかね

>>676
＞ >>673
＞ おれの言ったこと覚えといてくれよ
＞
＞ 「CPUID等の逐次化作用は、VPUメモリアクセスには完全に適用されるわけではないんじゃないか？」
＞
＞ と予想してるつっただろ
＞
＞ > rep movs*が良い例。例外起きてもそのまんま。SSEでももちろんそう。
＞ >>675
＞
＞ rep付きストリング命令は、「命令の途中からの再開」を許す極めて例外的な命令なんだよ
＞ その代償に遅い


全て妄想。どこにもそんなことは書かれていない。

>>678
　　--------------------
　　まこたんはコヒーレントキャッシュの動作を勉強したかね
　　--------------------
共有キャッシュに書き込む度にinvalidateが必要という珍説(笑)
>>634
　　=====================
　　invalidate方式のコヒーレンシプロトコルならそれが普通の動作だが。
　　=====================

>>679
上のCPUIDの話はおれの予想だ

ストリング命令が遅いのも、実行中に割り込みが入るのも事実だろ…

REPつきストリング命令って表現はまぬけすぎるな
じゃ、SSE*はREPつきMMX命令なのかな？