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

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

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

1 :デフォルトの名無しさん:2011/04/09(土) 16:43:11.05
ゆるゆる〜っと実測していきましょう。

過去ログ
x86命令の所要クロック計測スレPart4
http://hibari.2ch.net/test/read.cgi/tech/1212157132/
x86命令の所要クロック計測スレPart3
http://pc11.2ch.net/test/read.cgi/tech/1168399966/
x86命令の所要クロック計測スレPart2
http://pc10.2ch.net/test/read.cgi/tech/1136527588/l50
x86命令の所要クロック計測スレ
http://pc8.2ch.net/test/read.cgi/tech/1103609337/l50

関連スレ
アセンブラ… (゜□゜) ↑アッー!↓
http://pc10.2ch.net/test/read.cgi/tech/1148402614/l50
MMX SSE 3D NOW!のプログラミング
http://pc10.2ch.net/test/read.cgi/tech/1085749218/l50
CPUアーキテクチャについて語れ 5
http://pc9.2ch.net/test/read.cgi/jisaku/1159238563/l50
【Penryn】次世代モバイルCPU雑談スレ 3【Nehalem】
http://pc9.2ch.net/test/read.cgi/notepc/1160039483/l50
もしくは、自作板にて「次世代」でスレタイ検索

まとめサイト(過去ログ置き場)
http://www.wikihouse.com/x86clocker/index.php?FrontPage

2 :デフォルトの名無しさん:2011/04/09(土) 16:44:16.50
関連サイト(日本語)
コピペで動くVC++のインラインアセンブラ例
http://www.fides.dti.ne.jp/~tokai/vc/mmxab2.html
基本的な整数命令/スタックの使い方
http://ray.sakura.ne.jp/asm/
FPUやMMX,SSEの命令解説など。最適化の色々な話がある
http://homepage1.nifty.com/herumi/adv.html
pentopt(古)の日本語訳など
http://hp.vector.co.jp/authors/VA003988/
Intelの日本語技術資料のダウンロード
http://www.intel.com/jp/developer/download/index.htm

関連サイト(英語)
Intelの最適化マニュアル(Core2についても載ってる)
http://developer.intel.com/products/processor/manuals/index.htm
Software Optimization Guide for AMD64 Processors
http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739_7203,00.html
Intel向け最適化手法やクロックテーブル、testp.zipで手軽にrdpmcが使える
http://www.agner.org/optimize/
各CPUのレイテンシ-スループットの表(K7K8あり)
http://swox.com/doc/x86-timing.pdf
x86CPUの各種データシート
http://www.sandpile.org/
AMD CodeAnalyst Performance Analyzer、AMD用パイプラインの様子がわかるシミュレータ
http://developer.amd.com/downloads.jsp

CPU関係の記事が読めるかもしれない場所
http://pc.watch.impress.co.jp/
http://www.geocities.jp/andosprocinfo/
http://mypage.odn.ne.jp/www/k/8/k8_hammer_trans/files/Hammer-Info.html

3 :デフォルトの名無しさん:2011/04/09(土) 17:01:22.55
>>1


4 :デフォルトの名無しさん:2011/04/09(土) 19:28:25.78
前スレ>>4から拾ってきた
>テンプレに入れて欲しい
>http://instlatx64.fw.hu/

