blog.8-p.info

New York Times の Trump Had One Last Story to Sell. The Wall Street Journal Wouldn’t Buy It. を読んでいたら

This fall, top media and tech executives were bracing to refight the last war — a foreign-backed hack-and-leak operation like WikiLeaks seeking to influence the election’s outcome.

WikiLeaks って今はそういう評価なんだっけ? そういえば Snowden とか WikiLeaks とか、あのあたりについてちゃんと知らないなあ、と思って『暴露―スノーデンが私に託したファイル―』『全貌ウィキリークス』『Au　オードリー・タン　天才IT相７つの顔』と立て続けに読んだ。

暴露―スノーデンが私に託したファイル―

Edward Snowden の NSA に関するリークを、それを受けとったジャーナリスト Glenn Greenwald の視点から書いた本。山形浩生の スノーデン関連書紹介 (2019) では

グリーンウォルドはその後、自分で独立メディア The Interceptをたちあげ、スノーデンのファイルを小出しにするとともに、各種の調査ジャーナリズムを実践している。

と書かれているけれど、著者は2020年のアメリカ大統領選の最中に、編集方針の違いを理由に The Intercept を離脱している。

今回に取りあげる3冊の中では、人の生い立ちではなくひとつの事件を追うという性格が強く、スノーデン自身についてはあまり掘り下げられない。また、著者はマスメディアにだいぶ批判的で、私の中には、日本のメディアよりアメリカのメディアはちゃんとしていて、フェイクニュースといっている人々のほうが危うい、という気持ちがあったのだけど、そういう単純な話でもないんだなと反省した。

全貌ウィキリークス

Julian Assange, WikiLeaks のその周辺について、子供時代から追った本。著者の Marcel Rosenbach と Holger Stark‬ はいずれもドイツの週刊誌 Der Spiegel の人々で、それもあってか Glenn Greenwald のようなマスメディア批判はあまりない。

とっているリスクとは不釣り合いにスキの多い Julian Assange と、無編集に提供された情報を公開するだけという当初のかたちから、だんだんと編集を入れたジャーナリズムに流れていく WikiLeaks の姿は、見ているとだいぶ心配になる。

Au　オードリー・タン　天才IT相７つの顔

Audrey Tang について子供時代から追った本。著者の Cheng Chung Lan は nippon.com のスタッフライターで、Iris Chu も nippon.com にプロフィールがある。翻訳のようで実は日本語書き下ろし。

Audrey Tang の、知り合いの家を泊まり歩くような、ハッカー的な華々しさと自由さは Julian Assange にだいぶ似ているし、ひまわり学生運動での中立に情報の流通を促進する立場は、WikiLeaks 的だと思う。でもここから彼女は政府に登用されて中の人になる。

Audrey Tang の話は、本人の人間的な魅力にひきづられるのか、ヒーロー待望論になりがちで、私はそれは良くない (システムで解決したい) と思うんだけど、その点でいうと本書は、台湾のコロナウィルス対策について、中国起因の WHO との不仲、SARS 対策の失敗と、台湾 CDC の設立といった文脈を抑えた解説があって良かった。

友達のやっている Misreading Chat というポッドキャストで、From Laptop to Lambda: Outsourcing Everyday Jobs to Thousands of Transient Functional Containers について話してきました。録音された自分の声を聞くのは慣れないけれど、好きなポッドキャストなので出れてよかった!

以下、収録中にうまく説明できなかったり、調べたりなかった部分の補足です。

全体の流れ

GitHub の README.md にも貼られている、ffmpeg をコンパイルするスクリーンキャスト がわかりやすい。

• gg init で .gg/ ディレクトリを作る。
• gg infer make とすると、gcc などを、環境変数 PATH を書き換えることで gg のものに置き換えた環境で、make を実行する。
  • gg infer が対応していれば¹、任意のコマンドが実行できます。
• この時点でローカルに make を実行したときとおなじように ffmpeg という実行ファイルができる。
  • でも、これらは #!/usr/bin/env gg-force-run というのがついたシェルスクリプトで、本当の実行結果ではない。
  • この時点で gg IR で出来た “thunk” と呼ばれるファイルも、ローカルに作られます。
