Booklog 2025

2025-02-20

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 141 ~ 149, pages read: 9

第 9 章 マルチプロセッサ。 multiprocessor は 2 つ以上の CPU を持つハードウェア形態。 CPU パイプライン観点では命令流を増やすことで命令流の密度を高める。 ざっくり様々な形式がある。異種・同種の CPU による構成、 SIMD 型・ MIMD 型、集中共有メモリ型(UMA 型)・分散共有メモリ型(NUMA 型)。 つまり最近の Ryzen AI 9 HX 370 なんかは異種の構成か。heterogeneous multiprocessor という。 MIMD(Multiple Instruction stream, Multiple Data stream)型 は各 CPU が個別の命令流を、 SIMD(Single Instruction stream, Multiple Data stream)型は同じ 1 つの命令流を処理する(SIMD 命令とは別)。 SIMD 型は PC レジスタを共有し命令制御のハードウェアを共通化できるため規則的な大量データ処理に向き、 GPU で使われる。 共有メモリ型(Shared Memory Architecture)は各 CPU でメモリアドレスを共有する。 集中 UMA(Uniform Memory Access)と SMP(Symmetric Multiprocessing)はメモリアクセス時間が一定で、分散 NUMA(Non-Uniform Memory Access)はメモリアクセス時間に差が出る。 メモリアドレスを共有しない構成は、メッセージ交換型(Message Passing System)、私有メモリ型(Private Memory)、 NORMA(NO Remote Memory Access)、分散メモリ(Distributed Memory)型等。 近年主流の MIMD 型かつ共有メモリ型の採用は、ハードウェアの実装効率や性能向上よりもソフトウェアの実装が容易な構成に寄せてると。なるほどなー、それだけソフトウェア実装も大変なんやろう。

2025-02-19

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 133 ~ 140, pages read: 8

第 8 章 システムコール、例外、割り込み。 頻度が稀であるのと、 CPU 毎による差異、対処にシステムレベルの対応が必要なためソフトウェア的にできることは少ない。 システムコールの呼出回数を減らすためのバッファリングや一部の命令をユーザーレベルで実行。 例外では性能課題になりうるページフォールトがあるが、命令流切替と相対して小さいので割り切ってもよい。 割り込みは発生頻度を抑えることで改善できるが、その場合デバイスの応答性を下げるトレードオフになる。 最後は実験。ゼロ除算が Linux の場合整数と浮動小数点を SIGFPE 荷集約して区別しない場合があるの初めて知った。

2025-02-18

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 127 ~ 132, pages read: 6

第 8 章 システムコール、例外、割り込み。 これらの挙動は CPU のパイプラインの挙動に似て、事象の発生で命令フェッチが始まる。切替先命令列を handler と呼ぶ。 handler の先頭アドレスは vector table からロードされ、 PC レジスタに書き込まれ、命令フェッチが始まる。 命令流の切替は特権レベルも伴い、多くはユーザレベルから上位へ遷移するが、そのままの場合もある。 これらの処理が終わると元のソフトウェアの命令に戻る。戻り先やレベルは一般的に CPU が自動的に専用のレジスタへ保存する。 切替後の振る舞いは事象によって異なり、例えば例外では元の命令流をキャンセルする必要があり、割り込みでは要求が受け入れられなかったりする。 これらは、一般的に分岐予測の対象しない、特権レベルの変更と handler から戻るときに逐次的実行が必要になる(アウトオブオーダー実行できない、パイプラインを空にする(pipeline flush))、 vector table , handler の分岐予測ミス・キャッシュミス・ TLB ミス、といった通常の分岐命令との違いで遅くなる。 どんだけ遅くなる要素があるねんという気がしてきた...

2025-02-17

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 122 ~ 127, pages read: 6

第 8 章 システムコール、例外、割り込み。 システムコールは、デバイスへのアクセス要求・メモリ割り当て等で利用される。専用の命令で発生しレベル変更と命令流切替を行う。戻るためにも専用の命令を実行する。 システムコールの特権レベル(privileded level, 例外レベル exception level とも)には最も制限された user level と広いアクセスが許可された supervisor level(kernel level/OS level とも)、仮想化を支援する hypervisor level 等がある。 例外は、ゼロ除算やアクセス違反など命令を続行できないケースをハードウェアが検知して発生する。これにより異常が生じてもシステムを健全に保てるようにする。 割り込みは CPU 外部からの要求をまとめる割り込みコントローラが割り込み要求をして CPU にとって非同期に発生する。 教科書的に覚えるゾーン。

2025-02-16

家庭の低温調理 完璧な食事のためのモダンなテクニックと肉、魚、野菜、デザートのレシピ 99, read count: 1, page: 264 ~ 292, pages read: 29

わたしの場合ピクルスは発酵で作るので参考にしないが、コンフィは気になる。また常備菜のように比較的長く保存する場合は塩や発酵に頼らないと食中毒リスクが高まるから中々難しい。 最後に訳者注。 sous vide(スーヴィード)は真空という意味だが、真空調理より低温調理というのが主流になったのでそう訳したと。ただし「定」温調理の方がいいような気がしてると。 低温調理ならではの食中毒のリスクを意識しろってのはそうやわなと思った。 発酵ばかりしてると塩とか酸でリスク低減されるからうっかり忘れがちだが、低温調理の場合それらに頼れない場面もある(肉の調理のところで食感云々があったように)。 読み終えてみて低温調理は、食材の状態を狙った調理や風味の抽出・浸透に向いてる印象で、かつ温度は自動で管理するから失敗しにくいというのが魅力かと思った。あとは実践するのみかー。

