バイト単位でコピーするアホなコードの方が、勝手にベクトル化される分、gcc 内蔵のヤツより最大３倍高速なんだってwww
手元の glibc memcpy() だとこんなコードですが、 そもそも SSE2 を使わない縛りとしても最速コードではなさげ。
008bb6d0 <memcpy>: 8bb6d0: 8b 4c 24 0c mov 0xc(%esp),%ecx 8bb6d4: 89 f8 mov %edi,%eax 8bb6d6: 8b 7c 24 04 mov 0x4(%esp),%edi 8bb6da: 89 f2 mov %esi,%edx 8bb6dc: 8b 74 24 08 mov 0x8(%esp),%esi 8bb6e0: fc cld 8bb6e1: d1 e9 shr %ecx 8bb6e3: 73 01 jae 8bb6e6 <memcpy+0x16> 8bb6e5: a4 movsb %ds:(%esi),%es:(%edi) 8bb6e6: d1 e9 shr %ecx 8bb6e8: 73 02 jae 8bb6ec <memcpy+0x1c> 8bb6ea: 66 a5 movsw %ds:(%esi),%es:(%edi) 8bb6ec: f3 a5 rep movsl %ds:(%esi),%es:(%edi) 8bb6ee: 89 c7 mov %eax,%edi 8bb6f0: 89 d6 mov %edx,%esi 8bb6f2: 8b 44 24 04 mov 0x4(%esp),%eax 8bb6f6: c3 ret
Intel としてはコンパイラの性能自慢のために、 自分らの過去のコードよりもインパクトのある数字だから 持ってきたんだろうなぁ。
他人にIQ200であることを指摘されるのが呪いなんじゃなくて、そういう特性を持ってしまったことが既に呪いなのだ。
リンク先の人々を見る限り、まんなかの呪いが一番事態をややこしくしているように見える。
知能検査は確かに小学校の頃にやった気がするが、あの結果は「普通は」本人には教えてもらえない。それを本人が知らされるということはその情報を持て余した人(=教師)がいるからだ。
Gifted な人(orその逆でも)たちをロクに扱えない人らにそんな情報をあたえることがそもそもの人災なんじゃないか。知能検査の結果を見るまでその子が「特殊」であることを認識してなくても支障が無かった(ように見える)んだろう？
あるいは IQ=50 とかの人を今まで認識してなくて検査で見つけてうまく教育した例とかあるのかな？
IQが極端に振れるような人は見る人が見れば(しばらく観察すれば)検査しなくても分かるような気がするんだが、かつそれで分からない人はどのみちまともにその子に適切な教育を施すことは無理だと思うんだが、なんで学校は知能検査するの？
当サイト的な分析であるが、大原先生の言うとおりこのバッファが質的には事実上のトレースキャッシュである点は間違いないだろう。 理由は簡単で、同記事にもあるとおり単なるバッファならFIFOバッファであるべきところをファーストループに沿って再実行できる点と、x86ではなくμOPsを保存することでデコードを省略している点から読み取る事ができる。トレースキャッシュの本質は「デコードと実行をデカップルすること」にあるわけだから、LSDはその条件を満たしている。 (Core MAの構造ではデコードと実行をデカップルできないから、一見似ているが動作の本質は全く異なる。)
このバッファは決してトレースキャッシュではない。分岐予測に失敗した場合には何処から再起動が掛かるかを考えると、トレースキャッシュとの違いが鮮明になる。 分岐予測に失敗した場合にもトレースキャッシュにHitする限りデコードをすっとばせるが、LSD および命令バッファは分岐予測ミスしたら flush されてしまって、デコードをすっ飛ばすことは不可能(のはず)。
つまりトレースキャッシュは実行パイプラインの(レイテンシの)短縮化が主な目的になっているのだが、命令バッファはあくまでも命令キャッシュ(メモリ)と実行部とのデカップルが目的(=メモリレイテンシの隠蔽と実効スループットの確保)である。
トレースキャッシュはその存在により、Hit すれば命令実行パイプラインが短いが、現実には Miss する割合がそれなりに避けられない以上、Hit/Miss の混在によって L1I$ 〜実行部への直接パスのスループットを阻害しうる (トレースキャッシュへの書き込み処理などが邪魔する) 。つまりスループット変動を起こしやすく、実効スループットは低下しやすい。
逆に、命令バッファは L1I$ 〜実行部の「実効」スループットを確保することが本質的な目的であり、パイプラインの全長は短くならない(しない)。
そう考えると、CoreMA方式とNehalem方式ではこのLSDを含むバッファの「目的」の点では差が無い。デコードの前段か後段かの違いがあるだけであり、「命令キャッシュ(メモリ)との」デカップルという目的はどちらも達成している。
ただし、x86アーキテクチャはデコードスループットが致命的なボトルネックになりやすい (あんな変態的な命令体系でスーパースカラは大変)ので、デコーダの後ろでデカップルするというのは、実効スループットを稼ぐという命令バッファの目的に最も適っている。つまり命令バッファをx86アーキテクチャ向けに最適化したというスループット向上の正当進化であって、レイテンシ主眼スループット無視(...は言い過ぎか)のトレースキャッシュのような先祖返りでは無いのである。
LSD もこの「実効スループット確保」の目的を考えると自然である。 前回の日記でも書いたことだが、ショートループになる場合には命令キャッシュ〜分岐予測機構の実効供給能力がピークの半分以下に下がる。 ループになる分岐命令は高い精度で分岐予測が出来るのに勿体ない話であって、ILP を確保できる優良顧客からしっかり確保しようというのが LSD である。
トレースキャッシュもショートループはキャッシュヒットするから高い性能が出るわけで、ショートループだけに目を付ければ同じように高スループットの挙動を観測できるので、同一視したくなるのは仕方がない話ですが。
(Ando's Processor Information の「最近の話題 2008年4月5日」経由)
ここでは LSD (Loop Stream Decoder) の話題を拾う。 そもそも実装されたのは Core2 (Conroe/Merom世代)。
たとえば IBM の POWER シリーズプロセッサのような、ある命令フェッチ機動と同時に分岐予測まで行って次のサイクルには分岐先アドレスを予測できる構造を取っている場合には(省電力をのぞいて)LSDなんて考え方は不要。 分岐予測のロスが無いんだから。
＃ とはいえキャッシュラインを跨ぐケースはあるので全くロスがないわけでは無い。やれば効果はある(はず)。
分岐予測のため野記憶バッファが大きくて、分岐先アドレスの予測が即座にできない場合に効果が出てくる。特に
loop: mov eax,[ecx] add ecx,1 cmp eax,0 jnz loop ... (命令はとてもてきとう)
のような短いループ構造の場合、 実行系は１ループが１サイクルのスループットで並列処理が出来てしまう のに対し、分岐予測は (命令フェッチアドレス生成 -> 分岐予測アドレス生成) に２サイクル掛かるとすると、分岐予測先のアドレスを待つために(毎回同じアドレスなのにね！)、実行系の半分のスループットしか出ないことになる。 つまり命令フェッチ側がボトルネックになる。
＃ パイプラインを書かないとイメージしにくいかも。
ゆえに、「(短い)ループと分かっているなら」分岐予測を省いてしまってその後ろのバッファからばがばかと繰り返し供給してやればよい、となる。 x86 のような CISC マシンはデコードも重いので Nehalem ではデコーダの後ろにまで持っていっただけ。
というのが基礎的な話題。
しかし触れられていない厄介な話題として、CISC アーキテクチャ特有の話として、命令書き換え(が可能)がある。
＃ RISC CPUは大抵は明示的に専用のフラッシュ命令を実行しない限りは命令書き換えしたことを反映しなくていいことになっているので、問題は限定的。
loop: mov [ecx],0x90909090 ; 0x90 は nop の機械語コード add ecx,100 jmp loop ...
たまたま 0x90 をメモリに書いたその先がこのループ命令列の jmp 命令 だった場合、 (条件はあるものの) jmp ではなく書き換えた後の nop を実行する(つまりループが終わる) 必要がある。
毎回命令フェッチを実行することでキャッシュにとりに行っていれば、 書き換えも反映されるはず(というようにキャッシュは設計されている)わけだが、 LSD の仕掛けではデコーダーの前後にある命令バッファを書き換えてやるとか、パイプラインをフラッシュして命令フェッチからやりなおすとか、してやらないといけない (命令セットアーキ違反になる)。 制御の方法はいくつか考えられるけれど、これは結構困難なことだったりする。
単純にアドレスを覚えて一致検出をするにしても、仮想アドレス(Virtual Address) で命令フェッチするのに、仮想アドレスが違うのにたまたま物理アドレス(Physical Address) が一致しているようなところに書き込まれた ケースまで含めて書き換えを認識する必要があるのだ。
MMU は大抵キャッシュ側にくくりつけられていて命令バッファの近くにはないので、面倒臭いことこの上ない。かといって大雑把にやりすぎると逆に足を引っ張るはずなのだが...。
＃ 単純にストア命令がいるときはあきらめるというのが手っ取り早い解決方法ではある。それでも周辺に影響は有るが。
Before...
_ tetsuya [綾成分無しは考えられまへんな。赤いというとこういうのですかクス ttp://jabro.jp/Entry/557/]
_ うかい [真人間なので痛車にはのっていませんわよオホホホホ]
_ tetsuya [その口調がすでに魔人間ぽいですぜひさかわさんプ]