• ここで gg force ffmpeg --jobs 2000 --engine lambda などとすると
  • まずは thunk をクラウドにアップロードして
  • force サブコマンドの引数になっている ffmpeg の thunk をクラウド上で評価して
  • それに必要な thunk も再起的に評価されていって
  • 最終的に本物の ffmpeg がクラウド上で作られて
• それがクラウドからダウンロードされて、ローカルの ffmpeg が本物に入れ替わる

という動作をしています。UI がちょっと凝っていて、実行中に、計算にかかる金銭的なコストが下に出る²のがかわいいですね。

並列数は?

これは 5. Evaluation のところに記載があって、

• コンパイル: Chromium の場合 8,000 (5.2.3)
• ユニットテスト: 8,000 (5.3)
• 動画エンコーディング: 記載なし
• 物体認識: 記載なし

となっています。ちなみに、Lambda 自体の並列数は、デフォルトで 1,000 だけど、申請すれば “hundreds of thousands” まであげられます。

自分のプログラムを gg で動かすのって大変なの?

gg のレポジトリの中に、フィボナッチ数を計算する例があるけれど、これを見ると大体雰囲気がわかると思う。

ここでは、add と fib という二つの実行ファイルを作って、それを gg で実行している。

add のほうはファイルから数字を二つ読み込んで、それを足すだけのプログラムで、特に面白いところはない。

fib のほうは gg の SDK を使っていて、fib(n-1) を計算する thunk と、fib(n-2) を計算する thunk を作って、それを前述の add に渡す、という動作をしている。ここで、個々の thunk から再起的にまた thunk が作られていくんだけど、その再帰的に thunk を作る部分がクラウドで実行されていて、ローカルで計算に必要なグラフを作りきらなくてもいいのが、gg の見所のひとつだと思う。

この実行ファイルの切れ目が、そのまま分散して実行されるときの単位になる、というパラダイムにのれれば、自分のプログラムを gg で動かすことはできると思う。

日本でデジタル庁ができるというので、Digital government units: what are they, and what do they mean for digital era public management renewal? を読んだ。

著者は、イギリスの Government Digital Service (GDS) やアメリカの United States Digital Service (USDS) などの Digital Government Unit (DGU) について、共通点、差異、今後の課題などを論じている。Abstract に

This article kickstarts a much-needed research agenda on this emerging trend, which has to date largely been ignored by public management scholars.

とあるように「研究者のみなさん、こういう研究課題がありますよ」という方向で書かれているけれど、部外者が読んでも面白い。

個人的には、共通点の、例えば「ウォーターフォールではなくアジャイルを!」みたいなことをいいがちというあたりには関心を引かれなくて、差異のほうが興味深かった。例えば GDS はトップダウンで、

To pass point 17 (report performance data) in your service assessments you must set up a dashboard on the Performance Platform. You must show how you’re using the dashboard to share metrics for the following 4 key performance indicators (KPIs): user satisfaction, cost per transaction, completion rate, digital take-up

(強調論文筆者)

なんていえるけれど、USDS は

While they’re not a requirement, if an agency doesn’t already have an established style guide, the draft U.S. Web Design Standards can help save time, money, and effort

(強調論文筆者)

と控えめである。著者は後者を “diffuse leadership model” と呼んでいて、アメリカの 18f, カナダの Canadian Digital Service や Ontario Digital Service がこのモデルをとっているらしい。

また、組織内の改革事業みたいなものが、こういうふうに第三者に比較検討されることって、私企業つとめかつマネージメント業ではない私にはあまり機会がなく、そこも新鮮だった。

例えば GDS のトップダウンなアプローチについて

They think they’re doing God’s work, and the atmosphere around it is a bit up itself. I think the difficulty is that for people who are still doing digital in the departments, who aren’t in this sort of golden team, those people who are doing very difficult jobs and are very good at what they do, and in lots of cases much better than some of these people doing jobs centrally, they are being told that they’re rubbish and that they’ve been doing it wrong all these years.

なんて不満までインタビューされているのは、なんというか、こういう軋轢ってどこでもありますよね。

あわせて読みたい: デジタルガバメントに関する諸外国における先進事例の実態調査

NTT データ経営研究所のデジタル庁については、日本国内の経緯や前例についてはよくまとまっているけれど、海外の前例への言及が全くなくて、ちょっと拍子抜けした。