2025-02-15

家庭の低温調理 完璧な食事のためのモダンなテクニックと肉、魚、野菜、デザートのレシピ 99, read count: 1, page: 238 ~ 263, pages read: 26

アルコールを蒸散させることなく適度な温度で砂糖を溶かし風味を抽出するには低温調理が向いていると(この本では 60 ℃)。 85 ℃以上の調理になるとガラス容器が急な加熱で割れることがあるので、あらかじめ容器を入れるなど徐々に加熱するよう注意が必要。 カクテルのことを全然知らないので調べたが、ビターズは蒸留酒に様々な材料を漬け込んで作成する苦みと香りが強いアルコール飲料のことで、カクテルに使われることが多いらしい。 そのビターズやシロップ等を作るのに低温調理が向いているということみたい。 甘い酒を好まないので 20 年くらいカクテルに触れてない気がするけど、ペニシリンはスコッチベースだしこれは試してもいいかも。

2025-02-14

家庭の低温調理 完璧な食事のためのモダンなテクニックと肉、魚、野菜、デザートのレシピ 99, read count: 1, page: 206 ~ 237, pages read: 32

卵を使ったデザートが多いのは、凝固点の 85 ℃に達さずに完璧に卵を調理するには低温調理が向いてるから。 また風味の抽出に向いてるからアイスクリームに最適と。ただし原液を作るまでが低温調理で以降はマシンなりを使う必要がある。 個人的には子どもに野菜ペーストを混ぜた団子が好評だったので、レンチンより低温調理の方がカボチャとかの野菜の風味が上がるなら、次作るときに応用できそうで興味あるな。

2025-02-13

家庭の低温調理 完璧な食事のためのモダンなテクニックと肉、魚、野菜、デザートのレシピ 99, read count: 1, page: 176 ~ 205, pages read: 30

野菜のセルロースを分解するためにほとんどのレシピで 85 ℃。 根菜の長時間調理だとボツリヌス菌とか大丈夫なんかなと思ったけど、長期保存しないメニューで調理時間もさほど長くないし 85 ℃で調理するから安心なんかな。 調べると、中心温度 80 ℃で 30 分間の加熱で毒素が失活するというのがあったし。 パースニップは流石に近所で手に入らんな。万能マッシュルームはめちゃうまそう。

2025-02-12

家庭の低温調理 完璧な食事のためのモダンなテクニックと肉、魚、野菜、デザートのレシピ 99, read count: 1, page: 122 ~ 175, pages read: 54

豚の低温調理で気になるのは菌や寄生虫だが、こういうのは本では直接的に書いてないから低温調理器具の説明書で見るのが良いか。でも 57 ℃あたりが下限になってるし大丈夫そうか。 肉の調理がこれまででも最長時間ぽいな。実際こんなに調理に時間をかけた経験は発酵以外にない。 しかしキュアリングソルトが使いにくいからパストラミが作れないのは残念。 まだ低温調理器具買ってもないけど気持ちだけは高まってきた。

2025-02-11

家庭の低温調理 完璧な食事のためのモダンなテクニックと肉、魚、野菜、デザートのレシピ 99, read count: 1, page: 46 ~ 121, pages read: 76

低温調理にも色々あって、そのもので一品を仕上げるのと、下ごしらえとして施してその後さっと焼き目をつけたりで＋αする方法がある。 いずれにも同じなのが高温で調理すると実現できない手軽な方法で失敗しないジューシーな食感が得られるところか。 マスのオイル煮とコンフィは俄然興味あるな。コンフィは Cooking for Geeks に油は熱を伝える以外に関係ないって書いてたし、あれは低温調理ならではの味わいなんやろう。

2025-02-10

家庭の低温調理 完璧な食事のためのモダンなテクニックと肉、魚、野菜、デザートのレシピ 99, read count: 1, page: 1 ~ 45, pages read: 45

分子調理の延長で読んだ。 Nomiku は潰れたけど他メーカーがポータブルな低温調理器具を販売し続けてるのも考えたらやっぱイノベータやったんやろな。 卵の章まで読んだが、日本の場合は生卵を食すために尋常でない努力があるので安全に生卵を食べれるから、低温殺菌のところはピンときにくい。 でも俄然興味が湧いてくる。低温調理器具ほしいな。

2025-02-09

分子調理の日本食, read count: 2, page: 1 ~ 155, pages read: 155

素面で読み返すべきかなと思って再度読んだ。 昨日煮汁を使ったらええんちゃうかと書いたけど、透明度の高いジェランガムを使ってスノードームを模したいので煮汁を使ったら濁るからイマイチな気がする。 濁ると吹雪いてる感じになりそう。白濁していいなら元々寒天でも使ってるだろうに。 ジェランガムはじめとして、他の添加物も器具も結構高くてお試しで買うにはかなりハードル高いな。そういう意味でも空想の料理なのかも。大豆レシチンは唯一手頃？

2025-02-08

分子調理の日本食, read count: 2, page: 1 ~ 13, pages read: 13

今日は酔っ払っており、手元にある本を読んだ。 2021 年の本だが、この本の仮想のレシピ集は気合を入れれば日常的にできそうだなという感触を掴めた(恐らく記述時点でそれを狙ってたのであろうが)。 しかしスノードームふろふき大根、これの茹で汁を捨てるんだ～と思い、煮汁の味を凝縮して提供できないのかと思ったわたしは、教科書的には NG だろうか。 このような読者に対しては、まず実践してからモノを言えと。酔っ払ってないときにご飯を作って実践したいと思いますんません。

2025-02-07

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 119 ~ 122, pages read: 4

