ユメのチカラ: メモリアクセスは遅い
多くのプログラマにとってメモリアクセスの速度を気しなければならない状況というのはめったに無いが、OS、ライブラリ、コンパイラ、RDBMSなどの実装をする時には意識をしなければならない場合がある。 IA-32 Intel Architecture Optimization Reference Manual (order number 248966) をひもとくと6章にOptimizing Cache Usageというのがある。 マイクロベンマークの定番 lmbench http://www.bitmover.com/lmbench/ では、一次キャッシュ(L1)や二次キャッシュ(L2)を測定してくれる。例えば、わたしが利用しているノートだと、L1が1.776nsでL2が5.3490ns、メインメモリアクセスが139.4nsである。 Memory latencies in nanosecond
ユメのチカラ: Latencyの隠蔽
プログラマたるものコンピュータの基礎的な知識は必要だと多くの人は言うのだけど、じゃあどこまでが必須でどこまでがオプション（？）なのかというと明確な線引きがあるわけではない。まあ、Kernelとかコンパイラとかをゴニョゴニョする人はCPUのキャッシュがなんたるかくらいは理解していないといろいろ大変かと思う。 時間と空間を交換するというのはコンピュータだけの世界ではない。街のコンビニだって、店頭に並んでいるものはすぐにアクセスできるけど、店頭にないものはすぐにアクセスできないので、在庫量がある一定水準を下回ったら発注のトリガーがかかる。コンビニはその発注サイクルがデパートとかに比べれば異様に多いので、クロックを上げて性能を出すPentium4みたいなものである。発注単位も非常に小さくて、それこそ弁当一個でも平気で発注しちゃうという感じである。在庫をほとんど持たないので、キャッシュミスした時のペ
CPUのバグ、深刻度はいかほどか
ソフトウェア同様、CPUにもバグはある。IntelはBIOSベンダーと大手OSメーカーに詳細なフィックスを提供しており、オープンソースOSはおおむね蚊帳の外に置かれているようだ。 これは普通のバグ報告やパッチとは違う。問題があるのはCPUだ。人々はその深刻度を議論している。 CPUのバグは何も新しいものではない。1990年ごろ、わたしはIBMのDOSバージョンに取り組んでいたプログラマーと1日過ごしたことがある。彼は一部のIntel CPUにいかにバグが多いか、そのことについてどれだけIntelに苦情を言ったか（そして無駄だったか）をひっきりなしに話していた。これはOSを書く仕事ではよくあることだが、セキュリティの角度から見ると比較的新しいと言える。 この件に関するシオ・デ・ラット氏の率直なブログは、さまざまなセキュリティリストで引用されている。デ・ラット氏はCore 2 CPUラインには
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