同研究所のものだと、令和元年度経済産業省デジタルプラットフォーム構築事業（デジタルガバメントに関する諸外国における先進事例の実態調査）報告書 (PDF) はすごい。

314ページの PDF を、おそらく PowerPoint で、文字ぎっしりのスライドとして作るという手法には文化の違いを感じるけれど、アメリカ、イギリス、エストニア、シンガポール、中国、インド、デンマーク、韓国の8カ国について、法制度・規制から調達方法まで、5項目について比較がされていて読み応えがある。というか、ありすぎて、通して読めてはいない。

最近のKazuyoshi Katoのブログがなかなか良い

でも最近のKazuyoshiブログは技術的な事も私的な事もいろいろ投稿されつつ、個々のポストが不必要に完成されていないというか、 良い意味でブログらしさが出ていて、読んでいて面白い。

褒められた! ありがとうございます。

英語のほうを頻繁に書いているのは #100DaysToOffload 効果です。

一方で、karino2 さんが以前に書かれていた、ブログの時代がふたたび到来！？ (2017) とか、ブログを書き続ける能力 (2019) とかにも影響を受けているので、それが褒められているのは一周まわってきた感じがしますね。

Archive ページにその月の記事数を表示

ただ、いま見てたら blog.8-p.info では記事の文字数も表示されるようになっていた。 blog.8-p.info の過去記事ページは非常に参考になる。

また褒められた! ありがとうございます。

最近さらに手を入れて棒グラフもつけてみました。ここら辺にこるのは、森井さんの 過去記事ページの UI 考察 (2020) にも影響を受けているので、これも一周まわってますね。

記事にタグをつけるのは、昔はてなブックマークを使っていたときに「本文中に “Perl” って入っているものに perl ってタグを付けるのは人間の仕事ではないのでは!」と突然気づいて以来やめていたんですが、#100DaysToOffload でタグをつけろとあったので、また手でつけています。そういう経緯なので、日本語の方にはあんまりついていないという。

The Morning Paper も Misreading Chat も再開してめでたいので、PLDI 2010 ¹ の Evaluating the Accuracy of Java Profilers を読んだ。

著者らは、Xprof, Hprof, JProfiler, YourKit の4つの Java プロファイラについて、プロファイル結果の正確さを比較している。結論からいうと、それぞれのプロファイラの結果は正確さに欠き、さらにプロファイラごとの結果もバラバラ、という残念な話だった。

まず、これらのプロファイラは全て JVM から直接情報をもらっていて、JVM は “yield points” と呼ばれる箇所に到達しないと情報を返さないため、

We determined that all four profilers take samples only at yield points. More specifically, when a profiler wishes to take a sample, it waits for the program’s execution to reach a yield point.

Yield points are a mechanism for supporting quasi-preemptive thread scheduling; they are program locations where it is “safe” to run a garbage collector (e.g., all the GC tables are in a consistent state).

サンプリングがランダムにならない。

さらに、プロファイラを読み込んでメモリの配置が変わったり、プロファイラがバックグランドスレッドを起動したり、それらがまた yield points に影響してしまうことで、プロファイラごとの結果もバラバラになってしまうらしい。

正しいプロファイルをとるには

また、著者らは実験として、JVM の外側で動く tprof というプロファイラを開発して、実際にベンチマーク二つを高速化している。

JVM の外からプロファイルするべき、というのはまあまあ自明で、Brendan Gregg ² も、Java CPU Sampling Using hprof (2014) で

The runnable state issue and yield-based sampling could both be fixed at the same time, by profiling from the system. The best example was developed by Sun: the jstack() action for DTrace, which can sample Java stack traces based on the kernel’s understanding of running CPUs, and using reliable system timers.

と書いている。いまの Linux だったら BPF で出来るはず。

他のランタイムの厚い言語はどうなのか?

こういうのって Go とかにもあるのかなあと調べてみたら、Go のほうは、Proposal: hardware performance counters for CPU profiling という提案がされていた。

The Go pprof CPU profiles are quite inaccurate and imprecise due to several limitations related to the operating system (OS) interval timer used as its sampling engine.

JVM でいう yield points に当たるものは存在しないのか、それ以前にまずサンプリングレートをなんとかしたいという話なのかはよくわからず。知っている人がいたら教えてください。