5 :,,・´∀`・,,)っ-○○○:2011/04/11(月) 22:10:11.30
Bulldozerのマニュアル読んでて面白かったので久々にチラ裏日記を更新した。
そろそろあのサイトの移転先考えないと。

JohnのMLにコミットしておくか

6 :デフォルトの名無しさん:2011/04/12(火) 02:42:01.93
>>5
>おそらく6コアあるPhenom IIのほうがマシである。
暇ができたらちょっと検証してみてよ。


7 :デフォルトの名無しさん:2011/04/12(火) 08:02:38.41
Intel vs AMDってPen4 vs AthlonXPの時を除いてそれより前からもそれより後も
Intelはピーク性能、AMDは安くてそこそこの性能って感じじゃね?

AMDはベンチマークには現れにくいが足回りが良くてワーストケースに強かったイメージがある。
サーバー向き。

もっとも、最近はその足回りもIntelに抜かれた感がある。
抜かれようが抜かれまいが、AMDの性格上DESやらエンコやらパイ焼きみたいな数値演算メインの処理で比較したらIntelに有利だと思う。

8 :デフォルトの名無しさん:2011/04/12(火) 08:57:23.85
>>7
NetBurst vs K7
においても、
> Intelはピーク性能、AMDは安くてそこそこの性能
だったと思うが

K7って爆熱&お馬鹿プリフェッチ&高レイテンシFSBで、
足回りが悪かったよ。

キャッシュがヒットしない領域に入った途端に、
Pentium3にも突き放される低速っぷり。

9 :デフォルトの名無しさん:2011/04/12(火) 12:40:32.85
>>8
> Pen4 vs AthlonXPの時を除いて
って書いてるのに。
バカなの?

10 :デフォルトの名無しさん:2011/04/12(火) 13:07:20.54
>>9
日本語わからないの?

11 :デフォルトの名無しさん:2011/04/12(火) 13:13:27.73
>>10
レス番間違えてるよ。

12 :デフォルトの名無しさん:2011/04/12(火) 13:28:05.14
>>11
いやいや合ってますってば。

13 :デフォルトの名無しさん:2011/04/12(火) 13:31:44.96
だめだこりゃ

14 :デフォルトの名無しさん:2011/04/12(火) 13:34:40.12
>>13
おまえがな

相手が間違っているという前提で読むから誤読するんじゃね?
落ち付いて>>7>>8を読んでみ?

15 :デフォルトの名無しさん:2011/04/12(火) 13:53:51.56
お互いに誤読して勝手に盛り上がっているに一票。

16 :デフォルトの名無しさん:2011/04/12(火) 17:40:11.76
だめだこりゃ

17 :デフォルトの名無しさん:2011/04/12(火) 18:46:26.13
>>7
>イメージがある
>有利だと思う
ここは計測スレだデータを示せ

18 :デフォルトの名無しさん:2011/04/12(火) 20:55:19.22
だめだこりゃ

19 :デフォルトの名無しさん:2011/04/12(火) 22:47:48.81
間違いを認められずに煽りあいとか恥ずかしくないのか?
少しは紳士的な団子さんを見習えよ。

20 :デフォルトの名無しさん:2011/04/12(火) 23:39:16.69
athlonXPはK7世代だよな
そもそもK7,K8はDECのalphaの系譜なのだから
安くてそこそこの性能なんて言われちゃおしまいだろ

21 :デフォルトの名無しさん:2011/04/12(火) 23:43:52.33
でも実際、安くてそこそこでオタクに受けてたじゃん

22 :デフォルトの名無しさん:2011/04/13(水) 05:33:35.85
>>20
そりゃそうだが、アーキテクチャをx86にした時点で別の視点で見られてしまうからな
「いかに速いx86か」でしかなくなってしまう

23 :デフォルトの名無しさん:2011/04/13(水) 09:28:54.86
なつかしいなintel vs AMDのFSB論争

2chなんかでは、マルチプロセッサ構成で使ってもいない連中がPoint-to-Point接続の優位性を語ってて、おかしかった

24 :,,・´∀`・,,)っ-○○○:2011/04/14(木) 04:15:22.93
ちなみに、机上シミュレーションだとSHA-1/SHA-256のSIMD並列化コードでは
Bulldozerは同モジュールあたりでSandy Bridgeよりも良い数字が出てる。
もちろんXOPを使った場合ね。AVXだと同等以下に落ちる。

整数演算メインの処理で、SIMDクラスタのPort0は乗算が使えないところでは
使い道ないとは最初思ったんだけど、vpmacc* の第2引数に1とか-1を指定してみ?
レイテンシは大きいものの加減算に使えるんだよね。

整数は従来SSEやAVXの範疇ではIntelには負けるがXOPさえ使えば同等かそれ以上(ものによる)
の性能を引き出せる余地はある。
(更に欲をいうならPort 0にPort2,3と同じSIMD ALUをおいてくれさえすればSSE/AVXでも良い数字出るはず)