第 8 章 システムコール、例外、割り込み。 分岐命令の他に命令流の特別な切り替えが存在する。それらの呼び方や定義は CPU によってまちまちなので、本書では例外・割り込み系と総称する。 システムコール(内部的に特権レベルの変更命令で明示的に発生)、例外(内部的に命令実行時のエラーなどハードウェアが検知し暗黙的に発生)、割り込み(外部的要求により発生)の 3 つに分類する。 発生頻度が比較的稀であること、ソフトウェア的な観点で対策が難しく、もっと低いレイヤでの対応が主。 この図がわかり良いよな言葉に出来ないけど。発生する場所とか考えたことなかった。

2025-02-06

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 111 ~ 118, pages read: 8

第 7 章 I/O。 ソフトウェア的な I/O デバイスの遅さを緩和する方法は基本的に I/O アクセスの回数を減らす方法。 I/O デバイスへのアクセスをページキャッシュ・バッファキャッシュで減らす、また 1 回の I/O アクセスにまとめる等。 ただし I/O デバイスへのアクセス回数の減少はそのまま応答性の劣化につながると。ここでいう応答性はリアルタイム性能？ 計測実験は RTC(Real Time Clock) と PCI Express 。 I/O なくしてソフトウェアは成り立たないのでなくすことはできないが緩和策を使ってうまく付き合おう、というわけか。悩ましいな。

2025-02-05

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 106 ~ 111, pages read: 6

第 7 章 I/O。 I/O デバイスはコストと消費電力の観点から CPU に比べると動作周波数が低いため CPU から見て遅い。 I/O バスもそれ同様なのと、多数のデバイスを識別する新規デバイスへの対応、動的な着脱、バスの規格やプロトコル・複数のバスをまたぐことで、遅い。 また I/O デバイス自体がキャッシュ・バッファ・プリフェッチといった高速化手法を使えず、遅い。 これらの特性は汎用的な対処が難しいので CPU 的に割り込み要求(interrupt request)、 CPU を介さずメモリ間でデータ転送する DMA(Direct Memory Access) といった I/O アクセス自体を減らす仕組みがある。 CPU によっては I/O アクセスを制御する命令、 I/O デバイスから主記憶に直接アクセス可能、 I/O デバイスと CPU が L3 キャッシュを共有するなどの工夫もある。 I/O デバイスの遅さを緩和するためなら何でもやるなという印象。

2025-02-04

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 101 ~ 106, pages read: 6

第 7 章 I/O。 本書では CPU の外部デバイスの内主記憶を除くデバイスへの操作を I/O アクセスと呼ぶ。 I/O アクセスはメモリのように見せかけるメモリマップド I/O(memory-mapped I/O)とデバイス専用アドレス空間を用いる I/O アドレス空間(I/O address space)を用いる I/O 専用命令がある。 I/O アクセスにより、デバイスへの指示(I/O デバイスへの書き込み)、状態の取得(I/O デバイスからの読み込み)、ネットワークからの受信とかディスクへの書き出しといったデータ転送(I/O デバイス→レジスタ→主記憶の転送)といった操作が実現できる。 この章は I/O bound の話なので多少イメージつきやすそう。逆に今までよく掘り下げずに来たなという自戒...

2025-02-03

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 94 ~ 100, pages read: 7

第 6 章 仮想記憶。 仮想記憶のソフトウェア制御は OS の仕事なので(開発者が書く)ソフトウェアで対処できるようなものではない。 それでも TLB ミスはキャッシュミスと共通する点(初期参照ミス・容量性ミス・競合性ミス)があり同じ手法が有効。 仮想記憶にはアドレス変換の他に重大なダメージをもたらすページフォールト(page fault)(disk I/O が発生する)ある。 ここまで来るとソフトウェア的な対策は一定程度可能とはいえ CPU 毎にも異なるからどうしようもない感出てくるな。

2025-02-02

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 91 ~ 94, pages read: 4

第 6 章 仮想記憶。 TLB(Translation Lookaside Buffer)はページテーブルの一部を高速に主記憶から読み込んでおくためのハードウェアで、テーブルウォークの遅さを緩和する。 ページテーブルと TLB は主記憶とキャッシュメモリの関係に近い。 TLB は主に 4KB のページ単位のため、空間局所性が高ければより発生しにくいが、ミスは発生しうる。これを TLB ミス(TLB miss)と呼ぶ。キャッシュミスよりその頻度は低いが、コストはより高い。 TLB ミスの要因やダメージもキャッシュと同様。 ただしフルアソシティブ(full associtive)の TLB はキャッシュは競合性ミスが発生しない。 TLB は流石に初めて聞いた気がする。ここでも緩和のための仕組みがさらなる複雑さを...

2025-02-01

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 87 ~ 90, pages read: 4

第 6 章 仮想記憶。 仮想記憶の中核となるのは、仮想アドレス空間(virtual address space)と物理アドレス空間(physical address space)を対応付けるアドレス変換(address translation)を行う機能。 主記憶よりも大きなメモリがあるように見せかける等メモリの使い勝手を飛躍的に高める。 この対応付けはページテーブル(page table)と呼ばれるデータ構造によって行われ、ページサイズ(page size)の単位で行われる。 主記憶上のページテーブルから変換ルールを読み出すのをテーブルウォーク(table walk)と呼ぶ。 このため本来のアクセスに加えテーブルウォークのため 2 回主記憶にアクセスが必要になり、無駄に長いサイクルがかかる。 この本を読んでると、一難去ってまた一難という感じで次々に課題と緩和策の繰り返しから CPU のありがたみが沁みるよな。

