2024-04-11: avashe
近頃は映画にしろ小説にしろゲームにしろ、遠回しに感じられて億劫だ。ある時期を境にアニメを見たいと思わなくなったが、映画にもそれを感じつつある。
物語は例えと娯楽と表現からなる。私は例え、つまり物語が指示する対象の興味深さを期待するが、費やされる紙幅に対して、指示できる対象はあまりにも少ない。それなら直接それについて論じる本を探したほうがいい。娯楽は見れば見るほどテンプレートが蓄積していき見慣れたものになってしまう陳腐化の激しいものだ。そして感動する表現に出会えることは極めて稀である。
これは億劫なことに理由を後付けているだけなのかもしれないし、フィクションよりもノンフィクション、人文書や技術書が今私の中で流行っているというだけなのかもしれない。それが終わればまた何食わぬ顔でアニメや映画に熱中するのだろう。しかし、万が一私にとって物語が役割を終えつつあるとするならそれはきっと喜ばしい変化だ。
あるいは加齢によるもの?いやむしろ仕事に関する疲れや憂鬱、生活リズムの乱れによるものだろう。
物語は読むより作るほうが楽しいのかもしれない。
なぜ日記が続かないという人はそれを毎日つけなければならないものと定義し、続かなかったと言うのだろう 私は書き記したいなと思ったときに書くものが日記だと思っているから失敗したことはない
そういう意味では小学生6年生から続いていることになる。その頃の日記はまだ手元にあるのだが、さすがに恥ずかしいので自分が健康なうちに処分しないといけない。
第一、毎日つけなければならないものをつけられないと言うなら、それは思わずつけたくなるような出来事がなかったということであり、その日常の平坦さをなんとかしなければならなくなる。私はそんな風に急き立てられたくない。
目的を明確にすることが大事だ
もし自分の生活にあったできごとをなるべく正確かつ客観的に残したいなら、日記というフリーフォーマットを使うより、google calendarのようなスケジューラを細かく作り込み、適宜感想をその予定のノートに書いていく方が適しているかもしれない。
私はその時考えていることを好き勝手書き散らすことが目的だ、特筆すべきことがあったらついでに書く
なので日付の正確さは不要で、ざっくりそれを考えていた時期がわかれば十分だ
とりあえず水平分散すりゃええやんという分散DBの風潮の中で、そもそもノードのリソースを使い切れているか?という問題を提起し、収容率を上げるために現代の多コア計算機を使い切ることを目的としたShared Nothing Modelのソフトウェアで、すごくいいなと思った
あまりにも周回遅れだけど、まぁありのままの自分を受け入れていこう
流行りのソフトウェアが現れる度ちゃんと時間作って読んでいけばよかったなぁと後悔する。けどそんなに週末勤勉だと趣味の本は読めなくなるだろう。ちょうどいい妥協点がほしいところだ。
なぜ良いのかというと、自分の頭の中にない新しい並列プログラミングのスタイルを見たから。素朴に自分がCPUを使い切ろうとしたときに考えつくのはスレッドプールやイベント駆動だが、seastarはその折衷案を提出する。seastarはスレッド-CPUコアが1:1対応するように固定されており、実行したいプログラムはスレッドにコールバックという形で登録され、実行される。そのコールバック内のコードはFuture/Promise/Continuationのような非同期プログラミングが使えるので、プログラム内にはほとんどロックを取る箇所が存在せず、コンテキストスイッチとCPUキャッシュの書き換えが最小限に抑えられている。ちなみにコア間の通信は読みこみ/書き込みのキューがCPUコアの組み合わせごとに確保されており、これらを使ってロックフリーを実現している。でもってネットワークスタックがDPDKでユーザランドに実装されているのでカーネルランドへのスイッチも最小限に抑えられている。ここまで徹底していると、CPUコアを妨げる要素はほとんどなくなり、従来ソフトウェア上で実装されていたイベント駆動は、ハードウェアに移譲されたものと見なすことができる。NICのバッファがメモリへコピーされ、ハードウェア割り込みが走ることがイベント駆動のシステムそのものとなる。RSS, RPS, RFSなどを併用すればNICバッファ-スレッド-CPUコアまで綺麗に1:1対応する。 このアーキテクチャの美しいなと思うところは、SMP上に実装されたサーバソフトウェアのアーキテクチャとして説明を聞いたときに、なるほどこれ以上早いシステムは簡単に思いつかないと納得させられるところだ。これ以上を求めるなら地道に計測しながらCPUの挙動を妨げないようメモリやキャッシュの配置を最適化していくなど、アーキテクチャではなく各コンポーネントの細かい調整になるだろう。
このアーキテクチャのトレードオフ上のデメリットはわかりやすい。NICからの割り込みで駆動する並列処理サーバーシステム、という枠をはみ出すと途端に扱いづらくなってしまうこと。また、ネットワークスタックが再実装されているので、ネットワーク上の要件が色々ある場合実装しなければならないことが挙げられる。調停してくれる下層のシステムをバイパスするソフトウェアは、往々にしてそのユーザにも高い開発力を要求する。
ここまでカリカリに詰めてるソフトウェアだと、k8sやハイパーバイザーなどの仮想化基盤との相性が気になる。追加のパススルー設定が必要なら、その自動化のための開発が必要になるだろう...と思ったのだがscylla-operatorのパフォーマンスに関するテキストを読むと、パススルーではなくCPUアフィニティやIRQ処理のCPUを設定するくらいらしい。 私はいつもコードでどう実現するか確認するのをサボりがちなのだが、これについてはちゃんと読んでみたい
プログラマのセンスを磨くという行為において名著や論文、公式ドキュメントにあたったり、web媒体で新しい情報をキャッチアップするというようなコードではないものを読む行為は前提に過ぎない。最終的には、優秀なコードをどれだけ実際に確かめてきたかに集約されるだろう。私は業務時間こそコードをつぶさに調べるのだが、休日や余暇にソフトウェアを調べようと思うと一転してコードを読むことを渋ってしまっていた。
syuuさんのスライドがわかりやすい
slideshareがいつのまにかページをポチポチめくる命式ではなくスクロールで読めるようになってる!素晴らしい
seastarのコンセプトのRust版を見つけた
RDMSではアクセスパターンを気にせずに正規化されたテーブルを設計し、参照時にJOINを書いてアクセスパターンを作る
自由なアクセスパターンが許される代わりに、計算量は高くつく
一方でNoSQLではビジネスに必要なアクセスパターンを予め全て割り出し、それを具体的に表現したテーブルを全て作っておく
アクセスパターンは固定されているが、計算量は安い
NoSQLでは、テーブル数は可能な限り少なくする
JOINs の必要性をなくすことが NoSQL データモデリングの中核となります。