一方FPは完全にSandy Bridgeのほうが飴が美味しいですわ。
AMDは従来128ビットSIMDコアの実効1.4倍くらいの性能を目指してきたと思う。
FMACの片方とシャッフルユニットが同じポートだったり、そもそも制約が多い。
128ビットSIMDのまま性能を伸ばそうとしたからどうしても伸び白が小さくなってしまう。
Sandy Bridgeは256ビット化することで実効1.8倍(Intel曰く)を目指してきた。
FADD/FMULだけでなくシャッフルユニットも含めてフル256ビット化してきたことで
性能が出やすくなってる印象。

25 :デフォルトの名無しさん:2011/04/14(木) 04:35:35.14
まあいいんじゃね

AMDは価格相当の性能を出しているのだと思えば、Intel並みの性能が欲しければ
ハイエンドのCPUを買ってもIntelより安いのだし、「安かろう悪かろう」という市場原理
そのままのような希ガス。

逆にAMDが安価でIntelを突拍子も無く抜くような物を作るとAMDが独禁法の敵に
されるような気がする。

IntelはCoreアーキテクチャ以降もっさりのくびきから逃れる事が出来たし、AMDは頑なに
K5以降の路線を守り続けているが、目指す方向がほとんど同じに最近は思えてきた。

26 :デフォルトの名無しさん:2011/04/14(木) 05:23:25.03
k5以降の路線ってなんだよ
買収で開発を取り込んでるだけのAMDに

27 :デフォルトの名無しさん:2011/04/14(木) 07:47:19.01
しかしAMDの存在がありがたいだろ
もしAMDがなかったらもっとCPUの値段が馬鹿高いぞ

28 :デフォルトの名無しさん:2011/04/14(木) 10:12:38.73
そして64ビットはIA-64だっただろう・・・

>>24
そのコードを全コアで一斉に走らせた場合、
Bulldozerは実行ユニットを2コアで共有している分、
Sandy Bridgeよりも遅くならないか?

かつてリソースを占有できるという前提で書かれたコードが、
Pentium4のHyperThreadingで悲惨なことになったように、
あまりタイトすぎると・・・。

29 :,,・´∀`・,,)っ-○○○:2011/04/14(木) 12:15:12.08
Pentium4でHTを使うとトータルスループットが落ちる原因ってL1キャッシュミスでそ。
8KBとか16KBの小さいキャッシュを更に共有するとか、おかしいこと山の如し。

BulldozerはL1独立なのでL1容量がネックになるコードは性能が落ちるというより
最初から遅いと思う。1スレッドだけ走らせたからってL1Dが32KBとしてして使えるわけじゃ無しに
最初から16KB固定割り当てだしね。

ただし、2コア同時にキャッシュミス or prefetchしたらL2の帯域大丈夫かしら?ってのはある。
HPC版と銘打ったNehalem-EXの6コア・2.66GHz版は最初からHTは無効にしてある。
一方BulldozerのSIMD命令はレイテンシが大きすぎるので2スレッド使わないと埋まらない気がする。

30 :デフォルトの名無しさん:2011/04/14(木) 12:40:15.04
なるほど

31 :デフォルトの名無しさん:2011/04/15(金) 02:21:42.30
そだなあAMDは伝統的にL1が大きいからね
レイテンシも大きい事が多いけど
K8でメモリの足回りが良くなってから本当に速くなった

32 :デフォルトの名無しさん:2011/04/15(金) 10:23:32.33
K7のメモリが遅すぎた。いくらなんでもレイテンシ200nsは遅すぎだった。
そりゃIntelが、帯域幅を犠牲にしてでも共有FSBで100nsのほうが速いよ、って言うわけだ。

33 :デフォルトの名無しさん:2011/04/15(金) 17:50:04.78
nForce4というなんちゃってデュアルチャンネルノースブリッジチップだったら
100ns程度だったんだけどな

まあK7をフォトレタッチソフトのような大部分がメモリとのやり取りにCPU
タイムを費やすような用途に使う事はもうないでしょう

Phenom][やAthlonX2が出てるんですから

34 :デフォルトの名無しさん:2011/04/15(金) 17:51:57.11
悪いnForce2だった
古い物で記憶もあやふやになっとる
IntelもCode i7でトリプルチャンネルなんてやっちゃってるし
余程メモリが速度の足を引っ張るのが怖いんだろうな

35 :,,・´∀`・,,)っ-○○○:2011/04/15(金) 18:35:23.50
LGA1366は最大6コアをサポートするプラットフォームだからチャネル数増やすのは当たり前では?
もともとサーバ向けだし。ハイエンドデスクトップ向けでマスク共用して実質的なコストダウンしてるだけの話で
デスクトップ向けに3ch必要なわけではない。