2025-01-31

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 65 ~ 86, pages read: 22

第 5 章 キャッシュメモリ。 主記憶(main memory)である命令メモリとデータメモリを統合したハードウェア DRAM へのアクセスは 10 ~ 100 サイクル程度かかる。これを緩和するために SRAM からなるキャッシュメモリが使われる。 ただし常にキャッシュヒット(cache hit)が起きるわけではなく、キャッシュミス(cache miss)が起きるとその性能は大きく低下する。 キャッシュミスの種類は主に、初期参照ミス(compulsory miss, cold start miss)、容量ミス(capacity miss)、競合性ミス(conflict miss, collision miss)がある(他にもある)。 これらの緩和策として、キャッシュライン(cache ine)・プリフェッチ(prefetch)での先読み、キャッシュの階層化がある。キャッシュ自体の容量増加は現時点では技術的に難しい。 ソフトウェアによる緩和の可能性(空間局所性を高める、配列アクセスは chunk して操作、多次元配列の index は内側から操作)もあるが、容易ではない。 最後にキャシュミスの計測実験。ランダムな分岐条件だと予測がほぼ完全に失敗するが、偏りがあると予測の成功率が上がる例。 情報処理技術者試験では暗記だったが今は何故その構造が必要なのかがわかってきたかな。

2025-01-30

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 57 ~ 64, pages read: 8

第 4 章 分岐命令。 ソフトウェア的にはループ内の分岐をなくしたり、インライン展開でコール・リターン命令を減らして分岐命令の影響を緩和できる。インライン展開は命令数が増えて命令キャッシュを圧迫するデメリットもある。 また多くの CPU では条件分岐命令を減らすために単純な条件実行命令が提供される。 ループアンローリング最適化により分岐命令の実行回数を減らせる可能性もあるが、ループ回数が多いほうが分岐予測の精度は上がるためトレードオフの関係がある。 分岐予測でソフトウェア的にできることはあまりないが、ループ回数の固定や優先度の高い分岐を先に配置するなどの工夫ができる。 最後に予測ミスの計測実験。ランダムな分岐条件だと予測がほぼ完全に失敗するが、偏りがあると予測の成功率が上がる例。

2025-01-29

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 49 ~ 57, pages read: 9

第 4 章 分岐命令。 空きステージを減少させる方法として分岐先の命令を先読みでフェッチする分岐予測(branch prediction)がある。 分岐予測では、分岐命令の存在(過去の分岐命令を保存し命令フェッチ時に判定)、分岐先アドレス(BTB(Branch Target Buffer), BTAC(Branch Target Address Cache), リターンスタック(return stack, return address stack)を使う)、条件分岐命令の分岐方向(branch direction)(BHT(Branch History table), PHT(Pattern History Table), BHB(Branch History Buffer)を使う)を予測する。 分岐予測の成功率は(プログラムや CPU によるが)傾向的に 90% 台中程度で予測ミス(mis-prediction)も発生する。 過去の命令履歴に依存するので新しい命令パターンや、ハードウェア面の制約からテーブルやスタックの容量を超える数の命令やパターンを予測することはできない。 分岐予測とアウトオブオーダー実行の組み合わせで初めて、狭義の投機実行(speculative execution)が実現される。 レイテンシが大きい基本ブロック先頭付近荷配置される命令の実行前倒しができるため、アウトオブオーダー実行を導入する最大の動機といえると。 CPU の中は先読みして実行の試行錯誤の繰り返しみたいなイメージになってきた。

2025-01-28

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 44 ~ 49, pages read: 6

第 4 章 分岐命令。 PC レジスタに分岐先のアドレス(branch target address)を伝えることを分岐命令(branch instruction)という。分岐命令は特権レベルの変更を伴わずに命令流を切り替えることをいう。 これは投機的にフェッチした先行命令をキャンセルするため、パイプライン、スーパースカラ、スーパーパイプライン、アウトオブオーダーの性能を下げる。 失われるサイクルは少なくとも「命令フェッチから命令実行までのステージ数」になる。またハードウェア的にも切り替えによるキャンセル処理が煩雑になる。 文献やベンダによって分岐命令の区分や名前が異なるが、ここでいう分岐命令は無条件分岐命令(unconditional branch instruction)、条件分岐命令(conditional branch instruction)、コール命令(call instruction)/リターン命令(return instruction)(最近の CPU は無条件～のみ実装している)をさす。 この辺は暗記。

2025-01-27

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 38 ~ 44, pages read: 7

第 3 章 データ依存関係。 CPU の仕様書以外にレイテンシ、スーパースカラの同時実行、アウトオブオーダー実行の特性を知るために計測する方法。 CPU のミクロな挙動の計測が難しい点、 CPU の設計次第では特定の命令とレジスタの組み合わせのが速く・遅くなるようなものがある点を踏まえた上で、真のデータ依存関係を作ったアセンブリプログラムで perf コマンドを使って計測し、 cycles と instructions からレイテンシ等の特性を知る。

2025-01-26

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 35 ~ 38, pages read: 4

第 3 章 データ依存関係。 レイテンシが大きい命令を避けるソフトウェア実装の工夫に触れられる。 レイテンシが大きい命令自体の利用を避けるとか、レイテンシが大きい命令を先行させるソフトウェアパイプライニング最適化(software pipelining optimization)、 依存関係のない命令で空きを埋めるループアンローリング最適化(loop unrolling optimization)等。 ここで言うソフトウェアはアセンブリレベルの話で、コンパイラによる最適化が大きいのかな。 高次の言語での四則演算のような演算がそのまま命令に翻訳されるなら、なるべく除算と乗算のようなレイテンシの大きい命令を避けるという工夫はできるが。

