Fudzilla Nehalem also has a TLB bug Core i7にもTLBエラッタが発見されたようですね。 IntelのPDFの37ページにある"AAJ1 Clarification of TRANSLATION LOOKASIDE BUFFERS (TLBS) Invalidation"という部分に書かれています。 稀にハングアップしたりデータが壊れてしまう事があるようです。 TLBエラッタといえば少し前にPhenomで問題になりましたが、BIOSの修正で直りましたね。 しかし10%程度パフォーマンスが低下してしまいました。 今回もBIOSのアップデートで修正されるようですが、パフォーマンスの低下があるのか、また起こるとしたらどれぐらいの確率なのかが気になりますね。 大事にならなければ良いですが･･･ The Tech Report Do Core i7s have
●L2キャッシュまでを含んだCPUコアブロック Intelは、4月2～3日にかけて中国上海で開催されている技術カンファレンス「Intel Developer Forum(IDF)」において、次期CPUマイクロアーキテクチャ「Nehalem(ネハーレン)」の概要を発表した。 Nehalemは一言で説明すると、現在のCore Microarchitecture(Core MA)の骨格に、新たにSMT(Simultaneous Multi-Threading)や3階層のキャッシュ、階層化したTranslation Lookaside Buffer (TLB)や分岐予測ユニットを始め、さまざまな機能を加えることでCPUコアのパフォーマンスアップを図ったCPUだ。加えて、高速インターコネクト「QuickPath Interconnect(QPI)」とDDR3 DRAMインターフェイスを実装し、システ
拡張命令から見るx86 CPUの最終回は、拡張命令の今後について語ろう。とは言っても、ここで述べるのはあくまで現時点で見えているだけの話である。 Sandy Bridgeで新命令「AVX」が追加 Larrabee命令のx86導入はまだ先？ まず、本筋とあまり関係ない話を片付けておこう。インテルが現在「Larrabee」と呼ばれるGPU(というかStream Processor)を開発中なのは、すでに周知の事実だ。このLarrabeeでは、「LRBni」(Larrabee New Instructions)と呼ばれる新しい拡張命令が搭載されることがすでに明らかにされている。 LRBniに合わせて、32個の新しい512bitベクタレジスター「v0～v31」と、8つの16bitマスクレジスター「k0～k7」が追加され、(少なくとも)Vector Arithmetic/Logical/Shiftの
計測対象は，Windows 7ベータ版（以下Windows 7）およびWindows Vista SP1（同Vista）それぞれの32ビット版と64ビット版。32ビット版は，4Gバイトを超えるメモリーを搭載しても，3.2Gバイトしか利用できない（画面）。64ビット版であれば4Gバイトをフルに利用できるものの，今のところほとんどのアプリケーションは32ビット環境のエミュレーション（WoW64）として動作するため，オーバーヘッドが生じる。このトレードオフが，Windows 7とVistaのそれぞれのベンチマークの結果にどう表れるのかに注目したい。 測定環境のマシンは，CPUがCore 2 Duo 6300（1.86GHz）で，メモリーは4Gバイト。32ビット版で利用できるのは3.2Gバイトまでで，64ビット版は4Gバイトすべてを利用できる環境での測定となる。ベンチマーク・ソフトは，英SiSof
64bit版のWindows 7のシステム画面。赤枠内を見ると64bit版だとわかるが、それ以外で32bitとの違いを意識することはまずない。はたしてどちらがパフォーマンスに優れるのだろうか？ メモリーの価格が下がり、4GB以上のメモリーを搭載するパソコンが珍しくなくなってきた。4GB以上のメモリーを有効に使うには、64bit版のOSが必要となる。しかもWindows 7のパッケージ製品には、x86版(32bit版)とx64版(64bit版)のインストールディスクが両方とも含まれるという。これを機に、「64bit版を導入してみようか」と考えている人も多いだろう。 64bit版の導入で最も気になるのは、所有しているハードやソフトの互換性だが、同じくらい気になるのは、「64bit版にしてパフォーマンスは良くなるのか」ではないだろうか。極論すれば、パフォーマンスが変わらない(あるいは下がる)ので
Most recent news 2008-02-25 Frode V. Fjeld * movitz.asd: Created an ASDF system definition. * movitz/asm.lisp, movitz/asm-x86.lisp: Created new assembler and disassembler that's less overengineered (the design goals of ia-x86 were not originally to serve as an assembler). This speeds up compiles considerably; on the order of twice as fast, and reduces the overall footprint of the movitz system too
個々の仮想化技術の説明に入る前に，まず仮想化技術が適用できるプロセッサの要件を明確にしていこう。以下では，汎用的な仮想化の要件について述べたうえで，現在最も広く使われているx86（IA-32）アーキテクチャを例に取り上げ，問題点を明らかにする。 すべてのセンシティブ命令が特権命令であることが要件 仮想化を実現するためにCPUアーキテクチャが満たすべき要件の研究は古く，IBM システム/360の時代から行われている。最も有名な論文としては1974年にCACM（Communications of the Association for Computing Machinery）に掲載されたGerald J. Popek氏とRobert P. Goldberg氏の“Formal Requirements for Virtualizable Third Generation Architecture
PopekとGoldbergの仮想化要件 (英:Popek and Goldberg virtualization requirements) とは、コンピュータアーキテクチャが効率的にシステムの仮想化を実現するための一群の十分条件である。ジェラルド・J・ポペック (Gerald J. Popek) と ロバート・P・ゴールドバーグ (Robert P. Goldberg) の 1974 年の論文 "Formal Requirements for Virtualizable Third Generation Architectures" (仮想化可能な第三世代アーキテクチャへの要件) で示された [1] 。これらの要件は簡単のため仮定に基づいたものであったが、コンピュータアーキテクチャが十分な仮想化機能を備えているかどうかの判断基準と、仮想化されたコンピュータアーキテクチャの設計についての
x86には様々なNOPがあり、Intel® 64 and IA-32 Architectures Software Developer’s Manual に記載のあるものだけでも1byte長から9byte長までの種類がある。 これにprefix等の選択肢を考えると、まさに無限に広がる大宇宙。といった感じの可能性の広さである。 で、LKML内ではNOPの種類によって速度が変わることが広く知られていて、時折どのNOPを使うのがよいかが熱い議論になる。 特に近年は自己書き換えコードの都合で最速5byte NOP議論が熱い（long jumpが5byteだからね）。 まあ、5byte NOPと3byte NOP + 2byte NOP（とprefix NOP）のどれが速いか、なんて議論は、自転車置き場理論によって無駄にスレッドがのびていくので見ていて楽しい（ほんとか？） で、最近話題になったのはl
初めて梅干しを作ってみた話 今年の夏、初めて梅干しを作りました。 私梅干し大好きなんですが、自分で作るという発想がなくて…同僚が梅シロップを作っているのに影響されて去年から梅仕事を始めてみたんですが、そのときの説明書に「梅干しの作り方」というのも入っていて、えーー梅干しって自分…
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
