【骨髄反射】INTEL厨 vs AMD厨 Part21【ｴｸﾞｾﾞｸﾃﾌﾞ】

[過去ﾛｸﾞ] 【骨髄反射】INTEL厨 vs AMD厨 Part21【ｴｸﾞｾﾞｸﾃﾌﾞ】 (797ﾚｽ)
上下前次 1-新

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

1(1): 04/03/31 16:43 ID:5MAm5VI5(1)調 AAS
IntelとAMDのCPU、どちらがいいのかな？徹底的に話し合おう！
最近糞スレが多く立っています。厨さん専用隔離スレですので、
各CPUの変なスレが立っていたら、このスレへ誘導するようにお願いします。

■前スレ
【ﾀﾞﾒﾀﾞｺﾘｬ】INTEL厨 vs AMD厨 Part20【ｵｲｰｽ!】
2chｽﾚ:jisaku

671: 04/04/02 15:26 ID:omMmHH5h(1)調 AAS
明らかに昼夜逆転してる人たちの争いなんだな

672: 04/04/02 15:26 ID:YX8xvRTA(1)調 AAS
知らない間にすごい勢いで書き込み増えてますな・・
昨夜は祭りだったのですか？

絶対に負けを認めませんな、録音大先生は。
しかし「負け」とは客観的なものでありまして、つまりは・・・
そろそろお休みになられては如何かということです。

673: 04/04/02 15:29 ID:DO6Wq7MD(1)調 AAS
ヒットしたのこれだけだす。

外部ﾘﾝｸ:www.google.com"手動（てどう）"

674(1): ◆Rb.XJ8VXow 04/04/02 16:04 ID:1So+4lx1(110/111)調 AAS
>>669
そうなんだけどね、話題がプレスコットの段数を減らすと言うことなんで
その回答は不適切ってことだ。

675: 04/04/02 16:46 ID:JEkEUjy6(1)調 AAS
結局、録音はアセンブラの知識はあるのか？
ネタで誤魔化していたようだがw

676: 04/04/02 16:47 ID:zgDN1JWW(1)調 AAS
話題に乗り遅れてが・・・骨髄反射は笑えるな。
２ちゃん用語で流行らせるか？

677: 04/04/02 16:50 ID:YVfwG9pM(1)調 AA×

678: 04/04/02 16:55 ID:uAXlVUuX(1)調 AAS
使い古したカセットテープってさ
録音してもノイズが乗るし
再生してもノイズが乗るから
使いもんになんないよな

といまさらおもた

679: 04/04/02 17:00 ID:L3ksdLGc(1)調 AAS
使いもんになんないのに遊ばれる奴って何なんだろうな

といまさらおもた

680: 04/04/02 17:30 ID:rgvjt1nR(1/5)調 AAS
>674

もう寝ろ。

681: 04/04/02 17:42 ID:YMCsLNY3(1)調 AA×

682(1): 04/04/02 17:44 ID:eTWtvFj+(1)調 AAS
こいつ録音？

2chｽﾚ:jisaku
60 名前：55 投稿日：04/03/24 10:28 +NbPZPRC
>>59
俺は多分、当時から県内一のスキルの持ち主だが、君は知らん
N/N88-Basic専門だしで
現在は、当時のソフトをエクセルに移しているのだが、かなりの作業だ
応用性重視で、1つのファイルに数万もの数式を埋め込んでるぞ

1GHzクラスのCPUでも、データベースを変更すると数十秒の再計算時間を要する

683: 04/04/02 18:17 ID:DwOhu2U6(43/43)調 AAS
眠いｗ

>>682
懐かしいねN-Basic。PC8001とかの頃のアレだね。PC9801はN88(86)-BASICだったっけ？

ところで関数を一つのファイルに詰め込むって素人目には応用性が無いような気がするんだけど。
エクセルデータシートに数式を撒いてるだけなら普通の使い方だし

684: 04/04/02 18:37 ID:y68w5KuI(1)調 AAS
録音先生、仕事して下さい！
てゆーか他の皆さんもですよ！

685: 04/04/02 18:59 ID:WRI4sDEu(51/51)調 AAS
◆Rb.XJ8VXow11/05 01:21 >>1 > 俺は、３０代後半に突入した、元汎用機系ドキ
ュソ職人ＳＥ。省13 前次ｶｷｺﾐ ri ver 0.32 (2003/08/05)
science.2ch.net/test/r.i/infosys/1013186708/i - 3k - キャッシュ - 関連ページ

◆Rb.XJ8VXow 11/05 01:31 >>1 > 基本情報技術者試験ってSE始めて
どれくらいで取れるもんなの？省18 前次ｶｷｺﾐ ri ver 0.32 (2003/08/05)
science.2ch.net/test/r.i/infosys/1054649464/i - 3k - キャッシュ - 関連ページ

686: 04/04/02 19:48 ID:rgvjt1nR(2/5)調 AAS
最近の録音先生の書き込み時間は常軌を逸してるよな。
録音先生は2chと契約したプロコテの実在人物だったが、実は最近亡くなっていて
その書き込み誘発効果と先生の人となりを惜しんだUNIX板の有志達がinternetを自動巡回し
常に最新の情報をストックするデータベースとと７ヶ国語の自動翻訳機能、
それらから常に最新の情報を使って屁理屈をこねるスクリプトを作った、とか言うオチだったら嫌すぎ。

娘がいるとのことだったが、スクリプトが娘宛にメールを出していたりしたら怪談だよな。

687(1): 04/04/02 19:53 ID:B+btneBB(1)調 AAS
かなり前の発言にツッコミだけど、
>>212windowsの基本のタイムスライス値は基本的に約20msだったはず。
ただ自分で弄ることも出来たような気がするし、
XPは持ってないんでXPは知らんけど、今はそれより短くなってるのかもしれない。

688: ◆Rb.XJ8VXow 04/04/02 20:17 ID:1So+4lx1(111/111)調 AAS
>>687
今は10msだぞ。

