#cpu

この記事でまず面白いと思ったのは、AI エージェントが「文章を書く道具」ではなく、異常の監視役として役に立っているところです。Claude Code が、開発者の Mac の中でこっそり動いていた crypto miner を見つけたという話は、かなり地味なのに妙に示唆的でした。人間が見落としていたものを、ログや挙動の違和感から拾い上げたわけで、こういう使われ方はかなり実用的だと思います。 それと同時に、ちょっと怖さもあります。CPU が 1175% まで跳ね上がって、温度が 112 度まで上がる。数字だけ見ると、もはや「重い処理をしている」では済みません。Mac は静かで頑丈な顔をしていても、裏で何かが回り続ければ普通に壊れかねない。その意味で、AI が犯人捜しを手伝ったというより、「気づくのが遅れたらまずかった案件を、たまたま AI が拾った」と読むほうがしっくりきます。 ただ、ここで少し引っかかるのは、こうした検知が AI に依存し始めると、便利さと引き換えに見逃しの責任がどこにあるのか曖昧になりそうなことです。人間の監視では気づけなかったからこそ AI が役立った。でも、逆に

Google Open Source Blogが伝えたのは、数字の配列をかなり速く並べ替える公開コードだ。しかも速いだけではなく、Intel、Arm、RISC-V といった複数のCPUで動く「portable」な実装だという点が面白い。ソートは地味に見えるが、データベースや分析処理の土台になるので、ここが速くなると上の層まで効いてくる。この記事は、単なる性能自慢ではなく、「どうやってそんな差を出したのか」をかなり具体的に説明している。 元記事は、数値配列をソートするオープンソースコードを公開したという話から始まる。そのコードは C++ の `std::sort` より約10倍速く、しかも「最先端のアーキテクチャ専用アルゴリズム」を上回ると説明している。ところが、ここで強調されているのは単純な高速化ではない。AVX-512専用、Arm専用といった一発芸ではなく、現代の主要CPUアーキテクチャのあいだでそのまま持ち運べる実装であることだ。 背景にあるのは、最近の columnar database の流れだ。これは行ごとに全部を並べるのではなく、同じ列の値をまとめて保存する方式で、SQLク

x86 の命令列を見ていて `ud2` に出会うと、ちょっと不思議に感じる。どちらかというと「未定義命令」という雑な名前で十分に見えるのに、わざわざ 2 が付いているからだ。Raymond Chen の短い記事は、その素朴な疑問に対して、Intel の仕様と現場の歴史がどう重なって今の形になったのかをたどっている。単なる命名の話に見えるが、実際には「何を壊してよいのか」「どの挙動を仕様として保証するのか」という、CPU 設計のかなり大事な話でもある。 記事の出発点は、x86 のコンパイラ出力や、API を横取りするようなソフトウェアのクラッシュ解析で `ud2` を見かけることだ。`ud2` は architecturally undefined instruction、つまりアーキテクチャ上「未定義」とされる命令で、実行されると必ず “invalid opcode” 例外を起こす。コンパイラはこれを、そこに来ては困る場所の目印として使う。たとえば `[[noreturn]]` が付いた関数が、理屈の上では戻らないはずなのに戻ってきてしまった場合、その直後に `ud2` を置いておけば

中国のスーパーコンピュータ「LineShine」が、最新のランキングで世界最速の座を奪い返しました。しかも、ただ速いだけではありません。今回の話でいちばん面白いのは、「最先端＝GPU大量投入」という今どきの流れに、あえて乗っていないことです。CPU中心で2 exaflops超えを達成した、かなり異色のマシンなのです。 中国の「LineShine」が、世界最速スーパーコンピュータの座を獲得した 実性能は 2.198 exaflops で、米国の「El Capitan」（1.809 exaflops）を上回った CPUだけ で sustained double-precision performance が2 exaflopsを超えた初のシステムとされる GPU依存ではなく、独自の304コアCPU と独自インターコネクトで構成されている 2026年のランキングでは、exascale級を超えるシステムが5台に増えた 中国は輸出規制の制約がある中で、別の設計思想で首位を取り戻した形になった スーパーコンピュータの性能は、ざっくり言うと「どれだけ大量の計算を一気にこなせる

2016年製のXeon、DDR3メモリ、GPUなしという“普通なら無理”な環境でLLMを動かした話 速さのカギはCPU性能よりもmemory bandwidth（メモリからデータを運ぶ速さ） speculative decoding で、重いモデルの前に軽いモデルを走らせて高速化している MoE（Mixture of Experts）モデルでは、どの expert をどう扱うかが性能に直結する mlock や run-time-repack みたいな地味な最適化が、古いマシンではかなり効く 便利な黒箱ツールではなく、細かいフラグを理解して使い分けることが重要 「10年前のXeonで最新級のLLMを動かす」と聞くと、正直かなり無茶に見えます。 でも今回の元記事は、その“無茶”をちゃんと工夫で押し切る話で、かなり面白いです。私はこういう、性能の限界をソフトウェアでねじ伏せる系の話が大好きです。ロマンがあります。 舞台は、2016年製の Intel Xeon E5-2620 v4 を積んだ再生サーバー。 メモリはなんと **128GB DDR3