インテルの衰退とAMDの繁栄 Part10

(´-｀).o0()

使ってるやつは病人

>>949
そうだが、上位QWORDの扱いの問題上、ロード・ストアはXMMに読むよりMMに読むほうが速いはず。
現に、XMMレジスタと完全に用途のかぶる単精度や整数だとMMX/3D NOW!のが速いわけだから。

>倍精度実数に限っては、Pen4以外でもSSE2を使ったほうが速いこともあるってこと。
>なぜなら、SSE2を使わずにx87を使わないといけないから。

この部分、言ってることがわかんない・・・。

訂正

SSE2を使わずに済ませたいなら、x87を使わないといけないから。

(´-｀).o0(とりあえずMOVDQUがLDDQUより遅い事を理解した。

K8の実装なら上位64bitは関係ないと思うけど

いやAthlon64ではどっちも同じだよ
Pen4上でも、キャッシュラインを跨がない限りはmovdquを使ったほうが速いケースのほうが多い。

イソテルがゴミにしか見えなかったＩＢＭ様ですら独禁法には敵わなかったわけだが
雑音にはそういう認識が認められないらしいなｗｗｗ

まあパソコンしか弄ったことのない小僧には昔のＩＢＭのブランドイメージと今の
ブランドイメージの落差は分からないのは無理ないのだろうがｗｗｗ

でも、こう言うときこそ得意の妄想いや想像力を炸裂させればよい物をｗｗｗ

>>958
>動画圧縮においては、メモリ上には参照されるフレームのデータが収まっており、それは書き換えられることはないため、MOVDQUが有利なケースは考えにくいが、用途によってはMOVDQUのような動作が必要な局面があるため、残したものと思われる。
(´-｀).o0(だそうだが？

>>960
Pen4のlddquの実装では、128ビットデータを２個読んできてシフトして重ね合わせるのよ
movdquは64ビットずつ×２
256bitも連続した領域を読み込むと、依存関係の解消の問題で最適化の弊害になるんだ罠。
その記事間違いキャッシュラインを跨がない限りは普通にmovdqaのほうが平均的には速い。


Athlon64やその他では64ビット単位のロード・ストアを2つ束ねるだけだからどれも同じ。

×movdqaのほうが速い
○movdquのほうが速い

アラインメントされてないデータをmovdqaで読もうとすると例外発生な

だんだん助詞の省略が目立ってきたｗ

>>961
＞movdquのほうが速い
ttp://review.ascii24.com/akiba/column/latestparts/2004/03/01/images/images735647.gif
(´-｀).o0(じゃぁ、これは嘘か。

Athlonに最適化されてないプログラムではSSE2を使わないより使う方が速いんでしょ？
ならSSE2サポートしたのは意味があるじゃん。
SSE3も同じ事。

現実問題として3DNowよりSSE系が広まってる以上、AMDが「Athlonに最適化してくださいよー」と言っても無理な話。
Intelの方が影響力が大きいんだから。
ならSSE系をサポートしてちょっとでも性能上げるのが得策。

それはlddquだけを連続でまわしてるから、後処理が隠蔽されてるだけでしょ。
ロードして更にシフトして合成してるから実際にはその分遅い。
つまり、普通に演算の中で混ぜて使うならまったく話が別。

>>966
>従来のMOVDQU命令は、調べたところ、メモリアドレス末尾が0または8のときに限り19.7GB/秒、
>それ以外では7.5GB/秒にまで落ちてしまうことがわかった。
>現実には末尾が0のときにはMOVDQAを使うので、MOVDQUの使われる局面での平均速度は8.3GB/秒。
>MOVDQA利用時の6分の1ほどに落ちてしまう。3回に分けて読み出し、合成することのオーバーヘッドはこれほどまでに大きいのだ。

>一方、期待の新人LDDQUは、末尾アドレスにかかわらず19.7GB/秒をキープした。
>内部動作的に2回のMOVDQAを行なっているから、MOVDQAの半分、22GB/秒が予想される速度だが、
>ほぼそれに近い値になっている。平均速度で言えば、MOVDQUの3倍近い値だ。
>メモリアクセス速度がこれほど違えば、動き検出の速度に相当なインパクトを与えるであろうことは想像に難くない。
>TMPGEnc 3で13％といった速度向上が行なわれているのもこの結果から十分納得できる。

(´-｀).o0(さて明日は早いので寝る。

>>967
おつかれさまでした、ゆっくり休んでください。

だから、キャッシュラインを跨いでる場合も平均値に入れてるだろそれ
まあいいや。おやすみ。

>>912
>TMPGENCでSSE3を使って速くなったというのは、おそらくPen4優先にした最適化故の怪我の功名的なもので、
>最初からAthlon64優先でXMMレジスタベースで組んでたとして、lddquその他が高速化に寄与するとは考えにくい。

ここがどうしてもわからん。
Athlonでは、SSE3を使用した「P4向け最適化」が偶々（3Dnowより）速くなったが
「Athlon64向け最適化」だと（3Dnow）より早くなるとは限らない
と読めるんだが？

SSE3（P4最適化）＞SSE3（Atnlon64最適化）≧3Dnow

いやぁ素晴らしい理論だｗ

>>970
言ってもないことまで無理矢理脳内解釈で継ぎ足してもお前の理論であって俺の理論じゃないな。

３DNOW!向けのコードがちゃんと保守されてるかどうかもわからないし
何度も補足してるが倍精度使うならいまのところ実質SSE2/3しか選択肢は無い。

WinDVD3だったと思うけど「Crusoeにも最適化！」って言ってたのが、
次のバージョンではなくなってたのを思い出した。

>>971
じゃあ貴方様の脳内の単語を書き出してもらえませんこと？
>高速化に寄与するとは考えにくい。
というのは比較する条件が有ってからこそですよね？
3Dnowではないというならそれに置き換わる物は何でしょうか？

>倍精度使うならいまのところ実質SSE2/3しか選択肢は無い。
なら、SSE3実装の意味はあるってことですよね？
もっといい実装があったはずなのにSSEを実装するAMDは馬鹿だっていう話でしたっけ？
なら>>377の
>互換性と拡張性、それがSSEを使う理由だ。
でいいんじゃないですか？

立てられる方、どなたか次スレよろしくお願いします。


インテルの衰退とAMDの繁栄 Part11



インテルのスミスフィールドは消費電力が高過ぎ、性能も低く、
AMD社のデュアルコアは、消費電力もインテルのシングルコアのプレスコット未満となっており
インテル社のCPUはもう使い物にならない時代が到来しております。
私自身はメーカー名にかかわらず良い物を買う派だったのですが、
もうインテル製品は買えないほど、インテルは堕落してしまいました。
64は不安定と言う人もなかにはいますが、それはユーザー数の低さからか、
ソフトウエアの動作検証がされにくいために過ぎないようで、
現状の64環境でも、ユーザーが増えれば今よりもさらに動作検証例が増えることになります。
PenMもはっきりいってまだまだ熟成されておりません。


インテルさようなら

前スレ

インテルの衰退とAMDの繁栄 Part10
http://pc7.2ch.net/test/read.cgi/jisaku/1121441747/

過去スレ

インテルの衰退とAMDの繁栄 Part.1
http://pc7.2ch.net/test/read.cgi/jisaku/1114082746/

インテルの衰退とAMDの繁栄 Part.2
http://pc7.2ch.net/test/read.cgi/jisaku/1114173763/

インテルの衰退とAMDの繁栄 Part.3
http://pc7.2ch.net/test/read.cgi/jisaku/1114868333/

インテルの衰退とAMDの繁栄 Part4
http://pc7.2ch.net/test/read.cgi/jisaku/1115817862/

インテルの衰退とAMDの繁栄 Part5
http://pc7.2ch.net/test/read.cgi/jisaku/1116758399/

インテルの衰退とAMDの繁栄 Part6
http://pc7.2ch.net/test/read.cgi/jisaku/1117887926/

インテルの衰退とAMDの繁栄 PART8
http://pc7.2ch.net/test/read.cgi/jisaku/1119549117/

インテルの衰退とAMDの繁栄 Part9
http://pc7.2ch.net/test/read.cgi/jisaku/1120364183/




炭【すみ】［名］(自作PC・パソコン一般)
http://www.media-k.co.jp/jiten/wiki.cgi?%A1%DA%BF%B7%C3%E5%CD%D1%B8%EC%A1%DB#i0

>>912
>3D NOWでは倍精度浮動小数はx87命令を使う必要があるため、これならSSE2の倍精度×１or２を

AMD64で使わないものの話をしてどうする。

まあ、ずううううううっと32bitで停止しとけ

次スレ立てました。

インテルの衰退とAMDの繁栄 Part11
http://pc7.2ch.net/test/read.cgi/jisaku/1122226119/

>>803
裏切り者orz
半分分けてくれ・・・

MMXもSSEも3DNowもどうせたいして普及してないんだから
どうでもいいやと思った。

今日は503君まだきてないなぁ〜。
反論できなくなってばっくれてしまったかな？

>>976
乙。

>>979
続きは専用スレでどうぞ。

【動機は？】雑音犬畜生Part32【六千円が高級ｹｰｽ】
http://tmp5.2ch.net/test/read.cgi/tubo/1121710534/

>>947
それ当たってるかもな。

俺は1行目かな。
最初は妙に録音が説得力のあるウソをつくんでだまされるヤツがいるんじゃないかと許せなくなって
実態を暴いてやろうっていうのが動機だったけど、最近はそれが無くなったから必要なくなったんだが
おもしろいってだけでやってるもんな。

言ってもないことまで無理矢理脳内解釈で継ぎ足してもお前の理論であって俺の理論じゃないな♪
￣￣￣￣￣￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　 　　　　　In＿�� 　　　　　
　　　 　　　 ⊂（＠ε＠-）つ　
　　　　　 ／／（雑音/_/::::| 　　
　　　　　 |:::|/⊂ヽ ノ|:::| ／」　　
　　　 ／￣￣旦￣￣￣／|　　
　　／＿＿＿＿＿＿／ .| |　　
　　| |-----------| | 　　　　

>>967
>従来のMOVDQU命令は、調べたところ、メモリアドレス末尾が0または8のときに限り19.7GB/秒、

末尾の4bitが0の時だけはえぇってどんな実装しとるんじゃ？
わけわかめ

メモリ境界をまたぐときに、手前に足がつくように足幅を狭めて歩く。

>>984
アドレス末尾3ビットが0だから64ビット単位でアクセスしているだけだろ

>>986
ああ、3bitの間違いだった。

で、そこで64bit単位ってのがわからん。
使ったことの無いものはさっぱりわからんね。

アドレスの単位

>>987
メモリからデータをもらう時は、40bitのうち上位37bitを与える。
そうすれば64bitのデータバスに乗ってデータが返って来る。

物理アドレス　　　データ(64bit)
---------------------------------------------
00000000　　　　01 23 45 67 89 ab cd ef
00000008　　　　aa aa 55 55 aa aa 55 55
00000010　　　　00 00 00 00 00 00 00 00
00000018　　　　ff ff ff ff ff ff ff ff

00000000〜00000007 の8Byteが欲しい時は、2アクセスで済むけど、
00000006〜0000000e の8Byteが欲しい時は、3アクセスかかってしまう。

別にわけわかめな実装ではない。素直に作ると通常こうなってしまうわけで。

>>989
ありがとうありがとう

わかりやすい例までだしてくれてThx!

てっきり指定アドレスを先頭に64bitかと思ってたからわけわかめだったけど、
物理アドレスに対して固定した先頭アドレスから64bit拾ってくる仕様だったのねぇ。
あららぁって感じ。

(´-｀).o0(とりあえず2号君に詳しい解説を頼もう
(´-｀).o0(P4はTMPGEncのSSE3対応による速度向上はlddquらしいけど
(´-｀).o0(Athlon64のTMPGEncのSSE3対応による速度向上は何が原因なんだ？
(´-｀).o0(2号君のいう事を信用するとmovdquがlddquと同じ速度らしいし
(´-｀).o0(ならSSE3のほかの命令セットのお陰でTMPGEncが速くなったことになるからな。

最近はパディングをムシするプログラミングが流行りなんですか？
そんなことするの8bit時代の化石だけかとおもってた。

そして千

なんにしてもプレスコのような病人的発熱する石じゃぁ使えんよな。
終了。。

>>993
いや、そりゃ逆でそういう仕様になったから、考慮するようになったんじゃないの？

パディングを無視すると遅くなるなんて15年以上前からのお約束ごとでさ、
x86でいつまでもそんなのが許されてるのは、かけられてからそろそろ
30年は経とうかという8086/8088の呪いが今でも効いてるからにすぎないでしょ？

先祖帰りしてる猿プログラマの都合で良くここまでスレが伸びるなぁ、とちょっと関心。

そーゆー連中の書いたコードみると構造体とかパディングいれないで
メモリアライメントぐだぐだで、「おせぇおせぇ！」とか叫んでたり
するのかなぁ…。

1000

てわけでまぁ、埋まる前の独り言。

1台のマシンが組み上がりました。。。
新しい筐体を用意してくださいです。。。。

　　　　　　　　　自作PC板＠2ch http://pc7.2ch.net/jisaku/