#メモリ管理

Rust で長く開発してきた人が、Zig を実際に触って何を感じたのかを書いた記事だ。単なる印象論ではなく、JSONPath という実用的なライブラリを Rust 版から Zig 版へ移植しながら、IDE 支援、ファイル構成、テスト、関数型っぽい書き方、メモリ管理の手触りを比べている。面白いのは、Zig を持ち上げる記事ではなく、Rust に慣れた目で「どこが気持ちよく、どこが面倒か」をかなり率直に書いている点だと思う。言語の思想の違いが、日々の作業の小さな癖にどう出るのかが見えてくる。 書き手は冒頭で、自分はこの7年間 Rust 開発者としてやってきたと述べる。主に OSS を扱い、Rust の関数型寄りの書き方、たとえば整った関数や表現力のある型に親しんできた。一方で Zig も以前から気になっていた。C の後継候補として、より低レベルで軽く、しかも実用言語として存在感を増しているからだという。昔 C を触っていたこともあり、Rust と比べたらどう感じるかは前から興味があったらしい。 ただし、この記事は Zig の上級者が書いたものではない。最初に触ったプロジェクトがこの移植作業

この記事で一番引っかかったのは、「これは便利そうだ」と思うのと同時に、「でも今いちばん困っている人にはまだ届かないのか」という距離感だった。クラウド上では、複数のthreadを束ねて、shared memoryまで持たせて、プロジェクト全体をまとめて動かせる。たしかに、AI coding agent が増えてきた今、個々のagentを賢くするより、どう管理するかのほうが先に難しくなるので、この発想はかなり筋がいいと思う。 特に面白いのは、threadごとに会話を分けつつ、それらが互いに memory を共有するという設計だ。普通の「AIに一発で全部やらせる」やり方だと、途中で話が崩れたときに戻りにくい。でもthreadを名前付きで追いかけられて、途中から方向修正もできるなら、AIを“暴走しやすい作業者”ではなく、“途中で指示を出し直せる部下”として扱える。そこはかなり実務っぽい進化だと感じた。 一方で、この記事を読んで素直にモヤっとしたのは、memory の中身がよく見えないことだ。何が保持され、どこまで残り、消せるのかがはっきりしないまま「shared memory」と言われても、現

この記事を読んでまず思ったのは、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に投げた”だけに見える処理の背後で、かなり多くの機械的な準備が走って