2025-01-25

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 27 ~ 35, pages read: 9

第 3 章 データ依存関係。 真のデータ依存関係(後続の命令の読み込みレジスタが先発する命令の書き込みレジスタに依存)、 逆依存関係(後続の命令の書き込みレジスタが先発する命令の読み込みレジスタに依存)、出力依存関係(先発・後続の命令の書き込みレジスタが同じ)、 入力依存関係(先発・後続の命令の読み込みレジスタが同じ)等あるデータ依存関係の中で命令流を滞らせるのが、真のデータ依存関係。 スーパースカラでもスーパーパイプラインでも後続の命令が待たされる。これをペナルティサイクル(penalty cycle)といい、流れを妨げる要因をハザード(hazard)という。 依存関係にない命令を入れ替えるアウトオブオーダー実行(out-of-order execution)で緩和できるが、結果の整合性を保つためには再順序化(reorder)が必要となる。 ただし命令数分の re-order buffer が必要となりそれ以上の実行はできない制約ため実装に関して大きな問題がある。 アウトオブオーダー実行では逆依存関係や出力依存関係も影響を受けるため、依存関係にあるレジスタを解消するためのレジスタリネーム(register renaming)が必要となる。 これも専用のレジスタが必要なため、数が足りなければ実行する命令数を制約することになる。 速度を求めた結果の制約が重いというのがわかってきた。

2025-01-24

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 23 ~ 26, pages read: 4

第 2 章 命令の密度を上げるさまざまな工夫。 スーパースカラは空間方向に流量を、スーパーパイプラインは時間方向に流速を高める。 同時に利用でき CPU の命令の密度を高められるが、投機的な実行には設計の複雑さなどのリスクが伴う。 また同時に処理できる命令は増えるが 1 命令の処理時間は変わらなのが現代の CPU の高速化。 命令の高密度化を更に高めたのがベクトル型スパコンや GPU 。 ここまで命令流が滞らない大前提であり、実際には流れを阻害する要因や回避策がある。 命令自体は速くならないというのはちゃんと理解してなかったかも。 CPU クロックの頭打ちの話か。

2025-01-23

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 17 ~ 22, pages read: 6

第 2 章 命令の密度を上げるさまざまな工夫。 逐次処理方式は安全な実装。比べてパイプライン処理(pipelining)は投機的で、ステージが完了したら次の命令を実行するため、 2 サイクル分速くなる。 代わりに命令のキャンセル処理が煩雑になる。キャンセル処理は CPU のバグの温床。 スーパースカラ(superscalar)方式は、パイプラインを増やして同時に処理する命令を増やす。 スーパーパイプライン(superpipelining)方式は、命令を扱うステージを細かく分けて処理を高速化する(具体的に何段からという定義はない)。 いずれもある種力技で、 CPU 設計の複雑さが増し性能上の制約も出てくるらしい。 いずれの高速化も速さの代わりに失うものがあると。

2025-01-22

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 10 ~ 17, pages read: 8

第 2 章 命令の密度を上げるさまざまな工夫。 現代の CPU は命令流を逐次的に処理する。ハードウェア的には命令流の命令を 3 つのステージに分けて扱う(簡単のため。実際のステージは CPU 毎に異なる)。 命令フェッチ(PC レジスタに従い命令メモリからフェッチ)・命令でコード(フェッチした命令のバイト列をデコード)・命令実行(デコードした命令に従いデータメモリとレジスタ間の読み書きや演算器でレジスタの値を加工、演算で使うデータや値 = オペランド(operand)の読み込み)。 逐次処理方式は単純に命令 1 つの実行が終わってから次の命令を実行するため、 2 ステージ分のサイクルが無駄になる。 ここでいうサイクルは CPU のクロックサイクルで、命令実行に要するサイクルをレイテンシと呼ぶ。 なんかうっすら記憶にあると思ったけど情報処理技術者試験で覚えたやつか。

2025-01-21

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 3 ~ 9, pages read: 7

第 1 章 CPU は如何にしてソフトウェアを高速に実行するか。 現代主流の CPU から見て、ソフトウェアは「小さい命令の流れ」でありその流れが速いほど速く実行できる。 現代の命令セットアーキテクチャと CPU の内部構造(マイクロアーキテクチャ)は分離されてる。 かつては Lisp マシンや Prolog マシンのような CPU もあったが「小さい命令の流れ」を処理する方が汎用性・高速化・小型化に向いていて廃れた。

2025-01-20

魏武注孫子, read count: 1, page: 194 ~ 198, pages read: 5

九地篇 第十一。 「死地で勝つ」自軍を重地へ進めそこを死地とすれば、将兵一体となって戦に集中し実力以上に戦うことができる。曹操はこれを死戦という。 また呪いを禁じ疑惑の念を絶つのは、孫子が合理性を重視していることを示している。 自軍の退路を断つのは冷酷なようだが、迷いなく戦に集中するためには必要なことなんやろうな。

2025-01-19

魏武注孫子, read count: 1, page: 194 ~ 198, pages read: 5

九地篇 第十一。 「軍の統制」敵軍の連携を分断するためには迅速に戦い、敵軍の準備が間に合わないのに乗じて予測しない方法で備えのないところを攻める。 この節は九地と関係がなく見える。敢えて関連付けるなら死地に於いて迅速に戦うための軍政を乱すというところか。 実例として第一次北伐。ただし馬謖が功を焦った敗北によりで作戦は失敗した。

2025-01-18