実際4コアだと2chも3chも大して実効性能変わらんでしょ。
2chで6コアの製品はAMDしかないから知らんが。

36 :デフォルトの名無しさん:2011/04/15(金) 18:40:07.91
>>33
それはシングルCPUの話だよね。

デュアルCPUだと、
CPU(0)→ノースブリッジ→CPU(1)→ノースブリッジ→メモリ→ノースブリッジ→CPU(0)
ってな感じで、200nsもかかったらしい。

>>34
いや実際、メモリがボトルネックになるでしょ。

複数のコアのメモリアクセスがキューに並べば、レイテンシが悪化する。
だから、複数のメモリコントローラにアクセスが分散させてレイテンシの悪化を軽減しようとしてる。

K7時代のデュアルチャネルは、アドレスは1系統でデータが2倍というタイプ、
つまり、2つのDIMMを束ねて128bit幅のDIMMとして使うような方式だったが、
今のデュアルチャネル・トリプルチャネルは、アドレスが2系統・3系統あるのよね。

37 :デフォルトの名無しさん:2011/04/15(金) 20:20:21.95
>>36
あ、デュアルCPUの話でしたか
当時はマルチコアなんか無かったからすっかりわすれていました
SMPをすっかり忘れていました
そういえばAthlonXPをMP相当に改造してSMPで動くようにするとか
実験工作が流行ったような記憶が・・・

K7のデータバスは1本しかありませんから、nForce2のなんちゃって
デュアルチャンネルはノースブリッジに2本のメモリバスがあり、それを
ノースブリッジ内で合成して1本にして出力する物で、メモリインター
リープの考え方の延長上にありました

だから性能的には大して上がらず、単に売れ線を意識しただけの
ような格好だったと思います

いまのデュアルチャンネルはメモリを実質的に128bitや196bitとみなせ
ますから、実数演算やSIMD命令で相当性能が上がっていますね

38 :デフォルトの名無しさん:2011/04/15(金) 20:49:26.38
nForceのデュアルチャネルは、CPUのためというよりは、メインメモリ共有の内蔵GPUのためだったね。

K7はデュアルだとFSB266まで、しかもレイテンシ大で、CPUが1GHzの頃はよかったが、
2GHzにもなると、ボトルネックになった。まぁその頃はOpteronへの移行が始まってたが。

EV6は、せっかくPoint-to-Point接続で、共有FSBのクロックが上げられない制限がないのに、
FSB333や400に対応したチップセットが投入されないという、もったいないことになってたね。

39 :デフォルトの名無しさん:2011/04/16(土) 14:31:35.97
>>35
Windows VistaのDWM1.0ではGDIが全てCPU上で処理されてからDirectXでGPUに転送、だったせいで
メインメモリ帯域がPCの使用感に与える影響は半端じゃなかった。メモリが遅いともたもたスクロールになる。
DWM1.1になってそこまでの影響はなくなったな。

40 :デフォルトの名無しさん:2011/04/16(土) 14:50:47.44
>>39
2Dアクセラレーションを切った今時のGPUでエディタでマクロを使った時の
もたつき感はそのせいか

でもBitBltだけは残してあるんだよね?

41 :デフォルトの名無しさん:2011/04/16(土) 22:18:56.82
そんなに食うわけ無いだろ
だったらIGPなんてどうなんだって話だわ

