5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

x86命令の所要クロック計測スレ

1 :デフォルトの名無しさん:04/12/21 15:08:57
PentiumMにて
addpdは4-2(レイテンシ-スループット)
imul 4-1

Pen4、Athlonなどデータを集めてみる

2 :デフォルトの名無しさん:04/12/21 15:10:08
      ∧∧    / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
     (,,  )  <  >>2ゲットしようと来てみれば
     .(  つ   |  こりゃまた とんだ駄スレだなぁ オイ
     | , |    \____________
     U U

 |  まあ せっかくだからやっといてやるよ   |
 \  ハイハイ 今だ>>2ゲットズザー っとくらぁ /
    ̄ ̄ ̄ ̄ ̄ ̄V ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

            ∧∧
           (゚Д゚O =3
      ⊆⊂´ ̄  ソ ヤレヤレ

ドッコイショ・・・・・・・・・
 ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄
     ∧∧          (´;;
    (゚Д゚ ,)⌒ヽ    (´⌒(´
     U‐U^(,,⊃'〜... (´⌒(´⌒;;

ハァ、ダルッ・・・帰るか
 ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄
  ポ  ∧∧  ポ
  ン  (゚Д゚ ,) . ン
   (´;) U,U )〜 (;;).
(´)〜(⌒;;UU (´ )...〜⌒(`)

3 :デフォルトの名無しさん:04/12/21 15:14:48
(・3・) エェー OS上で正確な測定が出来るのかYO

4 :69式フリーPG ◆hND3Lufios :04/12/21 17:37:18
そこでMS-DOSですよおとうさん

5 :デフォルトの名無しさん:04/12/21 19:52:21
http://appzone.intel.com/scripts-util/download.asp?url=/jp/developer/jpdoc/ia32.pdf&title=IA-32+命令のレイテンシとスループット&fullpg=3&site=jp

コレじゃダメ?

6 :デフォルトの名無しさん:04/12/21 23:24:02
PentiumMはまた他と異なるからじゃないかと

7 :デフォルトの名無しさん:04/12/22 00:46:13
それなら、>>1はそうとわかるように、スレタイと>>1の内容を書くべきだったね。

8 :1:04/12/22 11:10:47
>>3
できるよ。

>>5
Intelのマニュアルは持ってるが、Pen4しか詳しくない。
PenIIIも概略はのっているが、細かいクロックはない。
PenMのSSE2はみたことないし。

P4以外のSSEは、おそらく2μopで、それぞれのμopが並列実行されたりするから
内部構造を意識しないとクロックがわからない。
実行ユニットの数、レイテンシ、スループットをうまく求める必要がある。

9 :1:04/12/22 11:16:19
PentiumM
addsd 3-1(レイテンシ-スループット)
addpd 4-2(addsd2回に相当。連続して行うと実質4-1)
sqrtsd 57-57

10 :デフォルトの名無しさん:04/12/22 20:57:50
PentiumMのSSE2は糞っていうのをどこかで見たな。

計測プログラムを公開して、色んなCPUで実行してもらうのが、いいんじゃない?

11 :デフォルトの名無しさん:04/12/22 23:35:01
>>10
PenMのSSEはNetBurstより圧倒的にレイテンシもスループットも良いんだがな
乗算やシフトもIntel系の伝統を破っていて不思議と速い
実クロック以外に糞と呼ばれる要素あるんかいな?

12 :デフォルトの名無しさん:04/12/23 03:38:27
AMDのCPUにはこれ使え。
ttp://www.amd.com/jp-ja/Processors/DevelopWithAMD/0,,30_2252_869_3604,00.html
パイプラインのストールの様子も分かり、とても面白い。

13 :デフォルトの名無しさん:04/12/23 03:49:01
>>11
SSEじゃなくてSSE2

14 :デフォルトの名無しさん:04/12/24 15:17:48
ベストケースのレイテンシ・スループットはAMD, Intelともに
ドキュメントがある。しかし、それが何の役に立つというのだ?

ちうわけで>>12のようなシミュレータの出力を眺めつつ
あっち立てればこっち立たずの局所最適化に明け暮れることになるわけだ。

15 :デフォルトの名無しさん:04/12/25 02:38:46
スループットって何?

スループット1なら、最も条件が良い時に1クロックで実行できる。
スループット2なら、2クロックで実行できる。
ってことだと思っていたのだけど、間違ってる?

論理演算は、64ビットのMMXがスループット1で、128ビットのSSE2がスループット2だから、
どっちでやっても変らないや、と思っていたのだけど、実際にやってみると、SSE2のほうが速い。
もしかして、コーディングがヘタ糞で、ストールしまくってるのかな・・・。

16 :デフォルトの名無しさん:04/12/25 12:36:21
メモリアクセスのレイテンシはいっしょ
ロード&ストア回数が少ないほうが速くて当たり前

17 :15:04/12/25 20:58:07
メモリアクセスのレイテンシは隠蔽されないのですか・・・。

18 :14:04/12/26 01:38:12
>>15
PentiumM, AthlonのMMX ALUは、スループット1/2
依存関係のない2つの演算が同時に2個実行できる。
(Pentium4 は スループット1 のハズ)
たいていのSSE演算は、いずれのプロセッサもMMXを2つ束ねて
実行しているようなものなので、スループットは半分になる。

レイテンシに関しては、メモリアクセスのレイテンシは
ベストケースでL1キャッシュにヒットしたとき。
メモリアクセスのレイテンシは、他に実行しているロード/ストアに
引きずられたりするので、予測するのはけっこうメンド。

コアループをここに貼ってくれれば添削はできる。

19 :15:04/12/26 04:59:15
解説ありがとうございます。

せっかくの添削の話ですが、
アセンブラではなくCで書いてコンパイラにスケジューリングさせてるので辞退させてください。

20 :デフォルトの名無しさん:04/12/26 15:26:13
コンパイラは確かに優秀だが
仕様上どうしてもできないことがある
漢なら__declspec( naked )で書くんだ

21 :1:05/01/11 14:54:37
>addpd 4-2(addsd2回に相当。連続して行うと実質4-1)
>>9のこれは間違いだった。
3-1を2つで3-2が正解。
上位と下位で並列性が生まれ、少しレイテンシが減る。

今はVC++6のインラインアセンブラとnasmで計っているが、
分岐ミスのクロックからパイプラインの長さ計ろうとしても
いまいちはっきりせん。
14段ぐらい?

22 :デフォルトの名無しさん:05/01/11 20:42:10
そういや、VCは不思議な挙動をするね。

インラインアセンブラで書く → その前後でコンパイラの最適化が無効になる
intrinsicを使って書く & 組み込み関数のインライン展開OFF → intrinsicを含め、コンパイラが最適化してくれる
intrinsicを使って書く & 組み込み関数のインライン展開ON → その前後でコンパイラの最適化が無効になる

リリース・ビルドでは
組み込み関数のインライン展開ONよりもOFFのほうが速く、
デバッグ・ビルドでは
組み込み関数のインライン展開ONよりもOFFのほうが圧倒的に遅い


23 :1:05/01/12 12:29:22
VB高速化のため、VCの__asmで書きDLL化したのをVBから呼び出している漏れ。
21の言っていることがよくわからない。
悔しいのでキャッシュの仕組みでも書いてみる。
話がPIIIなのは昔考えたことだから。


キャッシュというのはアドレスを言われたらすぐそのデータを差し出さなければならない。
PentiumIIIのL1キャッシュでのこの時間はわずか3clk。
キャッシュのどこにどのアドレスのデータがあるかを把握していなければならないのは当然だが、
突然言われたアドレスのデータが16KBものデータの中からどこにあるのかを調べて
データを転送するまでたったの3clkで完了させるというのは、
データの配置に制限をかけて検索しやすいようにしなければできないことである。

そこでL1キャッシュは4ウェイ・セット・アソシエイティブ、キャッシュラインサイズ32byte、
キャッシュライン512本で容量が16KBのキャッシュになっている。
まずL1キャッシュは512個のキャッシュラインに分かれている。
16KB÷512個でそれぞれが32byte。

ここには必ず32byte境界にアライメントされた連続データが入る。
これが4個ずつ128グループになっている。
アドレス値の5〜11bitには、7bitあるので128通りがあるが、
各グループがその128通りに割り当てられる。
そのグループ内のキャッシュラインには必ず割り当ての7bitをアドレス値の5〜11bitに持つデータが入る。
すると、このアドレスのデータがほしいと言われたときに、アドレスの5〜11bitからグループを特定し、
その中4つのキャッシュラインについて一致するアドレスがないか調べればいいことになる。
これなら3clkでできそうだ。

24 :1:05/01/12 12:33:56
って22の間違いね。
>21の言っていることがよくわからない。

まあ、アセンブラのおかげで、Cが内部的に何をやっているのかは
けっこう理解しやすくなった。
22がそんな難しいことを言ってないというのはわかるが
アセンブラ使いのVB厨つうことで勘弁。

25 :デフォルトの名無しさん:05/01/12 13:27:20
>>24
インラインアセンブラを含む組み込み関数(intrinsic)をインライン展開すると
最適化が効かなくなる。
→普通は速くなるはずのインライン展開が、却って遅くなる原因になることもある。

ってことでしょ。

26 :デフォルトの名無しさん:05/01/12 13:47:06
EAX,EDX以外のレジスタを使うとちゃんと保存してくれてるんだよな
エライもんだ

27 :1:05/01/18 12:34:02
>>25
サンクス。こっちの指定が大域的な最適化を阻害するわけか。
そりゃそうだわな。コンパイラ作った人えらいなあ。

調べた(PentiumM)
命令 レイテンシ スループット

MOVDQA 1 1
MOVDQU 1 1
MOVD 1 1
MOVD 1 1
MOVDQ2Q 1 1
MOVQ2DQ 1 1
MOVQ 1 1
PADD(B/W/D) 1 1
PADD[U]S(B/W) 1 1
PADDQ 2 2
PADDQ 2 2
PMADDWD 4 2
PMUL(L/H/HU)W 4 2
PMULUDQ 5 2
PMULUDQ 4 1
P(AND/ANDN/OR/XOR) 1 1
PS(L/R)LDQ 3 3
PS(L/R)L(W/D/Q) 2 2
PSRA(W/D) 2 2
PCMP(EQ/GT)(B/G/W) 1 1
PACK(SSWB/SSDW/USWB) 2 2
PUNPCK(L/H)(BW/WD/DQ) 2 2
PUNPCK(L/H)QDQ 1 1

28 :1:05/01/18 12:35:52
続き

PAVG(B/W) 1 1
PSADBW 5 2
PEXTRW 4 2
PINSRW 2 2
P(MAX/MIN)(UB/SW) 1 1
PMOVMSKB 1 1
PSHUFD 2 2
PSHUF(L/H)W 1 1

29 :1:05/01/18 12:38:51
OV(A/U)PD 1 1
MOVSD 1 1
ADDPD 4 2
ADDSD 3 1
MULPD 7 4
MULSD 5 2
DIVPD 62 62
DIVSD 32 32
SQRTPD 114114
SQRTSD 57 57
ANDNPD 1 1
ANDPD 1 1
ORPD 1 1
XORPD 1 1
CMPPD 4 2
CMPSD 3 1
[U]COMISD 1 1
MAXPD 4 2
MAXSD 3 1
MOVMSKPD 1 1
SHUFPD 2 2
UNPCKHPD 3 2
UNPCKLPD 3 2

30 :1:05/01/18 12:39:42
CVTPD2DQ 4 2
CVTPD2PI 2 2
CVTSD2SI 4 1
CVTDQ2PD 4 2
CVTPI2PD 4 2
CVTSI2SD 4 1
CVTPD2PS 5 2
CVTSD2SS 4 1
CVTPS2PD 3 3
CVTSS2SD 2 2
PINSRW 2 2
P(MAX/MIN)(UB/SW) 1 1
PMOVMSKB 1 1
PSHUFD 2 2
PSHUF(L/H)W 1 1
CVTDQ2PS 4 2
CVTPS2DQ 4 2

以上。全部SSE2でした。

31 :1:05/01/18 12:43:46
実行ユニットがガラ空きだったときのベストケースのクロックです。
SSE2は2μopのようなので、MMX2命令(1μop*2)の方が
デコーダには優しい場合もあり。

32 :14:05/01/18 14:14:24
thx.
予想通りだな。ちなみにK8も似たような感じかな、
SSEはMMX×2なので。

かといってこんだけの情報でオプティマイザ作るのは至難の業
次はMMX命令の計測 pls. (たぶんP6系と共通だろうが)

33 :1:05/01/19 13:05:15
orz...
Excelでまとめたのをそのままコピペしたらあかんわな。連投&&間違い多くてスマソ。
2回書いてある命令がかなりあるが、無視してくれ。
pmuludqは、下はMMXレジスタが対象のときのクロック。

>>10
自分でも試行錯誤して計ってるからなあ。配布できるようなものを作る自信もないし、
アセンブラで叩いて肌で感じる、CPUごとのクセみたいのを知りたいなあ。

>>11
PMのSSE・SSE2は、P4と大分性格は違うもののIPCは同じ程度と予想している。
PMは整数・論理演算が得意で小回りがきく。
P4はメモリから高速転送して浮動少数点演算が得意。かな?
ていうかPMは実クロックこそが糞なのだと思われ。SSE2では(実性能で)P4に張り合えないでしょ。

>>12
それ激しく面白そうだが、何?

>>14
自分はマンデルブロ集合の描写速度で理論値に迫りたいと思ってこの道にはまった。
確かに、「楽しいから」「知りたいから」以外、役に立つということは少ないかもなあ。

>>18
その「スループット1/2」という表現だと、「レイテンシ1・スループット1/2の演算器が1個」だよね。
実際は「レイテンシ1・スループット1の演算器が2個」なので厳密には違うと思う。
(18の言わんとしていることは正しいと思うが表現が気になっただけ)

>>26
VCのインラインasmはホント親切だね。そういうことは大分後で知ったよ。
VB+VC__asmって一番ぬるま湯なアセンブラ環境やも知れぬ・・・。

34 :1:05/01/19 13:21:01
>>32
K8の情報激しくキボンヌ。
SSE命令を2つ同時デコードできるかとか、
SSEの単精度と倍精度の差とか。

ちなみにPentiumMの乗算だと、単精度2個で4-1、倍精度1個で5-2。
倍精度だと、拡張精度のFPUと同等で、あまり速くない。

MMXだとP6と一緒みたいです。
ただ、μopフュージョンのおかげでメモリ周りがP6より速い。
例えばmovq [edi],mm0という命令は普通だと
「ストアするアドレス[edi]の計算」と「データmm0をストアバッファへストア」
の2つのμopに分解される。これをくっつけたまま処理する。
すると、デコーダはこの命令を複数μopに分解しないで済む。
1つの命令を複数のμopに分解するのはデコーダにとって相当に大変らしく、
これでこの命令はデコードに際し1μop扱いとなる。
当然リオーダバッファも1エントリしか占有しない。
実行ユニットに送られるときに分離され、それぞれ処理される。
OoOなのでこの処理は同時でなくてもいい。
結果は元のリオーダバッファに戻され再び合体、両方の処理が終わった後で
命令はリタイヤされる。リタイヤも1μop扱いなので楽ちんだ。

特に、P6ではリタイヤがボトルネックとなり、最大でも
3μop/clk(デコーダは6μop/clk吐けるのに)だったので、
PMは「思い通りのスピードが出る」名石だと思う。

35 :14 ◆TimpoiKAMI :05/01/19 17:29:25
いつも使ってるコテトリップつけると、ストーカーヴァカがやってくるので(汗

>>34
SSEのデコードが、K7/K8でもっとも違うところですね。
K7(Palomino)では、動けばいいやって感じの VectorPathだけど
K8では、SSEはDouble pathといって、Decoderを2つ同時に駆動するような
感じになるのね。だから、Double path命令は、2命令同時発行はできないけど
Double path+DirectPath は可能(なハズ)。

文章では、AMDサイトに Optimization guide(英文)があがってるので、参照されたし。

uops fusionに関しては、K7の頃から似たような感じの実装があった。
issue stageまでは一緒にスケジュールされる。

Retirement が3ってのがいちばんボトルネックになりうるというのを知って
愕然とした、俺であった。合掌。

36 :デフォルトの名無しさん:05/01/20 18:44:14
>>33

>>12で紹介されてるのはAMDのフリーウェアで、
ターゲットの実行ファイルに対して、
CPUのパフォーマンスカウンタの値を表示したり、
CPUシミュレータによってパイプラインの状況を1命令ずつ表示したりできる。

37 :デフォルトの名無しさん:05/01/24 23:35:22
>>35
DoublePathでも論理演算とかはFADD、FMULに並列に送ることが
可能じゃないの? 最適化マニュアルをみるとThroughputは1になっているし。

38 :14 ◆TimpoiKAMI :05/01/25 00:21:33
>>37
Yes, FADD, FMUL で同時に喰うから、スループット1だね。
Load も、たいていの場合だと 64bit x2 がイケるし…

Store は、64bit x1 なんだな、これがネックになりうる。

39 :1:05/01/25 10:07:59
>>35
>uops fusionに関しては、K7の頃から似たような感じの実装があった。
P6対K7でK7優勢だったのはこのおかげだろう。
確か、「メモリ読み書きとALUのセット」が3つあるんだよね。速すぎ(^^;
その上FPUが強力だし、よくP6で張り合えたものだ。P6がよかったのはL2キャッシュの性能?

>Retirement が3ってのが
デコーダも実行ユニットもしっかり考えて作るのになぜかIPCの壁があって、意味不明だった。
マニュアル読んでコレダ!と思ったよ。なぜか他所では見たことないが。
あのマニュアルはIntelに不利な点を隠すように書いてあるから、読みづらいったらない。

>Optimization guide
お、いいなこれ。ありがと。英語は読むのに時間がかかりすぎだが・・・。
もっとも、Intelの直訳マニュアルも意味不明だった。

>>32かといってこんだけの情報でオプティマイザ作るのは至難の業
手動で最適化できる知識を身に付けたいというのは大きな動機だったなあ。
しかしオプティマイザ作るってのはやり方の見当もつかん。
前も書いたが最適化の効いたコンパイラ作る人えらい。

>>36
サンクスコ・・・。やってみたが、StartSimulationを押すと即落ちる(XPで青い画面初めて見た)。
AMDのCPUじゃないとできないとか?APICがないとか出るがそれか?
ヴ〜パイプラインの様子見てえぞゴルァ!!

40 :1:05/01/25 10:11:54
>>10
>PentiumMのSSE2は糞っていうのをどこかで見たな。
遅レスだが、これはまるも製作所のことではないだろうか(戯言の04年11月9、11日参照)。
MMXをSSE2にしたら、PMは遅くなりP4は速くなったという話。
この人が使っている「psadbw」という命令が最悪(SSE2化で使い勝手が悪化した命令の1つ)。
P4ではSSE2で高速化しているが、PMの倍の帯域を持つL1キャッシュの力を引き出したのと、
糞性能(PM/P6の半分程度)のMMXを使わなくなった効果だろう。
psadbwを使う状況では、PMは素直にMMX版でいくしかないと思われ。
>>11の言い分は「P4よりPMが速い」なので正しい。ただ、キャッシュのスループットは例外。
MMXよりSSE2が遅くなるのはPMでもレアケースのはずだが、不満の声を聞くのが
動画処理(SIMD系命令本来の用途)をしている人からなのが意外だった。

>>37>>38あたりはOptimization guideよく読んで考えよっと。

ついでに。
このスレの主眼となるクロック計測だが、「addpdが4-2」で終わりじゃない。
「addpdは2μopに分解され、クロックは両方3-1で、実行できるユニットは1個」まで調べる。


41 :14 ◆TimpoiKAMI :05/01/25 10:30:37
>>39
> その上FPUが強力だし、よくP6で張り合えたものだ。P6がよかったのはL2キャッシュの性能?

初代K7と河童の最大の違いだね、L2は。低レイテンシ高スループットのL2は、
正直うらやましかった。今でもL1, L2とも、K7はP6系よりレイテンシ高い。

> サンクスコ・・・。やってみたが、StartSimulationを押すと即落ちる(XPで青い画面初めて見た)。

AMDコードアナルはAMD専用っぽいっす。プロファイリング用のドライバが
AMD-Specific Registersいじってるんだと思う。
俺に必要だったりするのはパイプラインシムだけだったりするんだがな。
あとのプロファイリングは RDTSC で事足りてるし。

俺のメインマシンである Crusoe ノートに入れたらやっぱり市んだので。

42 :1:05/01/25 11:47:41
>>41
即レスありがと。K7のレイテンシってどのくらいなの?
調べたが、P4とかはよくCPU-Zのが晒されてるんだがAMDは見かけない。
そもそもP6のL2バスが256bitのハーフスピードで4byte/clkのスループット
というのからして理屈がわからないのだが。

>AMDコードアナルはAMD専用っぽいっす。
残念。まあ仕方ないか(夢のようなソフトなんだが)。

さて。
クロック測定には、内部構造の知識も必要なので書いておく。
CPUの速さを決めるのは、キャッシュ性能・命令のフェッチ・デコーダ・命令の所要クロック・
実行ユニットの数・分岐予測・パイプラインの段数・OoO性能・リタイヤユニット・・・など。
PentiumMでは具体的にどうなっているかを解説する。

43 :1:05/01/25 11:48:47
キャッシュは、L1がデータ32KB,命令32KB、L2が2MB。巨大です。
L1がレイテンシ3、スループット8byte/clk。L2はレイテンシ10、4byte/clk?
速さについては>>23も参照。詳しいデータが欲しい。Intelはキャッシュが強い印象がある。

命令のフェッチ(L1命令キャッシュから読む)。何か16byteごとに持ってくるらしい。
なので16byte境界をまたがないように命令を置くといい。

デコーダ。3個ある。その内、複数μopの命令をデコードできるのは1個だけ。
つまり4μop、1μop、1μopと来たクロックには6μopも吐けるが、
2μop、2μopと来たらクロック当たり2μopしか吐けない。
よって1μopでない命令は連続しないように配置するとよい。
ここでμopフュージョンが効く。メモリへ書く・メモリから足すなどが1μopとなった。

命令の所要クロック。このスレの住人様(俺かよ)お願いしまつ。レイテンシをうまく隠蔽しよう。

実行ユニットの数。5個ある。0〜4の番号を付けると、
0はALU(整数・論理)・移動・浮動小数点乗算。1はALU・浮動少数点加算・移動。
2はメモリから読む。3はメモリへ書くアドレス計算。4はメモリへ書くデータをバッファに入れる。
メモリは読むより書く方が手間なんですね。処理を違うユニットに分散させれば最大5μop/clk。
ここでのμopは、フュージョンしたのを分離したμop。

分岐予測。今のCPUはパイプラインが深い。作業を細分化して流れ作業なわけです。
その作業の最初が命令のフェッチで、分岐はそのフェッチする場所を変える命令なので
早い内に変えることを予測して作業しないと効率悪すぎです。
今までのパターンから予測する他、ループ検出器なんかも付いていて強力らしい。
当然パイプラインの段数は少ない方が良い(クロックは上げにくくなるが)。

44 :1:05/01/25 11:51:39
OoO。アウト・オブ・オーダーの略。
レイテンシが長い命令の結果待ちμopなどがあったら、先に別の命令を処理しちゃおうという機能。
デコードが終わった段階で、μopたちはリオーダバッファとかいうのに格納される。
この中から今すぐ実行できる命令を選んで実行ユニットにガンガン送り出す。
バッファの数や送り出しの決め方なんかが性能を左右するのか?

リタイヤユニット。リオーダバッファから実行済みの命令を見つけて、
「順番通りに」結果をレジスタやメモリに書き込み、消していく。
最大3μop/clkでリタイヤさせることができる。


ってここに来る人はこんなのわかってるか・・・。
でも昔の俺はこういうのを猛烈に知りたかったのよ。

45 :14 ◆TimpoiKAMI :05/01/25 12:09:14
>>44
俺もマイクロアーキテクチャを真剣に調べるよーになったのは
ここ1年くらいのことなんで、マターリ逝こうや。お互いにな。

46 :デフォルトの名無しさん:05/01/25 13:55:31
>>44
PenMのレイテンシ/スループットは英語版の最適化マニュアルおとせば
主要なのは載ってるよ。

47 :デフォルトの名無しさん:05/01/25 14:18:47
>42
ここにP4とK7のロードレイテンシの比較が。
ttp://www.geocities.co.jp/SiliconValley-Oakland/8071/index.html

48 :14 ◆TimpoiKAMI :05/01/25 14:31:38
>>47
横槍失礼。見てみました。
データシート記載のものとほぼ同じ数字のようですね。

プレスコは…(ry

49 :デフォルトの名無しさん:05/01/25 15:34:50
>>46
x86がほとんど載っていない。

50 :デフォルトの名無しさん:05/01/25 17:37:33
>>49
しかし、>>1が欲しいのは>>27以降の書き込みをみるかぎりx86/x87ではなくて
SIMD系のデータらしいが…。
Pen4に関してはもっと詳細なソースもあるが、ここでは秘密にしておく。

51 :14 ◆TimpoiKAMI :05/01/25 18:12:43
まぁP6以降スーパースケーラx86石専用スレつーことでヨロ

52 :デフォルトの名無しさん:05/01/25 19:09:54
[x86]CPUアーキテクチャについて語れ![RISC]
http://makimo.to/2ch/pc5_jisaku/1082/1082357989.html#155

こんな説明の仕方もあるのかw



53 :1:05/01/26 10:49:37
>>45
俺走りすぎてる?(^^;
まあ、たまにしか来られないのでこのぐらいやらないと。
・・・と思ったら、俺のレスの割合多いな。orz

>>46
そうか。以前探して、無かったので、PMは無いという先入観ができていたようだ。サンクス。

>>47
これはイイ!しかしP4のL1はすごい。そういうのに特化した設計だから当然と言えばそうだが。
Prescottはキャッシュレイテンシが増えても、実際の性能がそこそこ出るのはなぜだ?
キャッシュ容量は増えてるが、内部的にも改善のある希ガス。

>>49>>50
俺は全て知りたいが、古いマニュアルに載っていなくて未知数だったSSE2を特に知りたかっただけ。
整数命令は使った経験が多いので、比較的挙動がわかる。
IntelのFPUは加算3-1、乗算5-2でPPro〜PenMまで変化ないと思うが、
加算と乗算の並列実行やfxchのコストなど、詳しい資料があれば是非見たい。
並列実行はPMになった時点で有効になったと見たがどうか?

つうか秘密にされると知りたくなる罠。

>>51
ま、そうだね。俺がアセンブラ始めたのが河童-128k。Celeronにしては、いい石だった。
VBを始めたのはPenIIで、BASIC始めたのはポケコンだった。
ポケコンで機械語できなかた雪辱をやっと(w

>>52
俺もたまに実生活でパイプラインが浮かぶ。スーパースカラの方が多いが。
両手で作業してるとき、右手と左手をUパイプとVパイプに見立ててP5ごっことか。

54 :デフォルトの名無しさん:05/01/27 02:01:29
勉強になります!

55 :デフォルトの名無しさん:05/01/27 13:37:35
両手で作業してるとき、右手と左手をUパイプとVパイプに見立ててP5ごっことか。
両手で作業してるとき、右手と左手をUパイプとVパイプに見立ててP5ごっことか。
両手で作業してるとき、右手と左手をUパイプとVパイプに見立ててP5ごっことか。

56 :デフォルトの名無しさん:05/01/27 19:35:38
>>55
>>1はかなりCPUに頭を侵されている。重傷だとおもったw

57 :デフォルトの名無しさん:05/01/27 20:28:17
可愛そうに・・・「させられ体験」をしているなんて、間違いなく統合失調症だな。

58 :1:05/02/01 14:29:56
>>54
わかった点や疑問点なんかも書くと更に嬉しいぞ。

>>56
頑張ってアセンブラの勉強をしていた頃は、かなりの事象がCPUの動きに見えてたなあ・・・。

>>57
マジレスでスマソ(スレタイからも脱線だが)。
人間は相対的に物事を捉える、言葉で物事を考える、とすれば、
CPUの仕事と自分の仕事の類似点があったら、アセンブラの経験を生かした捉え方ができる。
誰でも、P5のUVパイプの比喩でなくとも、もっと一般的な何かにたとえて捉えているにすぎない。

俺はコンビニのレジをやったことがあるのだが、おつりを取るときに、
距離の関係で、1円玉は右手で取れない、500円玉は左手で取れない(取れなくはないがw)。
つまり、片方のパイプでしか実行できない命令がある。

また、10円玉4枚を取るときのこと。
10円を入れる所が1個しかないので、2枚/clkの手を2本持っていても2clkかかってしまう。
依存関係はないが、実行ユニットの競合が起こってしまう。
8byte/clkのキャッシュでも、mov eax,[esi]/mov edx,[esi+4] には2clkかかるような感じ。

店員が2人で1つのレジをやっているとき。
確かに1人でやるよりは速いが、小額の客ばかりだとあまり変わらないことも多い。
客:タスク、客に対する様々な作業:スレッド、店員:CPU、
レジの個数:ソフトの仕様、お金の授受:外部記憶のアクセス。
1人の客に対して複数のスレッドがある時間は短いため、デュアルCPUを生かせない。
素直にレジ2つ使えば(ソフトをデュアルCPU向けに最適化すれば)速くなる。
ただ、このソフトをシングルCPUで実行すると、レジを行ったり来たりのオーバーヘッドがある。
だが、お金を出すのが遅い客ばかりだと、このソフトの方がいい場合もありうる。
(本当にやったら客に失礼すぎ)
店員がHT対応(2つのレジに手や目を分散できる変態。頭いいのが前提)だったら問題ないが。

59 :デフォルトの名無しさん:05/02/02 01:17:09
>>58
やっぱり、病気ですから。
もっと抽象的な捉え方するなら兎も角、特定のCPUのアーキテクチャと捉える辺りがもうね。

60 :デフォルトの名無しさん:05/02/02 01:47:44
その程度だったら精神科いけば直るよ

61 :1:05/02/02 11:37:34
あすろんについて。
K8でxmmレジスタに対するpandとandpdのクロックが違うのはなぜ?同じ動作なのに。
DoublePathなのは1.5命令/clkと書いてあったが、1個のデコーダで2clkてことかな。
P6のデコーダの1つは1clkに最大4μopを吐くが、
K7/K8は、それよりは少し弱いデコーダが3つあるということか。
2μopの命令が連続するとP6は弱い。μop自体K7の方が大きいし。

つーかロードが2命令/clk出せるのがうらやましい。
確かにPenMと同等かより上の高性能だが、Intelのとは
内部構造が別物だね。

Crusoeの叩き心地とかも知りたいが・・・。

62 :14 ◆TimpoiKAMI :05/02/02 11:59:42
>>61
>K8でxmmレジスタに対するpandとandpdのクロックが違うのはなぜ?同じ動作なのに。
>DoublePathなのは1.5命令/clkと書いてあったが、1個のデコーダで2clkてことかな。
フシギだねぇ。似たような動作なのに。
どちらもデコーダは DoublePath だから、実質的にデコードは1命令/clk
その後、PAND類は、FADD/FMULへissueされるが、
ANDPDはFMULへのissueのみなので、その分スループットもレイテンシも
大きい、そういう理解でいよう。

>P6のデコーダの1つは1clkに最大4μopを吐くが、
>K7/K8は、それよりは少し弱いデコーダが3つあるということか。
スケジューラに叩き込まれるまでに macroop になるようだね。
marcoop は、1〜2uopで構成されてると推測。

>つーかロードが2命令/clk出せるのがうらやましい。
けっこーこれができない条件があって、シミュレータでも実機でも
ストールを見ることができるよ。だからこそ、Load が 64x2 連続で
逝けまくってるときって楽しくてしょうがない。実際にはLoadするばかりでなく
Store(こちらは64x1)も混在するから、このときにいろいろ引っかかりが出てくる。

>Crusoeの叩き心地とかも知りたいが・・・。
俺は現役の Libretto L2使い。ほい。
Crusoe Exposed: Reverse Engineering the Transmeta TM5xxx Architecture
http://www.realworldtech.com/page.cfm?ArticleID=RWT010204000000
http://www.realworldtech.com/page.cfm?ArticleID=RWT012704012616

63 :1:05/02/02 13:28:42
>>62
andpdもALU使えよ・・・てのは素人考えなのだが。

しかし手元にないCPUを調べるのは、ある意味むなしいな。確認ができん。
1kHzくらいでいいからエミュレータ欲しい。

64 :デフォルトの名無しさん:05/02/03 14:57:15
age

65 :デフォルトの名無しさん:05/02/06 13:57:30
整数用のALUとSIMD用のALUって、別に存在して、同時に動くの?

なんか、SIMDの計算の間に、整数用の命令を挟んでも所要時間がほとんど変化しないよ。

66 :デフォルトの名無しさん:05/02/07 14:07:37
あーおもしれー

67 :1:05/02/08 09:37:06
>>62
Athlonでの>>65を考えて気づいたが、AthlonではMMXすらFPU側なのだね。
andpdはFADDを使いたいときに有効かなあ。
これは(AGU+ALU)*3とFADDとFMULが同時に稼動できるの?
DirectPath Singleのでかい命令をガンガン入てけばとんでもない性能になるな・・・。

>>65
Athlonは上述の通り、別にありそうな気がする。
PMだと、共通に使うALU(64bit以下の論理演算を1clkに1回できる)が2個あるだけに見える。
正確には、別にあるけどポートが競合して同時には稼動しない。
たくさんある実行ユニットは、パイプラインを共有しているものがあり(整数ALUとMMXALUとか)、
競合すると同時には実行できないのだ。
使用CPUとそのコードを晒してくれれば何が起こっているか分析したい。

あと、同じレジスタに続けて書き込むと2clkストールするとPIIIのマニュアルに書いてあった。
そのストールの間に整数命令を実行できたとか?(レジスタリネーミングで回避できないんかな)
PIIIはandpsが2-2だったんだよね。片方のALUしか使ってないかも。
P4も片方かな。P4はどんなμopに分解してるのかわからん。P4使いいないか。

pand xmm0,xmm0を8個の後dec ecx/jnz。これをPenMで9clk/loop。
1ループあたりALU(2個ある)行きのμopが18個なので9clk。
ALUの数で理論値を出しているので、ここでは整数命令を入れると必ず遅くなる。
理論値は出せたものの、結構シビア。使用レジスタによってコロコロ変わる。
xmm0,xmm0 xmm1,xmm1 xmm2,xmm2・・・とすると11clk/loop。意味不明。
ここで3と4の間にand eax,ebxをはさむと12clk、nopをはさむと10.66clk。誰か説明ぷりーず。。

68 :paddusb:05/02/08 09:39:30
このあいだ、僕のかよってるCPU行ったんです。PentiumIII。
そしたらなんか命令がめちゃくちゃいっぱいで入れないんです。
で、よく見たらなんか別スレッドが来てて、エンコード中、とか書いてあるんです。
もうね、アホかと。馬鹿かと。
お前らな、新作アニメ如きで普段やってないエンコしてんじゃねーよ、ボケが。
まほらばだよ、まほらば。
なんかでかい命令とかもいるし。1命令4μopでCPUか。おめでてーな。
よーし複雑命令デコーダ使っちゃうぞー、とか言ってるの。もう見てらんない。
お前らな、実行ユニットやるからデコーダ使わせろと。
CPUってのはな、もっと殺伐としてるべきなんだよ。
リオーダバッファに入った奴同士、いつ実行ユニットが競合してもおかしくない、
足すか足されるか、そんな雰囲気がいいんじゃねーか。マクロ命令は、すっこんでろ。
で、やっと入れたかと思ったら、隣の奴が、ロード・ストア同時で、とか言ってるんです。
そこでまたぶち切れですよ。
あのな、キャッシュバンクずらして使うなんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、ロード・ストア同時で、だ。
お前は本当にそのμopリタイヤできるのかと問いたい。問い詰めたい。小1時間問い詰めたい。
お前、同時にできるぞって言いたいだけちゃうんかと。
PenIII住まいの僕から言わせてもらえば今、僕らの間での最新流行はやっぱり、
MMX、これだね。
MMXとMMX2。これが通の最適化。
MMXってのはレジスタが長めになってる。そん代わり小回りが効かない。これ。
で、それにMMX2(SSE整数命令)。これ最強。
しかしこれを実行すると次にFPUを使うとき切り替えが必要という危険も伴う、諸刃の剣。
素人にはお薦め出来ない。
まあお前、ビデオエンコードは、Pentium4でも使ってなさいってこった。

69 :デフォルトの名無しさん:05/02/08 10:41:31
>>67
たとえば
http://sourceforge.net/projects/md5crk/
など。

x86の論理演算とMMXの論理演算またはSSE2の論理演算を混ぜてる。

70 :1:05/02/08 11:08:57
>>69
コードはどこ?


71 :69:05/02/08 12:11:50
>>70
CVS

CVS知らなかったら、とりあえず
http://cvs.sourceforge.net/viewcvs.py/md5crk/
から覗いてみて。

72 :1:05/02/09 12:09:19
すまん。全然わからん。orz
できればここにコードを貼ってほすぃ・・・

73 :1:05/02/09 12:13:41
別の話題でも。

色々調べて思ったのは、同時にμopを発行できる実行ユニットの数を増やすのは大変だということ。
Athlonの、マクロ命令の段階でスケジュールして振り分けてしまうのは、今更ながら感心。
(スケジュールを2段構えにして負荷を軽減)
デュアルコアよりも、実行ユニットを倍に増やしたHTの方がいいじゃん、とか思ってたが
これはOoO周辺を作るのがすごく大変なのだろう。
lp:
addps xmm0,[esi]
addps xmm1,[esi+16]
addps xmm2,[esi+32]
addps xmm3,[esi+48]
add esi,64
dec ecx
jnz lp
これはPMで11clk/loopなのだが、mulps xmm1,[esi+16] を追加挿入すると10clkになる。
まあ、addを全部mulに置換すると理論値の8clk/loopを叩き出すわけだが。
add系が不思議に遅い。

74 :デフォルトの名無しさん:05/02/09 12:22:08
>>1
漏れは>71じゃないが、そのURIにディレクトリ構造がそのまま見えているのだが。
coresをクリックしてみるくらいできないわけじゃなかろうに。

75 :1:05/02/09 12:50:28
>>74スマソ。
ディレクトリが見えてるのはわかってたが、
適当にクリックしても何も出てこなかったのだ。

今やって、できますた。ありがd
信じられないだろうが、>>73の前に30分ほど試行錯誤してできなかった。

ちょっと見た感じ、SSE2整数と32bitALUを混ぜると
デコーダ的にも悪くないし、
レイテンシの隠蔽にもなるのでイイと思う。
理想状態でALUが余ってなくても現実はストール多いので、
色々な命令を混ぜると速くなるだろう。ソフトパイプラインだね。

76 :デフォルトの名無しさん:05/02/09 17:19:23
>>73
糞ですねw

77 :デフォルトの名無しさん:05/02/09 23:39:03
SSE2だけの演算でも、
MD5みたいに同じレジスタに頻繁にアクセスするものは、
複数まぜることでレジスタストールのペナルティを逃れて性能がアップする。

78 :デフォルトの名無しさん:05/02/10 02:09:30
普段はそれをやろうとしてもレジスタが足りなくなるな。
うまくいくと気持ちいい。

79 :14 ◆TimpoiKAMI :05/02/10 02:34:34
俺がやってる分野は、L/Sネックなんだよなー
だから、AMD64でやったら明らかに効率が上がった。

80 :デフォルトの名無しさん:05/02/10 06:11:22
>>78
レジスタ足りなくなってロードストアしても、それでも速かったりするんですよ。
ロードストアが空いてれば同時に実行できちゃうから。

81 :1:05/02/15 11:25:55
>ロードストア
メモリは遅いというイメージが離れないんだよなあ。
整数で汎用レジスタが足りないときはmovdでMMXに退避させたりしたことがあるw
確かにmovはALU食うからロードストアが空いてたらそっちがいいんだよな。

しかしSSE/2の最適化を詰めていくとPM弱いな。
小回りはK8以上だと思うが、メモリ帯域や重い乗算平方根に対して力なし。
AMDの√×÷は神の領域だが、P4にすら負ける細腕PM・・・。


分岐をちょっとやってみた(いつものようにPentiumM)。

ループの中にif〜then〜elseみたいな構造を作り、
条件分岐で分岐してもしなくても3clk/loopのコードを用意した。
0〜7fffhのランダムな整数が閾値以上かどうかで分岐する/しないを決める。

ここで閾値を0や8000hにすると3clk/loop。
4000h(分岐は完全にランダム)にすると12.5clk/loop程度になった。
単純に予測ミスのペナルティを出すと、2回に1回の予測ミスで9.5clkの差なので、
なんと19clkもの損をしていることになる。
これがパイプラインの段数なのかはわからないが、思っていたよりかなり大きい。
短いループなので予測ミスの他、ループ処理にも影響があるだろう。

分岐(する/しない)を交互に繰り返すパターンを食わせると4.5clk。
予測はすべて的中していると思われるが、やはりパイプラインが乱れるのだろうか。
最近のCPUらしく分岐予測ミスは痛いようだ。
(ループなど、完全に予測できる分岐に関してはP6に比べて速くなっている)

82 :デフォルトの名無しさん:05/02/15 13:03:58
そんな短い処理だと分岐が確定する前に次の分岐が何個も来てしまう
同じ位置の分岐をパイプラインの中に何個も貯めこんで履歴テーブルは大丈夫なのか

83 :1:05/02/15 13:16:55
確かに、パイプラインの中に分岐命令が多数流れている。
分岐を含めて6命令を3clkでやっているのはすごい。

20clk/loopくらいのでやり直してみるわ。

84 :1:05/02/15 13:58:28
初心者のためのアセンブラリンク。
http://www.fides.dti.ne.jp/~tokai/vc/mmxab2.html
Cがわかっていれば、この辺をコピペして動かしてみる。
http://ray.sakura.ne.jp/asm/
基本的な整数命令を覚える。
http://homepage1.nifty.com/herumi/adv.html
FPUやSSEなど。最適化の色々な話がある(つーか分岐の話はここにあったな)。

85 :14 ◆TimpoiKAMI :05/02/15 19:14:59
久々のカキコでしかも亀レス。

>>63
AMD64だったら、MMX論理演算も整数ALU使えyp とか思ってみたり。
ていうか、128ビット演算のSSE2はあまり速くないし(MMXのおよそ半分)
64ビット演算のMMXはレジスタ本数少なくって虐げられてるし、
64ビット演算の整数ALUは…ANDNがない(ワラ

>>65
・デコード条件制約
・発行条件制約
・じつはヘンなトコでストール
だったりする可能性があるので、シムでプロファイル取ってみれ。

>>67
>DirectPath Singleのでかい命令をガンガン入てけばとんでもない性能になるな・・・。
俺が測ったときは、DoublePathはデコーダをふたつ占有してますた。

>>81
俺が言うところのL/Sってのは、実行ユニットとキャッシュのインタフェイスね。
通常用途だとAMDでもBaniasでもキレイに働いてくれるんだけど、
カリカリにチューンし出すと、L/Sが真っ先に参ってる希ガス。

分岐は詳しくないのでパス。ただ、二重ループの内側を
CMOV にしたら、ちょっと速くなった。

86 :1:05/02/16 10:46:32
>>85
そうか、Athlon64はその名の通り整数レジスタが64bitあるんだ。
初め32bitの書き間違いかと思ったよ。整数とSSEが16本ずつとは・・・、
非64bitで使っていたら、MMXを使わないMMXPentiumぐらいもったいないぞ!
・・・MMXはandnがあるけどnotがないんだよねえ。

ところでDoublePathは一般的な言葉?
検索しても日本語ではこのスレぐらいしかかからない(w
(今やってみたらなぜかここもかかんなくなってた)

長いコードにしてやってみた。
結果は分岐の向き固定で22clk/loop、ランダムで26clk。
いや、たった8clkのペナルティで済むわけないんですが・・・。
交互にしたときも22clk/loop。

よく考えたら>>81の短いコードだと、予測失敗のときに、多数の予測分岐が破棄される。
でもパイプラインの段数分損するの自体は変わらないと思う。
パイプラインが10段程度というのはありえないのだが・・・。

87 :デフォルトの名無しさん:05/02/16 12:45:04
>>86
ランダムのつもりでも実はパターンを読まれていた

88 :1:05/02/16 13:07:30
>>87
質がよくないとは聞いていたが、
C標準のrand関数はそこまで性能が悪かったのかw

でも最近の分岐予測って精度はいいんだけど人間には全然予測できないなー。

89 :デフォルトの名無しさん:05/02/16 17:28:35
>>88
良い乱数と言えばMT

90 :デフォルトの名無しさん:05/02/16 18:41:54
>>86
関数呼び出しの時にパイプラインが破棄されてたって案はダメでつか?

randって関数でそ。無条件分岐とリターン(これも分岐)があるはず。

マクロ版randってのもあるんだっけ。
どういうコードだろ?

91 :デフォルトの名無しさん:05/02/16 19:13:30
>>90
randは乗算一個なんで・・・


92 :デフォルトの名無しさん:05/02/16 22:27:07
>>91
MT ってそんなに簡単だったんだ!!

93 :デフォルトの名無しさん:05/02/16 23:37:01
結局乱数テーブルの質じゃないの?

94 :デフォルトの名無しさん:05/02/16 23:37:15
randは線形合同だから

95 :デフォルトの名無しさん:05/02/17 03:27:39
VC6のCランタイムのソースを見ると、
return ((x = x * a + b) >>16) & 0x7fff ;
と書いてあるね。aとbは定数ね。


96 :14 ◆TimpoiKAMI :05/02/17 08:56:06
いまどき線形合同法で実用に耐える乱数列が得られると思ってる香具師ぁいねえよな?
これ以上は擦れ違いなので別擦れに誘導してくれ。

97 :たぶん 14 ◇TimpoiKAMI のストーカー:05/02/17 16:58:47
同じくスレ違いだが、MT使っても安直にstd::time()関数をseedに使ってる香具師も
問題だとか言ってみる。
ソフトの起動時刻が大体わかれば擬似乱数系列のクラックも可能になります。
もち定数なぞ問題外。
seedの値だけど、私はWin32APIでいくと、timeGetTime()か、QueryPerformanceCounter()
の下位DWORDあたりを使ひますね。あといろいろ組み合わせてみたり。
これだけで解析はだいぶ困難になります。
つか、ほんの数回呼び出す程度ならstd::rand()でも十分実用範囲。

>>86
> 非64bitで使っていたら、MMXを使わないMMXPentiumぐらいもったいないぞ!

レジスタ論理数の制約のあるx86のコード体系自体がもったねーす。
MSの圧力でAMD互換になる前のIntelの64bit拡張がPentium 4の128本ある物理GRを
ある程度自由に使える仕様だったとしたら(妄想)、かなり遊び倒せた希ガス。
(しかしPrescottの実物がアレじゃいくら命令セットがよくてもどうしようもない気もした)

あと、MMX/SSE*にpnorやpxnorが欲しいと思うの漏れだけか脳?
同じモノ作っててもPPCのAltiVecだとNOR命令があるのでずいぶん書きやすく感じる。
それ以前に3オペランド命令主体でレジスタ32本あるのがかなり大きいと思うけど。

わたしわHacker's Delight厨なので、速度云々じゃなくFP_MUL使ったら負けかなと
思っている。
PenMの性能で困ったことがないのは整数演算主体だからだろうな。

98 :14 ◆TimpoiKAMI :05/02/17 18:43:06
>>97
スレ違いカキコ&未知との遭遇を記念して、
ultimotrip@hotmail.com
を、私のMSN Messengerメンバリストに追加いたしました。

以降、マタリ進行お願いします。

99 :97:05/02/17 22:12:42
話題を戻す方向で。

>>81亀レスになるのだけど

> (ループなど、完全に予測できる分岐に関してはP6に比べて速くなっている)
これはこいつの効果やね。
ttp://www.intel.co.jp/jp/developer/technology/itj/2003/volume07issue02/art03_pentiumm/p05_branch.htm


> でもパイプラインの段数分損するの自体は変わらないと思う。
> パイプラインが10段程度というのはありえないのだが・・・。

うちもこのへんの仕組みは全然詳しくないのですが、たとえば、分岐命令の条件となるフラグ値を
早めに確定させるように命令を再スケジューリングし、フラグが確定し予測ミスが判明した時点で
投機した命令のステージだけを破棄し、パイプラインの全ステージを破棄しなくてすむような
機構にしてるってことは有り得る?
これだとストールのクロックサイクル数はパイプラインの段数より確実に短くなる。

Pentium Mのパイプラインはかなり謎が多ひ

100 : ◆DDDDDDDDao :05/02/17 23:06:22




    ???(゚∀゚)???

80 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)