魏武注孫子, read count: 1, page: 188 ~ 193, pages read: 6

九地篇 第十一。 「九地とは」散地・軽地・争地・交地・衢地・重地・圮地・囲地・死地の説明。 「九地での戦い方」各状況での戦い方を述べる。争地では軍争の、重地では始計篇や作戦篇で述べたような兵糧の略奪をする重要性を説いているようだ。 地形を絡めた自軍の状況に触れているが、圮地・囲地で触れる地形は行軍篇や地形篇で述べたような危険な地形と言葉が違うのがややこしい。 険阻であるとかは共通するが。

2025-01-17

魏武注孫子, read count: 1, page: 186 ~ 187, pages read: 2

九地篇 第十一。 自軍の状況を、散地・軽地・争地・交地・衢地・重地・圮地・囲地・死地の九地があり状況に合わせた戦い方が必要である。 自軍の兵を死地に置き死線させ実力以上に戦わせるのが重要であり、そのために重地に進軍する。 それを為すためには常山の蛇・率然のような連携が必要であり、軍政と九地の理法が重要であるとする。はじめは正、あとで変について。 締めくくりは毎度おなじみ「兵は詭道」の表現を変えた形。 戦わないのを善しとしているし前の篇でも徳について述べてると思うが、この篇は覇道なイメージが強い。

2025-01-16

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: 1 ~ 2, pages read: 2

第 1 章 CPU は如何にしてソフトウェアを高速に実行するか。 この本はヘネパタの定義に沿った CPU 時間が短いほど「CPU の性能」が良いとする。 CPU 時間 = ①実行命令数/プログラム × ②クロックサイクル数/実行命令数 × ③秒数/クロックサイクル数 ① はプログラムやコンパイラや命令セット、 ② は CPU ハードウェア内部構造、 ③ は半導体プロセスや回路 で決まる。 この本は近年は外から見えにくい ② microarchitecture に焦点を当てて、ソフトウェア高速化にどのような効果をもたらすかを知るのが目的。 初っ端からヘネパタ。読後のチャレンジ課題か。

2025-01-15

プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか, read count: 1, page: i ~ xii, 246 ~ 256, pages read: 23

序文と目次と付録 B。 如何に CPU がソフトウェアを実行するのか、ミクロな振る舞いから肌感を養いソフトウェアの高速化につなげるという本。 CPU 命令に馴染みのない人は付録 B を読めとのことなので先に読んでおいた。 CISC, RISC の設計思想の違いが見えたり。 ミクロな振る舞いに着目するから表紙も小人なんか、より糸は thread やったりして。 これまで CPU-bound, Memory-bound, I/O-bound とかの言葉は使ってきたが、そこの解像度が上がるとよいな。

2025-01-14

ピアリング戦記 日本のインターネットを繋ぐ技術者たち, read count: 1, page: 117 ~ 128, pages read: 12

第 5 章 コンテンツ事業者の台頭。 2010 年以降のインターネットの変遷について、モバイルキャリアの NTT ドコモと、ISP の BIGLOBE のインタビュー。 ケータイの時代からスマフォの時代になりインターネットの繋ぎ方を考えないといけなくなった、 社内の事情で depeering した話、ピアリングの時代になりトランジットを販売している ISP の葛藤みたいな話とか。これでこの本は終わり。 話は逸れるが、ちょうど PowerShell Galley の Azure CDN from Edgio からの移行でがここ数日障害ガチャになってたけど、その破産して 2024 NASDAQ 上場廃止した Edgio の前の社名が Limelight Networks だったりする。ここ最近は CDN も大変なんやろか。

2025-01-13

ピアリング戦記 日本のインターネットを繋ぐ技術者たち, read count: 1, page: 109 ~ 116, pages read: 8

第 5 章 コンテンツ事業者の台頭。 2010 年ごろまでに通信キャリアや Tier1 から Hyper Giants と呼ばれるコンテンツ事業者や CDN に移り変わった。特に動画コンテンツによるトラフィックの増加が大きい。 Hyper Giants は多くの AS に private peering し、これにより従来の Tier で階層的だったネットワーク構造が変化した。 peering だけでなく、コンテンツ事業者のキャッシュサーバを AS 内に置くビジネスの駆け引きも行われるようになった。

2025-01-12

ピアリング戦記 日本のインターネットを繋ぐ技術者たち, read count: 1, page: 102 ~ 108, pages read: 7

第 4 章 ピアリング相手の探し方。 ピアリングイベントの話。 GPF(Global Peering Forum) で世界中から IX 関係者が集まって「仲良く」する。 元は欧米のコミュニティの延長だったので日本からホストとして参加するには中々 OK が出なかった。 Peering Asia というアジア圏のイベントもある。いずれも NOG のような技術的なばというよりはビジネス的な交流の場。 実際にネットワークを繋ぐとなると得体のしれない相手よりも知った中の方がというのはなんかわかるかも。

2025-01-11

ピアリング戦記 日本のインターネットを繋ぐ技術者たち, read count: 1, page: 93 ~ 102, pages read: 10

第 4 章 ピアリング相手の探し方。 PeeringDB で探すか、 IX の route サーバに接続するか、コミュニケーションを通じて(コミュニティ等で)探すか。 自力で接続相手を探せない場合は route サーバを利用することで接続相手を探す手間が省けるが、 route サーバだけだと L3 レベルの冗長性がなかったり、 depeering によって接続相手が消える可能性がある。 コミュニティを通じて相手を探す場合、 JANOG を始めとする NOG(Network Operators Group) のイベントや BoF(Birds of a Feather) で相手を探すことになる。 BGP での接続はビジネス色が強いと始めから書かれていたし、前の章でもコミュニティを通じて接続した話もあるので、コミュニティを通じて地道な営業活動をしてないと文字通りネットワークを広げられないということか。