42 :デフォルトの名無しさん:2011/04/17(日) 09:03:18.37
WindowsのGDI処理の速度は、ビデオメモリの帯域幅に大きく依存してる。
同じビデオチップを同じクロックで動かしても、ビデオメモリが違うと、かなり違う。

GeForce4MXクラスでも、
SDR 166MTs 64bit幅
DDR 400MTs 128bit幅
では、雲泥の差だった。

43 :デフォルトの名無しさん:2011/04/17(日) 12:59:01.94
だから、もともと帯域食い合ってるIGPだったら
違いがでない理屈だろ上のは

それとWDDMだよな書きたいのは

44 :デフォルトの名無しさん:2011/04/17(日) 13:55:29.25
> そんなに食うわけない

食うだろう

> IGPなんてどうなんだ

IGPだと、メインメモリをビデオメモリとして使うので、
GDIがソフトウェア処理でもハードウェア処理でも、
同じじゃないか? ということなら、Yesだ。

IGPはパフォーマンスが悪かった。

45 :デフォルトの名無しさん:2011/04/17(日) 15:17:41.05
IGPだと本当に悲惨なことになる

まずCPUがGDIエミュレーションルーチンを走らせてメインメモリ上のサーフェースにお絵描きする
それをテクスチャに変換してVRAM (IGPだとこれもメインメモリ) にメモリtoメモリのコピーをする
そしてIGPはD3Dでテクスチャを読んでフレームバッファ (IGPだとこれもry) にレンダリングする
そしてビデオ出力部がフレームバッファを読んで出力する

つまり、メインメモリ上で「書いて読んで書いて読んで書いて読む」ことになる
ちなみにXP以前のドライバモデルなら、「書いて読む」だけだ

46 :デフォルトの名無しさん:2011/04/17(日) 15:18:41.12
あ、フレームバッファは外付けのもあるな
そんなわけで少なければ2倍、多ければ3倍になるわけだ

47 :デフォルトの名無しさん:2011/04/17(日) 18:50:15.68
VistaでG45のほうが790GXより快適なのは何で?

48 :デフォルトの名無しさん:2011/04/17(日) 19:22:59.83
>>45に加えて、
XPでも、GDI処理がGPUで非同期実行されるからCPU時間で見ればあまり差がないように見えていただけで、IGPは遅かった。
bitbltのすぐ後にさらにGDIのapiを呼び出せば、その相応の時間待たされることで隠蔽されていた処理時間が見えるようになる。

49 :デフォルトの名無しさん:2011/04/17(日) 21:09:43.84
>>47
Radeonは描画がトロいよ。

