おや、私の車(駐車中)が写ってる。でも場所が正しくないなぁ。
]]>バイト単位でコピーするアホなコードの方が、勝手にベクトル化される分、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 としてはコンパイラの性能自慢のために、 自分らの過去のコードよりもインパクトのある数字だから 持ってきたんだろうなぁ。
]]>やねうらお氏のところでは現在56手だそうだが、 もう少し長いのが「将棋ガイドブック」p176 に書いてある。 それですら最長と証明されてるわけではなくもっと長いのがあるかもしれないとのこと。
コメントかけないのでここで。
]]>英単語のメモ
小野路のところ、いつの間にやら開通していたのねー。 Google map にも反映されているところを見るとだいぶ前(2〜3年くらい前？)からなのか？
]]>他人にIQ200であることを指摘されるのが呪いなんじゃなくて、そういう特性を持ってしまったことが既に呪いなのだ。
リンク先の人々を見る限り、まんなかの呪いが一番事態をややこしくしているように見える。
知能検査は確かに小学校の頃にやった気がするが、あの結果は「普通は」本人には教えてもらえない。それを本人が知らされるということはその情報を持て余した人(=教師)がいるからだ。
Gifted な人(orその逆でも)たちをロクに扱えない人らにそんな情報をあたえることがそもそもの人災なんじゃないか。知能検査の結果を見るまでその子が「特殊」であることを認識してなくても支障が無かった(ように見える)んだろう？
あるいは IQ=50 とかの人を今まで認識してなくて検査で見つけてうまく教育した例とかあるのかな？
IQが極端に振れるような人は見る人が見れば(しばらく観察すれば)検査しなくても分かるような気がするんだが、かつそれで分からない人はどのみちまともにその子に適切な教育を施すことは無理だと思うんだが、なんで学校は知能検査するの？
]]>ぼったくりだろーと思うくらいに高かったはずなのに、 全線開通したからか、新名神が開通したからか知らないけど、 いつのまにか普通の値段になっているのね。
わざわざ使うことはないだろうけど。
]]>先月末に開業した横浜市営地下鉄グリーンラインがまだ google map では観測できない。2月開業の新名神(亀山〜草津田上)もないな。2005年の地図なのかー。
Yahoo! Map にはある。すばらしい。
]]>当サイト的な分析であるが、大原先生の言うとおりこのバッファが質的には事実上のトレースキャッシュである点は間違いないだろう。 理由は簡単で、同記事にもあるとおり単なるバッファならFIFOバッファであるべきところをファーストループに沿って再実行できる点と、x86ではなくμOPsを保存することでデコードを省略している点から読み取る事ができる。トレースキャッシュの本質は「デコードと実行をデカップルすること」にあるわけだから、LSDはその条件を満たしている。 (Core MAの構造ではデコードと実行をデカップルできないから、一見似ているが動作の本質は全く異なる。)
このバッファは決してトレースキャッシュではない。分岐予測に失敗した場合には何処から再起動が掛かるかを考えると、トレースキャッシュとの違いが鮮明になる。 分岐予測に失敗した場合にもトレースキャッシュにHitする限りデコードをすっとばせるが、LSD および命令バッファは分岐予測ミスしたら flush されてしまって、デコードをすっ飛ばすことは不可能(のはず)。
つまりトレースキャッシュは実行パイプラインの(レイテンシの)短縮化が主な目的になっているのだが、命令バッファはあくまでも命令キャッシュ(メモリ)と実行部とのデカップルが目的(=メモリレイテンシの隠蔽と実効スループットの確保)である。
トレースキャッシュはその存在により、Hit すれば命令実行パイプラインが短いが、現実には Miss する割合がそれなりに避けられない以上、Hit/Miss の混在によって L1I$ 〜実行部への直接パスのスループットを阻害しうる (トレースキャッシュへの書き込み処理などが邪魔する) 。つまりスループット変動を起こしやすく、実効スループットは低下しやすい。
逆に、命令バッファは L1I$ 〜実行部の「実効」スループットを確保することが本質的な目的であり、パイプラインの全長は短くならない(しない)。
そう考えると、CoreMA方式とNehalem方式ではこのLSDを含むバッファの「目的」の点では差が無い。デコードの前段か後段かの違いがあるだけであり、「命令キャッシュ(メモリ)との」デカップルという目的はどちらも達成している。
ただし、x86アーキテクチャはデコードスループットが致命的なボトルネックになりやすい (あんな変態的な命令体系でスーパースカラは大変)ので、デコーダの後ろでデカップルするというのは、実効スループットを稼ぐという命令バッファの目的に最も適っている。つまり命令バッファをx86アーキテクチャ向けに最適化したというスループット向上の正当進化であって、レイテンシ主眼スループット無視(...は言い過ぎか)のトレースキャッシュのような先祖返りでは無いのである。
LSD もこの「実効スループット確保」の目的を考えると自然である。 前回の日記でも書いたことだが、ショートループになる場合には命令キャッシュ〜分岐予測機構の実効供給能力がピークの半分以下に下がる。 ループになる分岐命令は高い精度で分岐予測が出来るのに勿体ない話であって、ILP を確保できる優良顧客からしっかり確保しようというのが LSD である。
トレースキャッシュもショートループはキャッシュヒットするから高い性能が出るわけで、ショートループだけに目を付ければ同じように高スループットの挙動を観測できるので、同一視したくなるのは仕方がない話ですが。
]]>