2025-01-10

ピアリング戦記 日本のインターネットを繋ぐ技術者たち, read count: 1, page: 84 ~ 92, pages read: 9

第 3 章 IX とは何か？国ごとに違う IX 。 2012 年頃の peering 状況とコミュニティ活動による IX の変化。 当時は海外から日本につなぎにくかった。海外よりも 10 倍くらい価格が高く、いわゆる JTC らしい重厚なコミュニケーションが必要だった。 海外のようにデータセンター事業者が IX をやってそこに集中して価格が抑えられるとか、 DIY 的な活動や NPO が非営利でやるとかが日本でやりにくかったというのは興味深いな。 文化的なアレのせいか？或いは先に商用で大手が市場を取ってしまってたり、通信事業者として登録しないと IX をやれないあたりが、日本のコミュニティが活動しにくい環境を作ったか。 しかし結果的にJANOG から課題感が出て、 peering-jp や CloudIX 研究会のような事業者同士のコミュニティがつながって改善されていっている(現在進行系)と。

2025-01-09

ピアリング戦記 日本のインターネットを繋ぐ技術者たち, read count: 1, page: 78 ~ 83, pages read: 6

第 3 章 IX とは何か？国ごとに違う IX 。 ソフトバンク系 IX の BBIX の立ち上げ。 JPIX から depeering 後長く低迷。低価格路線を始める 国際ローミングの IX のようなサービス Roaming Peering eXchange を始めた。 RPX ユーザには IX をバンドル提供。後発 IX ながら、すべての接続帯域を合計するとアジア最大の IX になった。 国内に閉じないことで市場が広がったような感じかな。といっても狙ってできるもんでもなかろうが。

2025-01-08

ピアリング戦記 日本のインターネットを繋ぐ技術者たち, read count: 1, page: 71 ~ 77, pages read: 7

第 3 章 IX とは何か？国ごとに違う IX 。 NTT と IIJ が設立に関わった JPNAP の立ち上げ(1997 年)。 分割前の NTT の研究所と IIJ での共同実験がはじまりで、 IX でなくコンテンツを流すネットワークがビジネスだった。 IIJ が transit を売ってい他関係で IX をやりたかった NTT が表向き出来なかった。 しかし JPIX に ISP が集まるのに危機感を持った。また NTT 分割によって NTT コミュニーションズができ国際通信を売り始めた(1999) KDD に国際通信を独占される恐れがあり ISP を集める方法として IX を始めた。 始めの顧客は IX 開始前のコンテンツの顧客。商用 IX としては最初に大阪に設置。当時の大阪はバックアップ用途が多かった。 余談として日本と海外の IX の可用性の違いだとか、現在東京大阪で二極化を緩和するための地方 IX での相互接続とか。

2025-01-07

魏武注孫子, read count: 1, page: 180 ~ 185, pages read: 6

地形篇 第十。 「地形は軍の助け」地形の話に戻る。地形は軍の助けになるのでよく知る者は必ず勝てる。この原則を知り事前に勝てるかを知れば必ずしも君主に従う必要はない。 名声を求めてむや医に進軍せず撤退を恥じず、ただ民と君主のためになる将は国の宝である。 「将と民草」将は兵卒を大切にし愛してこそ共に死地に臨める。ただ愛するだけでなく統率をとれねばならない。 曹操は、恩は威と、賞は罰と共に用いねばならないとする。事例として「泣いて馬謖を斬る」。 「勝利の可能性」自軍と敵軍の状況が攻撃すべき状況を知るだけで地形を知らなければ勝率は半分である。 そのため、敵を知り己を知れば、勝利はようやくあやうくなくなる。天を知り地を知れば、勝利はようやく十全となる。

2025-01-06

ピアリング戦記 日本のインターネットを繋ぐ技術者たち, read count: 1, page: 59 ~ 71, pages read: 13

第 3 章 IX とは何か？国ごとに違う IX 。 日本初の商用 IX JPIX の立ち上げ(1997年)。NSPIXP は学術向けの側面強く、1995 年頃はまだ米国経由の通信が多かった。 当時、KDD は海底ケーブルを所有し、MCI, Level 3, Sprint から transit を購入。米国では IX 黎明期の終焉で Tier 1 同士のみ peering が可能、他は transit 購入が一般的に。 日本では KDD と IRI を中心に大手 ISP から出資を募り、より接続しやすく 24 時間 365 日稼働する IX を目指して設立。ただし NTT と IIJ は出資・接続せず、後に JPNAP を立ち上げる。 中小 ISP を中心に接続を増加。SINET (大学間ネットワーク) も接続。初期は KDD 大手町ビルに設置、後に都内・名古屋・大阪へ分散。 2000年 頃からコンテンツプロバイダも接続し、国内トラフィックが増加。海外からは Chunghwa Telecom, Singtel なども参加。 JPIX 以前に香港テレコム・ Dacom(LG の前身)・ Singtel ・ Telstra ・ KDD の 5 社にチャイナテレコムを加えてピアリングするグループがあった。 海の真ん中までケーブルを持ち寄って接続する形態だったが 2000 年代には米国の IX 黎明期の終焉のような強者の理論でチャイナテレコムが離脱しなくなった。 フェアな互助関係じゃないと難しいがビジネス観点での思惑が渦巻いてたんやな。

2025-01-05

魏武注孫子, read count: 1, page: 177 ~ 179, pages read: 3