50 :,,・´∀`・,,)っ-○○○:2011/04/17(日) 21:19:56.59
現行Radeonは2D機能はエミュレーションだからな。ドライバタイム無駄に長いし。


51 :デフォルトの名無しさん:2011/04/18(月) 14:26:59.69
CPUによるエミュレーションの最大の問題点は、
・メモリのフィルが無駄に遅い(リードモディファイライトするから???)
・エミュレーションするときにCPUのキャッシュの内容が一掃される
だと思うわ。


52 :デフォルトの名無しさん:2011/04/18(月) 15:02:55.49
2Dアクセラレーション復活しろカスと言いたいよな
大してダイ面積食ってるわけでもなかろうに

53 :デフォルトの名無しさん:2011/04/18(月) 18:39:49.51
ウィンドウの重なり処理を3Dでやれば、都度の再描画がなくなるし、今のCPUは速いので、アクセラレーション必要ない
っていうのがマイクロソフトの判断だったのだろう。

でも実際には再描画が遅いのではなく、初回描画が遅かったのだ。


54 :デフォルトの名無しさん:2011/04/18(月) 18:56:00.20
更なるベクターグラフィックのアクセラレーションとかに期待してみたい
今後OSレベルで多用する事になるだろうし

55 :デフォルトの名無しさん:2011/04/18(月) 19:28:31.39
54のベクタグラフィックは置いといて、現状の2Dはメモリの転送だけだろ。
アルファブレンドとかメモリの転送速度に比べたら誤差みたいな計算量だし。
アクセラレートのしようがないと思う。

Vistaが遅いのは本当に描画アーキテクチャが原因なのか?
スーパーフェッチとかそういうところじゃね?

56 :デフォルトの名無しさん:2011/04/18(月) 21:45:59.54
>>55
D3Dの描画はともかくGDIは遅いよ。
Core(TM)2 Duo CPU E8500 @ 3.16GHz(3.16GHz x 2)Radeon X1950 Pro/OS XPSP3
1920x1080 32bpp 120Hz/1.26Gpixel(s)/sec/184.67FPS
Core(TM) i7-2600K CPU @ 3.40GHz (3.41GHz x 8)HD Graphics Family/OS XPSP3
1920x1080 32bpp 60Hz/453.73Mpixel(s)/sec/64.21FPS

Win7でも2600で456.42Mpixel(s)/sec/77.04FPS程度

D3D描画だとGTX460やHD5800辺りなら問題ないけどね。

57 :デフォルトの名無しさん:2011/04/18(月) 22:45:31.93
何の数値?

58 :デフォルトの名無しさん:2011/04/18(月) 23:34:13.94
エロゲベンtなのは確定的に明らか

59 :デフォルトの名無しさん:2011/04/19(火) 03:40:32.20
>>53
まあそういうこったね
あと、遅いっていうのはスループットだけじゃなくてレイテンシでも遅い
つまり>>45の各段にはバッファが入っていてパイプライン的に処理されていくので
アプリがクライアント領域に描画してからデバイスに出力されるまでは3フレームタイミング遅れる
この分だけでも、「再描画がD3Dだけでできる」というメリットは帳消しだと思うね

60 :,,・´∀`・,,)っ-○○○:2011/04/19(火) 03:46:08.08
MacOSの真似やりたかったんだねゲイツは。
CocoaのGUI部品ってWindowsのそれと比べてオーナードロー/カスタムドローの
自由度低いから嫌いなんだが、描画方法が変わっちゃうと良し悪しなんだよなぁ


61 :デフォルトの名無しさん:2011/04/19(火) 14:01:00.61
>>59
フレームの遅延、1フレーム単位でも、人間に知覚できるんだよね。

キーボードからテキストを入力するときの応答が速いときと遅いときがあって、
最初はCPU負荷かと思ったら、そうでもなくて、突き詰めていったら液晶モニタだった。

入力信号と画面から出る光をフォトトランジスタで受けた信号のタイミングを調べたら、
モニタの電源を入れるタイミング等々によって、
入力信号からパネル表示までの遅延時間に、約1フレーム分のバラツキがあった。
おそらくFRC(フレーム・レート・コンバータ)によって入力信号とパネル表示が非同期で行われてるかだろう。

62 :デフォルトの名無しさん:2011/04/28(木) 21:37:10.99
第一世代「AMD Fusion」プロセッサを試す - Zacate搭載Mini-ITXで徹底検証
http://journal.mycom.co.jp/special/2011/zacate/menu.html

大原節

63 :デフォルトの名無しさん:2011/05/11(水) 09:24:45.13
32bit
32bit + PAE
64bit

下にいくほどページテーブルが肥大化していくよね。
メモリアクセスのオーバーヘッドは、どれくらい違うの?


64 :デフォルトの名無しさん:2011/05/11(水) 11:44:43.47
もひとつ

なぜx86はSMTやってるのに、強力なフェッチ・デコードなの?
フェッチ・デコードは1クロックで処理する命令数が増えると指数関数的にデカく、電気食いになるよね。

1つのフェッチ・デコードで2スレッドを交互に処理するのではなく、
2つのフェッチ・デコードで各スレッド専用で処理したほうが、
シングルスレッドのパフォーマンスは低下するけれども、
消費電力が下げられるのでは?

