#メモリ管理

この記事を読んでまず思ったのは、AI のメモリ機能って、便利そうに見えるけれど、雑にやるとすぐ壊れそうだということだった。 「覚えておく」だけなら簡単でも、何を、どの単位で、どのくらいの確からしさで残すのかを決めないと、あとで検索しても使い物にならない。そこに OKF みたいな形式を噛ませて、さらに SQLite FTS5 で引けるようにしているのは、かなり筋がいいと思う。単なる“気分のメモ”ではなく、検索できる記録に落としているのがいい。 ただ、読んでいて少し引っかかったのは、ここまで整えると今度は「AI の記憶」というより「人間が扱える知識ベース」にかなり寄っていくことだ。 それは悪いことではない。むしろ、AI の曖昧な内部状態に頼るより、ファイルとして見えて、消せて、タグで絞れて、履歴も残る方がずっと安心感がある。けれど同時に、これって本当に“記憶”なのか、という感覚は残る。実態は、上手に整理された外部メモ帳に近いのではないかと思う。 その「外部メモ帳」にも、ちゃんと思想があるのが面白い。memory/ に Markdown を吐き出して、人間がブラウザで読めるようにしつつ、裏で

「GPUで計算する」と聞くと、なんだか一瞬で魔法みたいに処理が終わる印象があります。 でも元記事は、その裏側にある泥臭い手順を、かなり執念深く追いかけています。しかも題材は、たった1行のベクター加算。`a[i] + b[i]` を並列に足すだけの、いちばん地味なCUDAプログラムです。地味だからこそ面白い。GPUという巨大な装置が、どれだけの段取りを踏んでこの1行を実行しているのかが、くっきり見えてきます。 `nvcc` は1つのコンパイラではなく、複数のコンパイラをまとめて動かす“司令塔”です CUDAのコードは、まずPTXという中間表現になり、その後SASSというGPU実機向け命令に変わります `vadd<<<4096, 256>>>(...)` のような記法は、ホスト側で引数を詰める「stub」に置き換えられます GPUカーネルの引数は、constant bank 0 に載って読み出されます 実行時には、CPU側のランタイム、`libcuda.so`、ドライバ、PCIe越しのGPUが連携して動きます ただ“GPUに投げた”だけに見える処理の背後で、かなり多くの機械的な準備が走って