Booklog 2025

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 ビルのダークファイバ利用の審議)の解消も活況に一役買った。