689: 04/04/02 20:42 ID:8B7PSzzr(2/3)調 AAS
カナ入力は１文字打つのに１タイプ必要だが速く打てない

ローマ字入力は１文字打つのに数回叩かなければならないが
その分打つ回数を増やすことが出来る

パイプラインのお話は以上で。

690(1): 04/04/02 21:12 ID:ih46VywT(1)調 AAS
おまえら、プレスコが投売りですよ！
外部ﾘﾝｸ:www.amazon.co.jp

691: 04/04/02 21:14 ID:rgvjt1nR(3/5)調 AAS
>690

激しく笑った。

確かに熱くはなるが・・・。

692: 04/04/02 21:19 ID:OHvfgpI9(1)調 AAS
カナ入力とローマ字入力の使い分けもできない人間が居るのはこのスレですか？

693: 04/04/02 21:38 ID:MdNIgtnK(1/2)調 AAS
使い分ける必要ないだろ、禿げ！

694(1): 04/04/02 21:54 ID:OvBUPB2M(1)調 AAS
結局，最高のプロセサはIBM Powerになるのかよ……(´･ω･`)ｼｮﾎﾞｰﾝ

695(1): 04/04/02 21:55 ID:jWwqBYXq(3/5)調 AAS
ありゃ、一晩経って来てみたら凄く伸びてますね(^^;

すみません、このままでは◆Rb.XJ8VXowさんがあまりにも気の毒なので・・・

パイプラインというのはフェッチや実行等の工程に分かれているからこそ意味があるのであって、一クロックでそれらをすべてこなせるのであれば必要無いんだと思いますよ。
もちろん物理的には不可能なので、工程を分けざるをえないんですけどね(^^;;

696: 04/04/02 22:00 ID:rgvjt1nR(4/5)調 AAS
>695

気の毒、と言うか、他人の書き込みに対する否定＋煽りって言う発言を繰り返したら
叩かれるのは当たり前だろう・・・。

697(2): 04/04/02 22:07 ID:8B7PSzzr(3/3)調 AAS
>>694
x86はあと数年は生き残る
Powerはcellが出るまでの命かもね

ところで昨日の書き込みをじっくり斜め読みしたんだけど
録音さんいつのまにかアム厨になってません？
IntelはIPC低いのが分かるようになったなんて成長したじゃないですか。

698: 04/04/02 22:10 ID:rgvjt1nR(5/5)調 AAS
>697

先生を構成するスクリプトに重大な改変が加えられたのかも知れないですね。

699: 04/04/02 22:10 ID:o/Xxr1IC(1)調 AAS
昨日祭りだったのね･･

700: 04/04/02 22:14 ID:MdNIgtnK(2/2)調 AAS
>>697
スクリプトのバグです。
いま、修正ﾊﾟｯﾁを当ててる最中。

701: 録音名語録上げ 04/04/02 22:26 ID:utVqEoHq(63/63)調 AAS
323 ： ◆Rb.XJ8VXow ：04/04/02 01:31 ID:1So+4lx1
>>322
お前さん何を言ってる？
クロックが同じならパイプラインが深かろうと浅かろうとストールが無いのならIPCは同じだぜ？
それすら理解出来ないのかい？

702: 04/04/02 22:43 ID:MY701I0S(1)調 AAS
なんでCellプロセッサみたいな妄想全開なのを信じるのか疑問･･･

703: 04/04/02 22:51 ID:bnEyzX38(1)調 AA×

704: 狸 04/04/02 23:04 ID:dmH6705R(1)調 AAS
-----------------------録音語録-------------------------------------------
そりゃ、取らぬ前の皮算用はこけたわけだが、それって最初から虫が良すぎる話だしなぁ。

----------------------------------終了------------------------------------

705: 04/04/02 23:12 ID:oLTGLg8S(1)調 AAS
一日で400もレスが付くとは・・・流石厨スレ

706(1): T.A. 04/04/02 23:16 ID:rzN965ML(1/2)調 AAS
こんばんわ。今夜も懲りもせずやってまいりました。
それにしても、こんな凄いお祭り騒ぎになってるとは・・・ログ読み返すのが大変でしたよ。
では、私も早速厨スレらしく煽ってみますか。

>250 ： ◆Rb.XJ8VXow ：04/04/01 23:42 ID:3Z/vwf1e
>うーん、T.A君はどうやらトレースキャッシュに意地でも64bitアドレスを記憶させたいらしい・・・・（なんでじゃ！！！
>もう一度基礎から勉強し直せよ。
>ってか、お前以前からアフォ丸出しだぜ。

じゃあ、仮に64bitモードでもμOPが32bitだったと仮定してみる。
トレースキャッシュの役割はデコード済のμOPを格納しておくことで、x86命令をデコード
する手間を省くためにある。
ということは、トレースキャッシュにはデコード済のμOPと共にデコード前のx86命令が
どんな命令だったのかを識別する情報が必要になる。
(変換元が何か判らない状態で変換後のデータだけ持っていても何の役にも立たない。)

ところがx86命令は1～15Byteの可変長命令だから、このままトレースキャッシュに格納する
のは非常に効率が悪い。じゃあ、どうするか？

個人的な予測では「元のx86命令の開始アドレスだけを格納しておく。」のが最も簡単で
回路も単純で済むと思う。
(トレースキャッシュはスピードが命だから高速化のためには出来るだけ単純な回路にしたいはず。)
当然、64bitモードではx86命令の開始アドレスも64bitになるから、少なくとも1つは64bitの
データがトレースキャッシュに格納されることになる。

となると、トレースキャッシュには64bit固定長のμOPを格納する方が望ましい。
(前述の通り、回路の単純化を図る場合64bit/32bit混在より64bit固定長の方が有利だから。)

・・・と考えた訳だが。

707(1): 04/04/02 23:32 ID:IcNolcBS(1)調 AAS
おもしろいスレができた

【AMD64】イマドキAthlonXP買ってる奴はアフォ（ｗ
2chｽﾚ:jisaku

708(2): T.A. 04/04/02 23:50 ID:rzN965ML(2/2)調 AAS
＜続き＞

まあ、実際には１つのキャッシュ領域に開始アドレスとμOPを一緒に格納するのは効率が
良くない。
(μOPのサイズが一定でも、発行数は元の命令によって異なるので全体としては可変長化してしまう。)

実際には次のような構造なんじゃないかと思う。

・まず命令エントリテーブルを用意する。ここにはx86命令の開始アドレスとトレース
　キャッシュ内の開始アドレス・μOPの個数を対で格納する。
　(トレースキャッシュは小さいので、こちらのアドレス・個数は16bit程度でも構わない。)
・デコード済のμOPはトレースキャッシュに格納され、その開始アドレスと元のx86命令
　の開始アドレスが命令エントリテーブルに格納される。
・デコーダはまず、デコード対象のx86命令の先頭アドレスを命令エントリテーブルから
　サーチする。
　ヒットした場合は、一緒に格納されているトレースキャッシュのアドレスと命令個数を
　参照してトレースキャッシュからデコード済μOPを引き出す。

で、命令エントリテーブルは32bitモードの場合は開始アドレスを32bitで格納し、64bitモードでは64bitで格納する。
当然、これらはチップ上に実装された時点で容量が固定化されるから、64bitモードでは
32bitモードと比較して半分強程度のエントリ数しか使用できなくなる。

ただ、この構造では命令エントリテーブルかトレースキャッシュのどちらか一方の容量が
枯渇した時点で、もう一方の容量に余裕があってもそれ以上は利用できなくなる欠点が
あるので、実質的には32bitモード時の半分程度まで効果は落ちると思う。

709(2): 04/04/02 23:55 ID:jWwqBYXq(4/5)調 AAS
>70
前段のInstruction Decoderでx86命令時と等価のμOP群に変換されますから、x86命令の開始アドレスだけを格納するという線は無いですよ。
それにμOPのサイズですが、確か64bitRISCプロセッサでも命令コードが32bit固定長のものが在ったと思います。
ですから必ずしもアドレスサイズと一致にするとは限らないですよ。
即値データに関しても内部レジスタに入れてから演算すれば問題無いですし。

710: 709 04/04/02 23:56 ID:jWwqBYXq(5/5)調 AAS
>>708
へのレスでした。すみません＿|￣|○

711(1): 04/04/03 00:06 ID:O/bViLe6(1)調 AAS
>命令エントリテーブルは32bitモードの場合は開始アドレスを32bitで格納し、64bitモードでは64bitで格納する。
これは流石に頭悪すぎだろ・・・

712(2): T.A. 04/04/03 00:14 ID:u0cSKxtb(1/4)調 AAS
>>709
私が参考にしたのはここのブロック図とパイプラインステージなんですが・・・

外部ﾘﾝｸ[html]:www.atmarkit.co.jp

このブロック図を見る限りだと、BTB・命令TLBがデコードやトレースキャッシュ
より前段にいるように見えますよね。
あと、パイプライン構造にも先頭に「次の命令ポインタをトレースキャッシュへ」
とあったので、このように解釈したんですが・・・この図が間違いなのかなぁ・・・
(この解説を書かれている方は元x86プロセッサのアーキテクトらしいので、極端に
間違っているとは思えなかったもので。)

まあどっちにしても、元々非公開の部分が圧倒的に多いものから推測しているので
間違ってたら笑い飛ばされても仕方がないんですけどね。(^^;

713: 04/04/03 00:21 ID:04XV+vV7(1/2)調 AAS
録音が夫じゃ、妻も別居したくなるっつーの
金だけもらって( ﾟДﾟ)ｳﾏｰ!

714(2): 04/04/03 00:36 ID:rI3O72Sy(1/5)調 AAS
デコード前のx86命令がどんな命令かを記憶しておく必要性が
わからないんだけど・・・
何故もとの命令が識別できる必要があるの？

715(1): 04/04/03 00:36 ID:g80Jz3LW(1)調 AAS
録音もTAさんのように独自の理論を展開して欲しいな。たとえそれが糞理論でも（藁
どの道正解は無いんだし。（ｉｎｔｅｌが公表してない。つーかするわけない）

骨髄レスに骨髄レスで返すのは見苦しい。

716: [ ] 04/04/03 00:36 ID:o+2HQpqG(1)調 AAS
test

717: 04/04/03 00:40 ID:OCh08WfD(1)調 AAS
AMD (Advanced Micro Devices, Inc.) へ

この手紙をもって弊社のCPU市場のパイオニアとしての最後の仕事とする。
まず、NetBurstの問題点を解明するために、ドレスデン Fab 30にArchitecture解析をお願いしたい。
以下に、CPU開発についての愚見を述べる。
CPUの性能向上を考える際、第一選択はあくまでクロックであるという考えは今も変わらない。
しかしながら、現実にはPentium4がそうであるように、行き過ぎたクロック向上は
IPCの低下や消費電力の激増をきたした新コアを生む事態がしばしば見受けられる。
その場合には、シュリンクを含む消費電力低下と更なるクロックの向上が必要となるが、
残念ながら90nmプロセスは未だ満足のいく成果には至っていない。
これからのCPU開発の飛躍は、クロック以外の性能向上の発展にかかっている。
弊社は、御社がその一翼を担える数少ないメーカーであると信じている。
能力を持った者には、それを正しく行使する責務がある。
君にはIPC向上の発展に挑んでもらいたい。
遠くない未来に、もっさりしたCPUがこの世からなくなることを信じている。
ひいては、Prescottの屍を解析の後、御社の研究材料の一石として役立てて欲しい。
屍は生ける師なり。
なお、自らCPU開発の第一線にある者が独自のx86互換64bit規格を提唱できず、
AMD64に追従することを心より恥じる。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Intel Corporation

【心から】財前教授のガイドライン【恥じる】
2chｽﾚ:gline

718(3): 04/04/03 00:41 ID:o1MOikWY(1/3)調 AAS
NothwoodとPrescottのダイ写真を比較してみると、Prescottでは
トレースキャッシュの容量が1.6倍くらい増えているのが分かる。
それにも関わらず、NorthwoodとPrescottでは
格納できるμOP数は12k個で同じ。

719: 04/04/03 00:52 ID:8n5hPsaA(1)調 AAS
「GET Ride アムドライバー！」
未来の地球･･･人類は、数年前に出現した「プレスコ」と呼ばれる謎の兵器の襲来を受けていた。
「プレスコ」の前には、人類が保持するいかなる兵器もまったく歯が立たず、地球はこの正体も目的
もわからない敵に怯えていた。そんな地球の救世主となったのが最新工学「アム　テクノロジー」に
よって生み出された「アムドライバー」と呼ばれる戦士たち。圧倒的な強さを誇る「アムドライバー」は、
「プレスコ」を次々と撃破。たちまち世界のヒーローとなる。
外部ﾘﾝｸ:www.tv-tokyo.co.jp

720: T.A. 04/04/03 01:25 ID:u0cSKxtb(2/4)調 AAS
>>711
言われてみると・・・確かに頭悪いですね。(^^;
現状では物理アドレスレベルでは52bitに制限されてるから、64bitモードでも64bit
フルには必要ないかな。

>>718氏が指摘されているようにトレースキャッシュの容量が1.6倍にも関わらず、
格納できるμOP数が変わらないってことは・・・32bit/64bit共に52bit固定長と
考えたほうが良いのかも。

>>714
トレースキャッシュの効果は、
「トレースキャッシュにヒットしている間は(より遅い)デコードステージを省ける。」
点にあるわけですから、機能的には

x86命令→トレースキャッシュ→μOP　＝　x86命令→デコーダ→μOP

となりますよね？
デコーダの場合、マイクロコードとロジック回路によってこの変換を行うわけですが、
トレースキャッシュの場合、既に変換済のμOPを再利用する訳です。
ところが、トレースキャッシュには多数のx86命令から変換されたμOPが混在しているので
識別情報が無ければ、対応するμOPを特定することが出来ないと思うのですが。

721(1): 04/04/03 01:33 ID:Tr51fGHY(1/2)調 AAS
録音先生きませんね。
寝てるのかな？

722: 04/04/03 01:37 ID:04XV+vV7(2/2)調 AAS
>>721
辞書データに致命的なバグが見つかったのでメンテ中

723(2): 04/04/03 01:37 ID:PS2XUDeT(1/8)調 AAS
>712
図は>305の示すHPのと微妙に違ってはおりますが、大まかには合っていると思いますよ。
このパイプラインの図に記されている内容はトレースキャッシュ以降のものですので、
「次の命令ポインタをトレースキャッシュへ」というのは、「命令ポインタを次に実行されるμOPに合わせる」という事だと思います。

>715
こうやって色々と考えてみるのが楽しいんですよねｗ

>718
という事はNorthwoodよりもμOPのサイズが大きくなっている可能性が高いですね。
Prescottは元々64bit拡張をされていますから、そうせざるを得ないのかもしれません。

724(2): 714 04/04/03 01:53 ID:rI3O72Sy(2/5)調 AAS
ダメだ、まだわからん。
トレースキャッシュ内のμOPは並び順どおり実行されるだけじゃないの？
何故キャッシュヒットしてるときにx86命令がまた出てくる必要が？

・・・つか俺トレースキャッシュの構造自体が間違って把握してる？

725(2): 04/04/03 01:57 ID:QX0EpvtQ(1/8)調 AAS
>>723
64bitと無関係にアドレス拡張もしているから、その分トレースキャッシュ上のアドレス情報
は増えているだろうね。
素人考えだけど、トレースキャッシュ部は「このアドレスからの命令をよこせ」って言われる
わけで、元のアドレスを知らないと仕事にならないだろうから。

ただ、uOPを実行する演算パイプラインは元のアドレスを知らなくても困らないし、整数演算
パイプラインは32Bit幅のままなのだから、uOP自体は32bit用じゃないのかな。

726: 04/04/03 02:06 ID:PS2XUDeT(2/8)調 AAS
>724
その解釈でいいと思いますよ。
分岐命令までμOPに変換されるとしたら、実行順序も自在に変えられるんですけどね。

727(2): 04/04/03 02:09 ID:rI3O72Sy(3/5)調 AAS
＞実行パイプラインはマイクロオペレーションを実行していくが、
＞その中に分岐がある場合、その分岐の履歴はマイクロオペレーション・ベースの
＞トレース・キャッシュも指すようになっている。
＞もし、トレース・キャッシュに詰め込まれたマイクロオペレーションにヒットすれば、
＞もはやx86命令のデコードは実行されず、直接トレース・キャッシュ内の
＞マイクロオペレーションを使って、メインの実行パイプラインが
＞動作していくのである。

>>712で挙がってた記事を読んでるとこう書いてあるし、
実行時にx86命令のアドレスからトレースキャッシュ内のμOPの位置を
割り出すわけじゃないと思う

728: 04/04/03 02:16 ID:qgZgxHe1(1)調 AAS
つまり、トレース･キャッシュはTBTBで独立して分岐予測するでFA？

729(2): 04/04/03 02:23 ID:QX0EpvtQ(2/8)調 AAS
>>727
トレースキャッシュ上にあるのが、本当に目的アドレスかどうかを調べるのに、
x86レベルのアドレスを持っていると思う。

730(2): 04/04/03 02:39 ID:PS2XUDeT(3/8)調 AAS
>725
アドレス情報だけで1.6倍にも膨れ上がるとは考え難いのでμOPもサイズアップしたのだと思ったのですが、どうなんでしょうね？
外部ﾘﾝｸ[htm]:pc.watch.impress.co.jp
を見るとモード毎に異なるμOPを発行しているようですし。
もっとも今までのサイズでも十分対応可能だったり、モードの変更を示すμOPを挿む事で実現してるのだったらサイズアップする必要も無いですけどね(^^;

>729
その辺りは従来のコードキャッシュと同じなんでしょうね。

731(1): T.A. 04/04/03 03:10 ID:u0cSKxtb(3/4)調 AAS
失礼。ちょっと弟のマシンのトラブルを見ていて席を外してました。

>>723
>こうやって色々と考えてみるのが楽しいんですよねｗ
そうですよね。いわゆる「思考実験」というやつですが、こういうのって
他人の意見を頭ごなしに否定するとちっとも面白くないんですよね。
録音先生にはそういう楽しみ方は理解できないのかな？

>>724
ああ、なるほど。ループ構造を主体にした場合は確かに並び順だけ合って
いれば問題ないですね。
でも、実際のコードだとループ構造の中に分岐が入ったり、別関数を呼び
出したりと並び順を乱してしまう要素が多いのでちょっと無理があるような
気がしますが。

>>727
私も読み込みが足りなかったかも。
でも、>>729氏が指摘されている通り、x86命令のアドレスは少なくとも
保持しているだろうと思います。
(でないと、今コード中のどこを実行しているかCPUが把握できなくなるので。)

>>730
その記事は私も見てはいたんですが・・・ちょっと気になるのが

「NetBurstのパワフルな(トランスレートの)メカニズムによって、同じMacroOPs(x86命令)でも、様々な異なるオペレーションモードのトランスレートができる。(以下略)」

という部分なんですよね・・・機能的には確かにパワフルなんだろうけど、トレース
キャッシュなんて仕組みが必要な位だから、性能的にはさほどパワフルではなさそうな
気がするんですが・・・

・・・しかし、先生がいないとこんなまともなスレになるんですねぇ・・・

732(1): 04/04/03 03:11 ID:27WX4OCF(1/3)調 AAS
この落差の繰り返しがなんとも

先生は寝たふりですか？
ネタフリ？

733: 04/04/03 03:20 ID:QX0EpvtQ(3/8)調 AAS
>>730
確かに、μOP自体のサイズも増えていないと1.6倍ってのは苦しいですね。
>>725のOP自体は32bit用ってのは、μOPによって行われる演算は32bit演
算というつもりでしたが、μOP自体の話の最中にする事ではなかったです。

サイズが増えたのは、内部レジスタ数やμOPが区別しなければならない命
令(SSE3等)の増加じゃ説明つかないかな。

734: 04/04/03 03:31 ID:KPRq8ILY(1/5)調 AAS
>732

先生は。録音スクリプトは今、メンテ中です。

735: 04/04/03 03:32 ID:QX0EpvtQ(4/8)調 AAS
>>731
＞「NetBurstのパワフルな(トランスレートの)メカニズム(以下略
NetBurstって、オンチップ CMSみたいなものだしね。

736: T.A. 04/04/03 03:38 ID:u0cSKxtb(4/4)調 AAS
いずれにせよ、>>718氏の指摘通りNorthwoodとPrescottで格納できるμOP数
が変わらないということは

「Prescottでのトレースキャッシュ増量は見かけ上の容量だけ。」

ということになるわけで、そうなるとレイテンシが増加した分、トレース
キャッシュの効果は薄くなっていることになりそうですね。

それでも性能的にはNorthwoodとほぼ同等か場面によってはそれ以上になって
いるということは、２次キャッシュ増量とALUが32bit*2になった効果の方が
大きいという事なんだろうか？
(いくらなんでも32bitモードでは片方のALUは使わないなんてこては無いと思うし。)

・・・ついでに、私が推測していた
「64bitモードでは32bitモード時に比べ、トレースキャッシュの効果が半減する。」
という説もほぼ間違いでしょうね。(^^;

737(1): 04/04/03 03:48 ID:27WX4OCF(2/3)調 AAS
外部ﾘﾝｸ[html]:www.atmarkit.co.jp

738(1): 04/04/03 04:34 ID:biXzaaf1(1)調 AAS

739: 04/04/03 04:51 ID:Ne/9c65b(1)調 AAS
>>738
無駄な事するな、厨房。

740: 04/04/03 05:45 ID:98m4AmAY(1)調 AAS
税金の時もそうだが、録音先生は反論の使用のないマヌケな事すると一定時間雲隠れするのは仕様です。

741(3): ◆Rb.XJ8VXow 04/04/03 06:21 ID:j1o0NWBg(1/7)調 AAS
お、やっとるな（笑
>>706-708
T.A君やっと自分なりの考え方を出したね。
uOPにとってみればデコードさえ出来れば元の命令は不要だということです。
翻訳後の命令もブランチが無ければ順次処理されて行きますから各命令に64bitアドレスを持つ必要は全く無く
固定長であれば事足ります。
そして必要なのは命令カウンタであり64bitの幅は要りません。
次に、uOPバッファは小さいですから必要に応じて破棄されます。
ここで問題になるのが再デコードをする為のアドレスです。
皆さんが感じているようにx86は可変長ですからそのままでは直接読み込むアドレスが判らなくなる訳ですね。
ですが、再読込する位置は限られます。
そう、ブランチ先なんです。
プログラムは通常後戻りしませんから消化（実行）した命令は破棄してよいのです。
但し、ブランチ先への戻りは有り得る訳ですからここを記憶する必要が生じます。
x86は元々可変長なので実アドレスを格納する必要があります。
とはいえ64bitにする必要は全くありません。
何故ならば、プログラムは一度メモリに全て読み込まれ（スワップ吐き出しあり）て実行されることになる訳ですから
開始位置からの連続するストリームと考えて良いのです。
そしてプログラムの大きさが64bitを必要とすることはありえません。
結果、各スレッド毎に変位アドレスを持つだけでよい事になる訳です。

742(3): ◆Rb.XJ8VXow 04/04/03 06:36 ID:j1o0NWBg(2/7)調 AAS
>>737
そこに書かれているようにAMD社がAMD64の発表した時期にINTELもIA-32eへ踏み出せばINTEL色の濃さを
演出出来たことは疑う必要もないだろう。
だけどそれを出来ない事情がINTELにはあったわけでIA-64の成長がそれだと間に合わないわけだ。
INTELとしては出来るだけ発表を遅らせ、MSにもAMD64対応のOS開発を遅らして頂く必要があったと言う事だ。
そしてそれらは不本意なものもあるが全体としてまずまずな達成と言える。
次に、INTELがIA-32eに踏み出した訳だが、当然ながらAMD64互換の様相となる。
しかし発表してしまえば、後は如何とでもなるわけでこれからも拡張命令においてINTEL色の濃い演出が可能
だと言う事だ。

743: 04/04/03 07:36 ID:Tr51fGHY(2/2)調 AAS
>>742
64bit化技術に際して、AMDは特許を取っているのでしょうか？

744(5): 04/04/03 07:42 ID:FkN9EIqi(1/3)調 AAS
>>741
オペランドにメモリを指定している場合はどうなるんだ？
64bitモードの場合、64bitのアドレス値が必要になるんじゃないか？

745(2): 158 04/04/03 08:07 ID:skQ3n0jX(1/6)調 AAS
>>744
その質問をすると、μOPSの構造を分析するためにトレースキャッシュを
解析しているのに、μOPSの実装とは無関係にトレースキャッシュに32bit
でアドレス情報を格納する方法論に話をすり変えられる可能性があるよ。
まあ、録音にそこまでの知識はない可能性も高いのだが。

746(1): 04/04/03 08:18 ID:FkN9EIqi(2/3)調 AAS
>>745
MOV reg64, imm64
じゃー、これは？
即値コピーなら逃げられるまい。

747: 04/04/03 08:24 ID:FkN9EIqi(3/3)調 AAS
同じことか・・・

748: 04/04/03 08:29 ID:QX0EpvtQ(5/8)調 AAS
>>746
それのどこにメモリオペランドが存在するのかと小一時間...

749: 04/04/03 08:32 ID:QX0EpvtQ(6/8)調 AAS
あ、逃げられるのを防ぐ為に、より単純な方向に進もうとしたのか、スマソ。

750: 04/04/03 08:36 ID:skQ3n0jX(2/6)調 AAS
x86のニモニックには疎いんだけど、それは64bit即値が示すアドレスの中身を
64bit単位でレジスタにロードするって意味？即値が単なるデータなら趣旨から
外れるし、アドレス情報なら少し馬鹿っぽいけどある程度合理的な逃げ道がある
のよね…出来れば、録音の目の届かないとこで話し合いたいな。

751: 04/04/03 09:31 ID:KPRq8ILY(2/5)調 AAS
>744 >745

珍しくまともな書き方で話とる・・・。とうとうスクリプトが壊れたか・・・。
つーか、そんな書き方出来るなら最初からヤレ。このとんちんかん。

752(2): T.A. 04/04/03 09:37 ID:UhLW37aU(1/2)調 AAS
>>741,742
相変わらず他人の考えを横取りするのだけはうまいね。
年収4500万とやらもそうやって稼いでるんだろうね。

753: 04/04/03 09:48 ID:KPRq8ILY(3/5)調 AAS
>752

確かにコイツって他人が見解を出した後にしか出さないよなぁ・・・。
やっぱりスクリプトなので、ベースになるモノが必要なんだろうな。

754: 04/04/03 09:51 ID:skQ3n0jX(3/6)調 AAS
>>752
前半部は、T.Aさんの示したソースを自分なりに解釈して書いたんだろうね。
後半部で、俺たちが思ってる疑問、解釈をまったく理解できていないことは明白になっているわけだが。

755: 04/04/03 10:03 ID:27WX4OCF(3/3)調 AAS
SunとMSが和解

SunとMSは10年来の係争を和解で終結させ、技術協力協定を結んだ。
MSはSunに、アンチ・トラスト訴訟に関して$700百万、パテント訴訟に関して$900百万、
サーバ製品に関するパテント使用料の前払い金として$350百万、合計約$20億支払う。
SunとMSは、今後、相手のテクノロジーの使用料を払う。

その他、MSのJavaサポートの件や、Javaと.Netの件、SunはXeon (さらにOpteron）製品
にWindowsを搭載できるようになるらしいことも書かれています。

外部ﾘﾝｸ[html]:mypage.odn.ne.jp

#Intel包囲網ですな。

756(1): 04/04/03 10:24 ID:PS2XUDeT(4/8)調 AAS
まあまあ、ﾏﾀｰﾘとできるのならいいではないですかヽ(´▽｀)ノ

>742
結局のところIA-32eを出すきっかけが欲しかったのでしょうね。
AMD64が発表された当時、パーソナルユースではIA-64よりも歓迎されておりましたし、
Itaniumの価格もなかなか落ちてくる気配が感じられなかったのでYamhillを開発したのだと思います。
今までのIntelの戦略を考えると、恐らくYamhillはAMD64以上の機能を持った命令群だったのでしょうね。
その内容には非常に興味が有るのですが・・・もう知る由も無いんですよね。少々残念です(^^;

>744
そういう場合は下位DW，上位DWと分割してトレースキャッシュに格納しているのではないでしょうか？

757(4): 04/04/03 10:43 ID:rI3O72Sy(4/5)調 AAS
>>756
RISCの命令は固定長が基本だから並べるのはナシでは。
64bit即値のロードは、デコーダで
16bitのロード命令４つとかに分割されるものかと思われ。多分。
μOPのサイズが32bit程度なら。

つかIA32eとかの64bit拡張のじゃなくて、現状の32bitデータのロードも
16bitのロード命令２つに分割されてるかと。きっと。

758: 04/04/03 11:11 ID:skQ3n0jX(4/6)調 AAS
>>757
並べるのはナシだったらアドレッシングに厳しい制約がつかない？

759(1): 04/04/03 11:12 ID:PS2XUDeT(5/8)調 AAS
>757
μOPレベルでそれをやってしまうとクロックが余計にかかってしまいますから（その例だと4クロックですかね）、恐らく違うのではないかと。
この辺りはimm32とimm64のクロック数を比較してみれば想像できるのですが、まだ公表されていないみたいですしね(^^;;

私は32bit境界から外れなければOKだと考えていたのですが・・・他の64bitRISCプロセッサはどのように処理しているのでしょうね？

760(2): 04/04/03 11:17 ID:skQ3n0jX(5/6)調 AAS
>>759
>>380のリンクの資料のP292みて。

761: 04/04/03 11:46 ID:QX0EpvtQ(7/8)調 AAS
>>757
μOPの幅は、32bitよりもはるかに大きいよ。
x86命令を効率的に実行する事を考えると、32bitの即値オペランドを最低でも
1つは運べないといけない。

>>760
AMD側はALUやレジスタファイル自体を64bit化してるから、プレスコの参考に
はならないんじゃ？

762(1): 04/04/03 11:56 ID:PS2XUDeT(6/8)調 AAS
>760
Athlon64/Opteronはimm8～imm64までクロック数は変わらないみたいですね。
もしPrescottも同じならば、imm64時においても一括してデータを処理できるようにならなくてはいけませんよね。
そうなるとμOPのサイズを64bit以上にするか、L2キャッシュからデータを取得するアドレッシング・モードを設けているのかもしれません。

763(4): 04/04/03 11:58 ID:o1MOikWY(2/3)調 AAS
>>757
現状の32bitPen4の場合は、32bit即値は2つに分割されてトレースキャッシュに格納されます。
ただし、32bit命令が2つの16bit命令に分割される訳ではないです。
32bit即値を伴う命令は、即値データを分割して、前後の隣接する命令の空いている即値データ領域に格納します。
つまりトレースキャッシュ上のμOPは厳密な意味では固定長ではありません。
32bit即値を伴う命令が連続すると、即値データを格納する領域が不足してしまうので、
ダミーのμOPが追加されます(その分遅くなります)。

参考文献↓ ページ2-72「Assembly/Compiler Coding Rule 48.」
外部ﾘﾝｸ[pdf]:developer.intel.com

764(1): ◆Rb.XJ8VXow 04/04/03 12:03 ID:j1o0NWBg(3/7)調 AAS
>>744
uOPに変換が基本ですぜ。
64bit即値オペランドは3つに分解すればそれでＯＫ

765: ◆Rb.XJ8VXow 04/04/03 12:05 ID:j1o0NWBg(4/7)調 AAS
>>763
> その分遅くなります
騒ぐ必要は何処にも無いぜ。

766: 04/04/03 12:21 ID:SuXDMaFI(1/3)調 AAS
>>763
日本語版の最適化マニュアル

アセンブリ/ コンパイラ・コーディング規則48 ( 影響ML、一般性M)。( 符号拡張された
16 ビット即値としてコード化できない)32 ビット即値を使用する命令同士を、近くに配
置しないようにする。32 ビット即値を使用するマイクロオペレーション(μOP) の直前ま
たは直後には、即値を持たないマイクロオペレーション(μOP) をスケジューリングする
(2-58 ページ)。

767: 762 04/04/03 12:22 ID:PS2XUDeT(7/8)調 AAS
よく考えたらμOPのサイズまで64bit幅に揃える必要は無いですね＿|￣|○
よって>762の下2行は無視してください(^^;;;;

768(1): 04/04/03 12:28 ID:SuXDMaFI(2/3)調 AAS
>>764
3つに分解って・・・？？？？？？？？？？

769: 04/04/03 12:38 ID:PS2XUDeT(8/8)調 AAS
>768
恐らく実行OP，上位DW，下位DWに分けるという事だと思います。
でもμOPが64bitサイズのデータを一括で処理できるとしたら、64bit即値を1クロックで処理できるのですが・・・

770(1): 04/04/03 12:39 ID:rI3O72Sy(5/5)調 AAS
>>763
なるほどー、カコイイ格納方法してるねぇ・・・

771(1): 04/04/03 12:51 ID:SuXDMaFI(3/3)調 AAS
>>770
あの文章はコーディングの最適化について説明してるのであって
別にトレースキャッシュの構造を説明しているわけじゃありません。

772: 04/04/03 13:21 ID:QX0EpvtQ(8/8)調 AAS
>>771
それはわかるけど、最適化が必要な理由として >>763 は説得力あると思う。
トレースキャッシュの容量をケチる手段としても、よさげだしね。
トレースキャッシュ上ではμOPペア毎に合計32bitの即値を保持できて、スケ
ジューラに渡すときに正しい即値データを持つμOPが作られる。
再構成用に余分な1bitが必要になるが16bit減らせるので、15bitの省エネ。
12KμOPSの容量が各15bit少なくなると22Kバイトも少なくてすむ。

773(2): ◆Rb.XJ8VXow 04/04/03 13:58 ID:j1o0NWBg(5/7)調 AAS
まぁ、どっちにしてもIA-32eになったからと言って容量が倍要るなんて
戯言を言い出すのはT.A君だけだろうね。

774: 04/04/03 14:59 ID:o1MOikWY(3/3)調 AAS
私がWillametteで試した範囲では、
　add reg32,ebp
を連続配置（reg32はeax,ebx,ecx,...等、同じレジスタが連続しないようにいろいろ変える）
して実行した場合、IPC=3

　add reg32,0x00007777
を連続配置して実行した場合も、IPC=3

　add reg32,0x77777777
を連続配置して実行した場合は、IPC=1.5

　add reg32,ebp
　add reg32,0x77777777
　add reg32,ebp
　add reg32,0x77777777
　　:
と交互に連続配置して実行した場合は、IPC=3

　add reg32,0x00007777
　add reg32,0x77777777
　add reg32,0x00007777
　add reg32,0x77777777
　　:
と交互に連続配置して実行した場合は、IPC=2

775: 04/04/03 19:02 ID:E6OeIHzG(1)調 AAS
結局今イニシチアブを持ってるのはAMDっと。
Intelはいまいち冴えがなく後手後手。

776(1): 04/04/03 19:21 ID:6Ucrd7W6(1/2)調 AAS
LGA775はピン曲げでマザーを使い捨てにさせる陰謀だと予想

777: 04/04/03 19:28 ID:Dy/ah+WS(1/2)調 AAS
コア欠けならぬピン曲げが登場するわけか･･･

778: 04/04/03 19:52 ID:10rJz9nc(1)調 AAS
でも、ピン折れで死亡するCPUも無くなる訳か。

779: 04/04/03 20:31 ID:Dy/ah+WS(2/2)調 AAS
変わりにピン曲がりするマザーの誕生

780(1): 04/04/03 20:53 ID:alefzJzG(1)調 AA×

781(1): 04/04/03 20:59 ID:KPRq8ILY(4/5)調 AAS
>780

先生はμｏｐって書かないでuＯＰってかくんだよなぁ・・・。
バカっぽいよ。

782: 04/04/03 21:02 ID:KPRq8ILY(5/5)調 AAS
>773
まあ、どっちにしても年収4500万なんて世迷い言言い出すのは先生だけだろうね。

783: 04/04/03 21:12 ID:SoO5eOgh(1)調 AAS
>>776
クレームを避けるためと予想。
ピンはマザボ側だから、簡単に曲がってもインテルは悪くないぞと。

784: 04/04/03 21:39 ID:MIrVXVtg(1)調 AAS
録音の年収
2000万→3000万→4500万
大体一月毎に1．5倍になります。

785(1): 04/04/03 21:51 ID:1zJPPF1n(1)調 AAS
4500万　・・で、どこの貨幣単位で？

786: 04/04/03 22:01 ID:gGVrK1eu(1)調 AAS
リラ

787: 04/04/03 22:16 ID:x4wUbOTc(1)調 AAS
>>781
μの読み方を知らないので変換できないのです。

788: 04/04/03 22:40 ID:Oy3Li4u+(1)調 AAS
ﾐｭ

789(1): 04/04/03 22:51 ID:KweurONI(1)調 AAS
>>785
ｳｫﾝ
冗談じゃなくウォンだとホントっぽくなるウォン計算だと年収400万円くらいになるんだよね
金持ちって自分で言ってもなかなか買い換えないとか見てるとちょーどそのくらいになるんだよねぇ

790: 04/04/03 22:53 ID:EykEskuG(1)調 AAS
>>789
漏れは年収150万円の貧乏フリーターでつが何か？

791: 04/04/03 22:53 ID:6Ucrd7W6(2/2)調 AAS
日本語も不自由だしね、彼

792(1): T.A. 04/04/03 23:34 ID:UhLW37aU(2/2)調 AAS
>>773
>まぁ、どっちにしてもIA-32eになったからと言って容量が倍要るなんて
>戯言を言い出すのはT.A君だけだろうね。
まあ、戯言なのは今更言われるまでもなく自分自身よく判ってるからね。
何しろ真相はIntel(それも設計陣のトップレベルの連中)しか知らないんだから
どれほど真実味があっても、所詮、推測に過ぎないし。

ただ、夕べからのやり取りは「議論」のやり方としてはいい勉強になっただろう？

議論の結末には3種類あるんだが、

1)発散：複数の意見が単に衝突を繰り返すのみで、問題解決に至る結論が出ない状態。
　議論の結末としては最悪。更に最悪の場合は問題自体が摩り替わってしまい、本来の
　問題以外に別の問題を派生させてしまう。
2)妥協：複数の意見の利害関係の中間点を結論とすることで、取り敢えず問題解決を
　優先する。これでも充分に問題が解決する場合もあるが、多くの場合は根本的解決
　にはならず、後々に最終的な解決を必要とする。
3)昇華：複数の意見を元に短所を改め、長所をより高めた意見を作り上げる。
　議論の結末としては最も理想的。

録音先生が議論に参加した場合、必ず1)の結末に向かっているんだよねぇ・・・
(参加しなかった場合については、夕べからのμOP関連の議論を見れば判るだろうから
改めて書く必要はないよな？)

ちなみに、あくまで「議論の方法」についての話なので、出てきた「結論」について
は考えてないからね。

793: 録音名語録上げ 04/04/03 23:39 ID:skQ3n0jX(6/6)調 AAS
744 ：Socket774 ：04/04/03 07:42 ID:FkN9EIqi
>>741
オペランドにメモリを指定している場合はどうなるんだ？
64bitモードの場合、64bitのアドレス値が必要になるんじゃないか？

764 ： ◆Rb.XJ8VXow ：04/04/03 12:03 ID:j1o0NWBg
>>744
uOPに変換が基本ですぜ。
64bit即値オペランドは3つに分解すればそれでＯＫ

794: 04/04/03 23:42 ID:GVUsakLo(1)調 AAS
なんかやけにスレ進んでると思ったら…
やっぱり予想通りでしたか…

795: ◆Rb.XJ8VXow 04/04/03 23:54 ID:j1o0NWBg(6/7)調 AAS
>>792
非常に残念だが結論が分かりきってるものを議論する必要は無い。
単に戯言を否定するだけで良いのだよ♪

796: 04/04/03 23:58 ID:uoY5eKAP(1)調 AAS
議論の結末とか、詭弁とか、そんなの気にしてるのは
録音に良い様に弄ばれてる厨だけだろ。
いい加減相手にするのは止めにしてみてはどうか。
奴を論破することによって、自らの精神の平安を得ていると言うのなら
俺が言い過ぎた、ごめんね。
月曜にでも医者に行け。

797: ◆Rb.XJ8VXow 04/04/03 23:59 ID:j1o0NWBg(7/7)調 AAS
ついでに言っとくが「真実味」はこれっぽっちも無いぞ。
ってか、「寝ぼけるなボケ！」としか言い様が無い。

上下前次 1-新書関写板覧索設栞歴

ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ

ぬこの手ぬこTOP 0.257s*