65 :,,・´∀`・,,)っ-○○○:2011/05/11(水) 11:54:37.30
スレッド毎にフロントエンド分けるなら2コアにしたほうがマシだな


66 :デフォルトの名無しさん:2011/05/11(水) 12:30:19.50
>>60
AppleはiPadは失敗したけどAndroidは大成功だしなあ
Open OSだからすぐに中華でパクりそうだけど

67 :デフォルトの名無しさん:2011/05/11(水) 16:03:33.64
>>66
マテマテ
AndroidはAppleではなく絡んでるのはGoogleだぞ
今の所はiPhoneのシェアが高すぎてAndroidはどうなるか未知数だが
ニコニコ生放送を見ていても最近Androidの端末を使用している人が
増えていると感じる

68 :デフォルトの名無しさん:2011/05/12(木) 15:19:27.82
>>64
シングルスレッドの性能が限界に達しているので、メインストリームのプロセッサで性能を落とすわけにはいかないんでしょう。
並列化出来ない仕事だってあるからね。

69 :デフォルトの名無しさん:2011/05/12(木) 16:37:13.69
Pentium4のときに
Pentium3よりも遅くなる処理がある
って
散々叩かれたものね。

70 :デフォルトの名無しさん:2011/05/13(金) 23:37:02.71
http://support.amd.com/us/Processor_TechDocs/47414.pdf

B.5 Amended Latency for Selected FMA Instructions
によれば(FMA/IMAC)と(XBAR/MAL/STO)間のデータ移動で1サイクルの
ペナルティがあるようだ

IntelのCPUでも異なるドメイン間のデータ移動でペナルティが発生するが
各ドメインに演算ユニットが配置してあるので適切な命令を選択すれば
ペナルティを回避できる

71 : ◆0uxK91AxII :2011/05/26(木) 06:03:06.78
aeskeygenassistは全然assistっぽくない。

72 :天使 ◆uL5esZLBSE :2011/07/02(土) 16:25:52.13
> Open OSだからすぐに中華でパクりそうだけど
ハアアアァアアアァアァァァァァアァァアァアアアァァァアァァアアァァアァアァァアァア?????
うるさいゴミ


73 :天使 ◆uL5esZLBSE :2011/07/02(土) 19:18:13.81
これ ; デリミタっていうんだけどさ、よく打ち忘れるよね
Rubyだとつけなくてよくなるんだけど


ゴミだよなぁほんと

74 :デフォルトの名無しさん:2011/07/11(月) 01:19:18.18
ゴミすぎて最近はIDEが補完してくれるわけだが。

75 :デフォルトの名無しさん:2011/07/22(金) 14:01:37.28
>>75

http://www.friweb.hu/instlatx64/
確かにLlanoの整数除算は速くなってるね
FP除算は速くなってないようだけど

Intelの場合、整数とFPの除算器を共用しいているせいか、両方速くなったりするもんだけど、AMDは別個なんだね

76 :,,・´∀`・,,)っ-○○○:2011/09/04(日) 20:39:56.33
IntelのCPUの除算ユニットは、μOPs数考えるとFP乗算器としてデザインされてるものを
整数側が間借りしてるような感に見える。
整数DIVは商を求めてから非除数 - 商×除数で剰余を求めてるような。





77 :デフォルトの名無しさん:2011/09/09(金) 19:08:51.01
逆数求めて掛けているとかどうでしょう?

78 :,,・´∀`・,,)っ-○○○:2011/09/11(日) 20:58:20.03
Radix-16 SRTっていうハードウェア実装されたアルゴリズムを使っている。
4ビットずつ辞書引きをして引き算をするという操作を反復して商を求める。




79 :デフォルトの名無しさん:2011/10/08(土) 06:52:14.25
整数にするだけだったら小数点以下は反復しないだけでおkだしね
アルゴリズムにもっと良いものがあるかどうかは知らないが
intelがそうするのならそれなりの理由があるのだろう

80 :,,・´∀`・,,)っ-○○○:2011/10/08(土) 07:47:06.40
しょっちゅう使うもんでもないけど使うときには性能が欲しい。
ってことになると整数と実数で別々に持つよりは共通の強力なユニットを1つだけ
持つほうが合理的だわな。

81 :デフォルトの名無しさん:2011/10/20(木) 19:24:52.03
http://www.friweb.hu/instlatx64/

bullちゃんのレイテンシー&スループット

82 :デフォルトの名無しさん:2011/11/09(水) 22:30:07.36
Bullちゃんは複雑怪奇

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

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

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