地形篇 第十。 「六種の敗因」軍の六種の敗因がある。いずれも将の能力不足による。 敵の戦力を測らず敵わなくて「走る」(逃走)・軍吏が弱く兵卒を統率できず統制が取れず「弛む」・ 軍吏が強くとも兵卒が弱く進撃について来れず危険に「陥る」・ 小将が大将に怒られ心服せず独断で戦い大将は小将の怒りに任せ敵を測れず軍勢が「崩れる」・ 将が弱く軍吏と兵卒の状態がなく布陣が不統一で軍規が「乱れる」・ 将が敵を測れず弱兵で強兵を攻め敗北する「北げる」。

2025-01-04

ピアリング戦記 日本のインターネットを繋ぐ技術者たち, read count: 1, page: 47 ~ 58, pages read: 12

第 3 章 IX とは何か？国ごとに違う IX 。 日本最初の IX である NSPIXP の立ち上げ。 NSPIXP は学術系の IX で 1994 年に WIDE プロジェクトが神保町岩波書店一ツ橋ビルに NSPIXP を設置。 NSPIXP 以前には AT&T Jens, IIJ の IX が ISP をやっていた。当時 ISP 同士の接続は電話網同士の接続で、郵政大臣認可が必要だった。 NSPIXP はインターネットのみのため認可を受けたことはない。開始当初は ISP 事業者に影響が出ないよう帯域制限をかけていた。 開始当初は BGP3 での接続だったが、後に NSPIXP-2 を KDD 大手町ビルに設置。 BGP4 に移行。 学術系 IX として実験的な取り組みをする側面もある。 地理的に分散した IX(大阪、福島の IDC と港町の OMP)、 IPv6 のプレイグラウンド(NSPIXP-6)、 DNS の M-root サーバ(世界に 13 ある root サーバのうちの 1 つ)等。

2025-01-03

ピアリング戦記 日本のインターネットを繋ぐ技術者たち, read count: 1, page: 46 ~ 47, pages read: 2

第 3 章 IX とは何か？国ごとに違う IX 。 日本の IX の最大手は JPIX(1997 年～ KDDI)、JPNAP(2001 年～ NTT)、BBIX(2003 年～ソフトバンク) がある。 株主に大手キャリアが含まれ、 transit と peering の両方を提供している点が、海外では珍しい形態で日本の IX は特徴である。 Equinix の IX も利用されており、学術系で WIDE プロジェクトが運営する NSPIXP 、地域 IX がある。 WIDE プロジェクトが 1994 年に神保町で NSPIXP を始めるまでは transit を海外から購入していた。

2025-01-02

ピアリング戦記 日本のインターネットを繋ぐ技術者たち, read count: 1, page: 40 ~ 46, pages read: 7

第 3 章 IX とは何か？国ごとに違う IX 。 IX(Internet eXchange)は AS が BGP ルータを持ち寄って接続し合う場。商用 IX もあれば学術用 IX もある。 IX サービス事業者を IXP(Internet eXchange Provider)と呼ぶ。 日本では、最初に誕生した学術研究用 IX NSPIXP 、商用 IX 大手 JPIX, JPNAP, BBIX がある。 商用 IX は場を提供することで収益を得る。物理的なポートの帯域で月額固定料金を請求するポート課金が一般的。 IX は場を提供するだけで実際に接続し合うのは AS 間の契約により、 peering だけでなく transit での接続もある。 IX が提供するルートサーバに接続することで複数の AS と接続できる環境もある。 IX での接続を public peering と呼び、 IX を介さずに接続することを private peering , PNI(Private Network Interconnect), dynamic peering と呼ぶ。 public peering の場合複数の AS のトラフィックが 1 本の回線に集中する可能性があるが、多数の AS と接続する手間やコスト面でのメリットがある。 IX は国や政治的背景によって在り方に違いがある。合法的傍受(Lawful Intercept)の対応や、 MSK-IX(Moscow Internet eXchange) は Sovereign Internet という規制の元でインターネットからの切り離せる仕組みが強制されている。 IX が設置される場所は国それぞれだが技術的・運用的・政策的課題はどこも共通しており、 IX 事業者連合会で情報交換されている。

2025-01-01

ピアリング戦記 日本のインターネットを繋ぐ技術者たち, read count: 1, page: 25 ~ 39, pages read: 15

第 2 章 データセンターとその立地。 BGP ルータの設置場所としてよく使われるデータセンター。 構内配線での相互接続をクロスコネクトという。同一 DC 内ならクロスコネクトだけで BGP ピアを確立できる。 BGP ルータ同士をピアにする時は同一の L2 セグメントに配置する。 L2 セグメントを仮想的に統合する技術(L2 延伸)もあるが一般的にはクロスコネクトが利用される。 原理的には別のルータを介して BGP を利用することも可能で、その特殊な方法は BGP マルチホップと呼ばれる。 この経緯から、 DC に IX 、ISP(Tier1)、大手通信キャリア・コンテンツ事業者が入居する DC は価値が高く集中しがちで、コスト面でも優位なことが多い。 日本ではそれが東京一極集中の理由になっていた。 しかし 2013 年の東日本大震災で海底ケーブルが切れてギリギリだったのもあって以降、 BCP 的な観点から大阪でピアリングする数も増えた。 利用者が増えて新たな DC もでき、大手キャリアが大阪にも進出したことで更に利用者が増えた。 また堂島問題(構内配線の煩雑さ、 4 つのビルが 1 拠点に見えるややこしさ、 1 ビルのダークファイバ利用の審議)の解消も活況に一役買った。