ハードウェア構築言語 Chisel がアツい（かもしれない）

いきなりタイトルと関係なさそうな話題からスタートしますが、今週1番のトピックは、なんと言ってもEdge TPUがオフィシャルに発売されたことでしょう。
しかもUSB接続のアクセラレータがたった80ドル弱ですよ。日本だとMouserで8800円ほど。

こいつをいち早く入手できたIdein社内でのお試し結果がこちら。

Edge TPU(USB版)
Mobilenet v2 1.0 224x224 ImageNet
Raspberry Pi 3 Model B v1.2
で10msちょっとでした pic.twitter.com/BOfSAgUewJ

— Koichi Nakamura (@9_ties) 2019年3月5日

10msってことはあと6ms程度別の処理に充てても高精度カメラのフレームレート60fpsに間に合っちゃうってことで、これはくそっ速い。
僕は去年夏にEdge TPUがアナウンスされたときから、これが世に出回った時点でAIチップ戦争は終結するかなって思ってたんですが、本当にそうなりそう。変な欠陥でも見つからない限り。ヤバイ。

で、昨日あたり更にびっくりしたのは、このEdge TPUがChiselという言語で設計された、というのを知ってからでした。
以下がその話をしている動画（英語）。

www.youtube.com

Chiselについては今まで

• RISC-V界隈で流行っているらしい
• ディープラーニングコンパイラTVM専用のISAであるVTAをChiselで実装するプロジェクトが始まったらしい

くらいを聞きかじった程度で、言語の中身もよく知らず興味もそんなに湧いてこなかったんです。
が、実製品に適用されてしかも出来がよさそうだ、となると、やはり俄然興味が湧いてきます。

ということで、調べてみました。
……と言っても一晩でそんなに沢山調べられるはずもなく、ひとまず

• DAC'12 で発表された論文
• GitHubにあるChisel3のWiki

あたりをざっくり読みました。以下自分なりのChiselの特徴まとめ。

ハードウェア構築言語である

Chisel は自身をハードウェア構築言語（Hardware Construction Language）と名乗っています。そもそもこれが聞き慣れない用語。
よく知られているのはVHDLやVerilog HDLなどのハードウェア記述言語（Hardware Description Language, HDL）で、ちょっと詳しい人ならSystemC（や既に消え去ったSpecC）なんかの俗に言う高位設計言語くらいかなと思うわけですが、これらと何が違うのか。

自分のもやっとした理解を誤解を恐れず端的に言うと、RTLそのものの抽象度を上げた言語なのかな、という感じです。
RTL（Register-Transfer Level）とは、つまりレジスタや演算器モジュールとその間の接続のデータフローを記述するレベルです。これまでのHDLはこの抽象度で書かれる想定をしていました。
で、これでは抽象度が低く生産性が低いため、SystemCなどはビヘイビアレベル、つまり回路の振る舞いをソフトウェアライクな抽象度で書けるようになっています。

ただ、HDLにしろSystemCにしろ、RTLがあって、その上にビヘイビアレベルがある、という観念に則っていました。これは長らくハードウェア業界の常識だったわけです。

しかし、Chiselはその常識に則っておらず、RTLを書くけどRTLそのものの抽象度が上がっているというノリに見えます。

Scalaの組込みDSLである

で、その抽象度を上げる要因となっているのが、このChiselがScalaの組込みDSLとして実現されている点。

Scalaとは2000年代に登場した言語で、ものすっごくざっくりした説明をするならJavaを関数型言語のフレーバーで書けるようにしたプログラミング言語、というノリのものです。
で、Chiselはこいつの組込みDSL、つまりScala内に埋め込まれたハードウェア設計特化言語なわけです。
言語を組込みDSLとして設計する意図は言語によって様々ですが、Chiselの場合はScalaというモダンなプログラミング言語の機能をフル活用してハードウェアが書けるというのが狙いであるように見えます。

考えてみるに、VHDLはAdaという古いプログラミング言語が元になっており、VerilogはそこにCやPascalのフレーバーをかぶせたもの。要するにベースとなっている言語が古いわけです。
で、ハードウェアがこういうベースの古い言語でずっとやってきた傍らで、ソフトウェアの言語は抽象度が上がり、型システムなんかもかなり整備されて、少ない記述量で高度な記述ができるようになっていました。
なので、ベースの言語をモダンなものに置き換えればそれだけで生産性は随分上がる、ということは確かに言えるかも。もちろん口でいうほど簡単なことではないんですが。

Chiselの機能

上でも述べたように、Chiselで記述するものの大枠はデジタル回路のRTLです。 しかし、中に記述されるモジュールが （オブジェクト指向的な）オブジェクトであり、関数でもあります。なのでソフトウェア的に高い抽象度でモジュールを書き下せるっぽい。
オブジェクト指向的なオブジェクトなので継承も使えるし、さらにジェネリクスも使えます。一部にはトレイトも使われています。こういう最近の言語に備わっている多相性がハードウェアの記述に使えます。
あと随所に型推論を使えるので煩雑な記述をかなりの部分省略できます。
今時のプログラミング言語を知ってる人には随分書きやすい言語だろうなと思います。基本ソフトウェアエンジニアの会社であるGoogleで採用されたのもむべなるかな、という気がします。

Chiselの短所

なるほど良さそうだな、というChiselの個人的印象なんですが、一方で上で紹介した動画ではChiselの短所も述べられていました。
いくつかあったけど個人的に印象に残ったのは以下の2つ。

学習コストが高い

動画では、Chiselの学習は

1. ChiselでのRTLの書き方を覚えるフェーズ
2. Scalaに習熟するフェーズ
3. Chiselをツールとして使いこなすフェーズ

の3段階ある、と言っていて、しかもほとんどのハードウェアエンジニアは1の段階を超えられないという話。確かにそうかもしれない。

検証がクソムズい

らしい。 Googleの検証エンジニアがだいぶ死んでたようです。
これはまだChiselが未成熟なせいなのかな、という気もするんですけど、Chiselが吐き出すSystemVerilog記述がChiselのソースとうまく対応付けられず、低レベルのRTL記述が検証と非常に相性が悪い、など。チップ設計の検証をするにはまだまだ物足りないところが多いようです。

[追記] この記事読んで「検証できないんじゃ使い物にならん」みたいな反応をしている人がちょいちょいいるので補足しておきますと、Edge TPUチームの動画ではChiselの長所として「ソフトウェア的な単体テストが非常に有効だった」という話を述べています。独立した検証エンジニアの手によるチップ全体への検証が難しい代わりにこうしたソフトウェア的なテスト手法で検証を補っていた（補えた）ということなのかもしれません。[追記終わり]

結論

まぁそういう短所はありつつも、少数精鋭のチームが生産性を上げたいならChiselはいい言語だろうなという印象。きちんと使いこなせる人が使えばVerilogなんかで書くよりも全然楽チンかもしれないですね。

MSのエルゴノミックマウスを強力にオススメする話

はじめに書きますが、この記事は思い切りダイレクトマーケティングかもしれません。
別に僕はMSの回し者ではないし当然利害関係もないですけど、本日はMicrosoft Sculpt Ergonomic Mouseを強力にプッシュしたい。

マイクロソフト ワイヤレス マウス 人間工学 高精細読み取りセンサー Sculpt Ergonomic Mouse (ブルートラック) L6V-00013

週末の深夜テンションで何か急に書きたくなった。許してほしい。

こいつを買った経緯（自分語り）

※ ここから、こいつを使い始めるいきさつを長々と語るので、面倒なら次のセクションまで飛んで下さい。

まぁ僕はもともと、キーボードに関しては熱烈なMS信者でして、確か一度肘が腱鞘炎になりかけたときに会社の上司に無理言って↓このエルゴノミックキーボードを買ってもらって、それ以来仕事ではずっとこれを愛用してました。

マイクロソフト キーボード 有線/人間工学デザイン Natrual Ergonomic Keyboard 4000 B2M-00029

マイナーチェンジしてて型番がちょい新しくなってますが、僕が入手したのはもっと古いやつです。ただほぼ同じ形のはず。
1台は使い潰して、買い直してまでこれ使ってましたね。

一方、自宅のデスクトップ環境はワイヤレスキーボードのほうが都合よかったので、Microsoft Wireless Comfort Keyboard 1.0a ってやつを使ってたんですよ。もう廃番っぽいやつで現在は新品どこにも売ってなさそうですが、こんなやつ。

Microsoft Wireless Comfort Keyboard & Mouse 1.0a

といってもプライベートでのメインマシンはずっとサブノートPCだったので、これはそんなにヘビーに使ってなかったんですよね。

ところが、会社辞めてフリーになって、自宅でがっつり作業する機会が増えたんです。
当時は（今も）メインのノートPCとしてMacBook Proの2017年モデルを使ってて、大変お気に入りなんですがキーボードだけはクソで、やっぱちゃんとしたキーボードを使って作業したいと。

で、↑のワイヤレスキーボード＆マウス使ってデスクトップで仕事のコーディングとかし始めたんですが、1日で右手首が腱鞘炎になりました。
最初何が起こったのかわからなかったんですけども、よくよく考えたらこれはマウスのせいだと。
長らくMacBookのトラックパッドで作業しててマウスはほとんど使ってなかったところ、久々にちゃんとマウス使ったら小指を上げる方向にひねるような持ち方に手首が耐えられなかったみたいです。

ということで、キーボードごと新しいマウスを買いました。

マイクロソフト キーボード マウスセット ワイヤレス/セキュリティ(暗号化機能搭載) Sculpt Ergonomic Desktop AES L5V-00030

そしたら腱鞘炎が一瞬で治まった。嘘松じゃなくほんとに。

こいつの何がそんなにいいのか（使用感などを語る）

割と最近のエルゴノミックマウスに共通してるっぽいですが、手首を変にひねらないのですごい楽。
外観これなんですが、 こういうふうに握る。 角度を変えるとこうなる。 手首が自然に傾いてるのがわかりますかね。この傾きと握り具合がすごく心地いいんですよ。
結構重めで、ボールを上から鷲掴みにする感じで握ります。

なお、僕は普通のマウス操作をしてるときはこうではなく、こんな感じ。 この握り方が、僕の手のサイズだとちょうどいいですね。本当に野球ボールか何かをただ握ってるだけの感覚。

ただ、上の方の正規の？握り方にも実は意味があって、この親指がちょうど当たるところにブラウザの戻るボタンがあって、これが地味に超便利なんですよ。 ↑これの水色のWindowsボタンではなく、その脇にもう一個横向きにボタンがあるんです。
ブラウザバックするときにいちいち画面の左上にマウスカーソル持っていく必要なくて、リンククリックしてざっとスクロールして前の画面に戻る、ってのをほとんど手を動かすことなく指先だけで動作が完了するんです。
Webブラウザでググったりしてるときにこれがくっそ楽。
なお、僕は普段の開発はUbuntuでやってますが、この機能はUbuntuでも動きます*1。

ということで（まとめ）

これ本気でいいマウスで、一度使うと普通のマウス使えなくなります。
普段の作業で手首疲れるとか痛いとか思ってる人は試してみるといいかもよ。

*1:水色のWindowsボタンの方はそのままではUbuntu18.04では機能しないです。Xevで見てると認識はしてるようだし、設定ちゃんとすれば動きそうですがそこまでは試しておらず。

就職したよ ＆ ディープラーニングコンパイラについてお話したよ

新年あけました（←笑いどころ）
ええと、前回書いたのが10月初旬で、それから4ヶ月も開いたのか……
以降の僕の簡単な動静：

• L社を辞めてフリーになった
• 兼務で国立情報学研究所（NII）のポストを得た
• 今月からフリーを辞めてIdeinに就職した

って感じでドタバタしていてブログもSNSも全然手に付きませんでした。

そんなところで先般 fpgax #11 ＋ TFUG ハード部 なる勉強会があり、こちらで『DNNコンパイラの歩みと最近の動向 〜TVMを中心に〜』というタイトルでお話してきました。

fpgax.connpass.com

内容的には、最近出てきた "Deep learning コンパイラ" ってどんなものなのか、ざっくりと僕なりに概要をまとめたものです。
こちらで資料も見れます。

DNNコンパイラの歩みと最近の動向 〜TVMを中心に〜 from Takeo Imai

www.slideshare.net

あと当日の映像。僕の登場は 2:09:50 あたりから。

fpgax #11 ＋ TFUG ハード部：DNN専用ハードについて語る会

以上、生存報告でした。

日経xTECH記事『デジタル活用を阻む「PoC貧乏」〜』について

日経xTECHに、次のような記事が載っています*1。

tech.nikkeibp.co.jp

この記事、冒頭から

PoC（ポック）貧乏──。講演者の1人が使った言葉が聴衆の笑いを誘った。あるAI（人工知能）関連イベントでの出来事だ。

という一文で始まっています。

で、読み進めていただくとわかるんですが……この「AI関連イベント」、明らかに、私が関わっている 日本ソフトウェア科学会 機械学習工学研究会（MLSE）が5月に開催した、研究会発足記念のキックオフシンポジウムのことで、「講演者の1人」は、アクセンチュアUSAの工藤卓哉さんです。
下記アーカイブ動画の16:44あたりからご覧になれば、記事になっている話がそのまま講演で語られていることがわかります。その辺りで出てくる「丸山先生」は、MLSE運営委員の一人である丸山宏さん（現：Preferred Networks フェロー）です。

基調講演１「ソフトウェア工学における問題提起と機械学習の新たなあり方」工藤卓哉【機械学習工学研究会 キックオフシンポジウム2018】

それで、この「AI関連イベント」がMLSEキックオフシンポジウムであることを前提として書くのですが、当記事には何点か誤りがあると思いますので、このエントリーで指摘しておきたいと思います。
その指摘とは以下です。

1. PoC貧乏 という言葉の意味が違います
2. そもそも、PoC という言葉の意味が違います
3. MLSEのイベントは「AI関連イベント」ではありません

この3点の詳細を、以降で順を追って説明します。

PoC貧乏 という言葉の意味が違います

記事では、工藤さんの講演内容の紹介を、以下のように締めくくっています。

PoCをいくら実施しても、その先が続かない。ベンダーに対価を支払って支援を仰ぐのであれば、リターンを得るどころかお金が出ていくばかり。これがPoC貧乏の実態だ。

これは工藤さんの指す「PoC貧乏」とは意味合いが全く異なります。工藤さんや我々がいう「PoC貧乏」とは発注者側でなく、受注するベンダーが損をする現象のことです。

機械学習プロジェクトにおいて、PoCでは成果が約束できないので、成果報酬でなく、準委任契約に基づく時間報酬で、小規模に行うことが多いです。
これはベンダーにとってあまり利益を生むものではなく、ベンダーはその後の本番システムの構築まで進めて初めて大きな利益を得るのですが、PoC段階で終わってしまうと期待した利益が得られません。この現象を「PoC貧乏」と呼んでいます。

そもそも、PoC という言葉の意味が違います

記事では、PoCについて次のように解説されています。

PoCはProof of Concept（概念検証）の略で、通常は「ピーオーシー」と呼ぶ。新しい技術やアイデアを活用して期待する効果が得られるか、どんな課題があるかなどを確認する作業を指す。

この説明自体は大枠では正しいと思いますが、記事タイトルにもありますように、記事では「デジタル活用」、いわゆる社内のデジタルトランスフォーメーション（DX）におけるPoCの話と、MLSEで扱っている機械学習プロジェクトでのPoCとを混同して用いられているようです。
DXにおけるPoCは、例えばベイカレント・コンサルティング社のサイトなどが参考になるかと思います。社内全体に展開する前に、まずは小規模な試行で効果を確認する行為をPoCと呼びます。

一方、機械学習プロジェクトにおけるPoCは少し特殊な意味合いがあります。機械学習プロジェクトにおけるPoCは、機械学習モデルの訓練（学習）を試みるフェーズのことです。
機械学習プロジェクトの難しいところは、モデルが目的のシステム構築に見合う精度・性能に達するか、達するまでいつまでかかるか最初に見積もれないことです。ですので、ひとまずPoCとして、訓練データを揃えられるだけ揃えて、機械学習エンジニアがモデルの訓練を試みます。
一度の訓練で目標精度に達することは少なく、機械学習エンジニアが様々な改良を加えながら訓練を何度も繰り返します。こうした作業が、機械学習プロジェクトにおけるPoCです。
PoCを経て十分な精度・性能が得られるとわかったモデルを使い*2、初めて実際のシステム構築に着手します。システム構築に踏み切る前に機械学習モジュールだけを先に仮組みするのが、機械学習プロジェクトでのPoCです。全社展開する前に一部の部署でトライアルする、というDXでのPoCとは、意味合いが全く異なります。

MLSEのイベントは「AI関連イベント」ではありません

最後に、これは個人的に不快感を覚えた点ですが、そもそもMLSEでは「AI」を扱っていません。
これについてはMLSEサイトのQ&Aにありますので、少し長いですがそのまま引用します。

Q. 人工知能、AIという言葉を使わないのはなぜですか？ この研究会では現在よく世間で問われている「AIをいかに業務で使いこなすか？」という問いに対し、対象を機械学習に限定しているだけのように見えます。

現在、機械学習は人工知能（AI, Artificial Intelligence）と抱き合わせで議論されることが多いです。

これまで「AI」という用語は、その時代時代で別個の技術を指していました。初期のAI研究では論理プログラムや探索アルゴリズム、1980年代の第2次AIブームではルールベースのエキスパートシステムなどが「AI」と称されました。現在の第3次AIブームで、これに相当するのがディープラーニングを含めた統計的機械学習です。

しかし、これまでのAIと機械学習が典型的に違うのは、これまでのAIが演繹的アプローチ（汎用的なルールを人間が与え、そのルールに従って推論する手法）であるのに対し、機械学習は帰納的アプローチ（個別のデータを人間が与えて、機械に汎用的なルールを獲得させる手法）である点です。従来のAIが演繹的であるという点では普通のプログラミング、一般的なソフトウェア開発と特段に変わるところはないのですが、機械学習は全く違う方法でプログラミングをするものだといえます。

ですので工学的視点から見ると、今までのシステム開発手法はそのまま適用できないことがあり、新たな工学としての体系化を行う必要があるのです。これが、MLSEでは「人工知能」「AI」でなく「機械学習」にこだわる理由です。

またAIの宿命として、技術が成熟すると、その技術は世間ではAIとは呼ばれなくなります。機械学習も遠くない将来、AIとは呼ばれなくなると予想されます。しかし，その場合でも機械学習自体は重要なシステム開発技術の一つとして残るでしょう。

AIであるか如何に関わらず、機械学習のための工学研究はこれから地道に取り組んでいく必要があります。ですのでMLSEでは、人工知能ではなく、統計的機械学習を中心に扱います。

「MLSEではAIを扱わない」ことは、キックオフシンポジウムでも何度か述べられていたことです。にも関わらず、MLSEの主催イベントであることを伏せた上で、敢えて「AI関連イベント」と呼称する行為には、遺憾というほかありません。

*1:このアイキャッチ画像に写っている方は記事後半で取材されている平鍋健児さんで、記者とは別人です。念のため。

*2:モデルの再訓練を行う場合も往々にしてありますが、この場合も、使用アルゴリズムや、深層学習の場合はネットワーク、またハイパーパラメータの類はPoCで最終的に用いたものから変更しません。

Leaving LeapMind

Note: This is an English translation of this post.

I guess someone knows and others don't, but anyway, I will leave LeapMind in the middle of next month.

It was the beginning of the last Oct when I joined the company. Since then, I have spent around one year, but it was quite a fulfilling year. I had a thrilling and supreme experience as an engineer, through the challenge in the cutting-edge area of deep learning compiler development, which is what only a few people can enjoy in the world.
There is a full of appreciation for all members of LeapMind. I would like to thank to all of them.

And then, I will be a freelance engineer from around Oct 20th.
But I won't be a permanent freelancer. I'm planning to spend several months to do various things including job hunting, and eventually, hopefully, I would transfer to another company.
Actually, there are many things I have wanted to do so much but failed due to lack of time. I may do some of them during the freelance period.

I want to add a note about MLSE (the special interest group of Machine Learning Systems Engineering). I will keep active as a steering member. We also spent around one year from when we started the activity as a voluntary group, and have gained huge supports from many people, much more than expected, through the year. This is worthwhile, I believe. That makes me more enthusiastic to boost the movement until "the machine learning systems engineering" becomes a true academic discipline.

So anyway, my title and affiliation will change, but I will come through and hit it up. Thanks!

LeapMindを退職します

感づいている人もいない人もいるでしょうが、来月の中旬あたりでLeapMindを退職します。

去年の10月頭からお世話になったので、ちょうど丸々1年といったところですが、大変充実した1年を過ごさせてもらいました。 ディープラーニング用コンパイラ開発という、世界でもなかなか得ることのできない貴重な経験を通じて、常に世界の最先端で勝負し続けるという、スリリングで、エンジニアとしては最高な体験をさせてもらえました。
LMの皆さんには感謝しかありません。本当にありがとうございました。

10/20付近から、フリーランスエンジニアとなります。
といっても今後一生フリーで食っていくつもりはなく、色々なことをしながら数ヶ月かけてゆっくり転職活動をし、最終的にはどこかの会社にお世話になるのでは、と思います。
LMにいて、この世界で凄くやりたかったけど、時間を作れずになかなかできなかったこともいっぱいあります。この間にやってみようかな、などと思っています。

なお、機械学習工学研究会（MLSE）の活動については今までどおり継続します。こちらも有志が集まっての活動開始からちょうど1年くらいなのですが、僕らの当初の想像を遥かに上回る形で皆さんの支持を得ることができ、すごく手応えを感じています。 機械学習工学が本当の学問分野となるまで盛り上げていこうと思います。

そんなところで、まぁ肩書？所属？は変わりますが、ガンバって生きていこうと思います。

p.s. 俗に言う内幕暴露な「退職ブログ」を期待された方、すみません。Twitterにちょろっと挨拶を書くだけのつもりが長くなりそうだったので、ブログに書いただけでした。

Facebookのバグ自動修正ツール "SapFix" とは何ぞや？

前回の記事↓で国内ソフトウェア工学事情を勢いに任せて書いたら思いのほか炎じょ……バズってしまい、しかも身内のソフトウェア工学の先生方に火をつけまくってしまいまして、いやはや。関係者の皆様すみませんでした*1。
フォローの記事も書こうと思ってたんですが、少々タイミングを逸してしまった感。でも少し誤解を与えたところもあるんで、また時間ができれば書こうかと思います。 bonotake.hatenablog.com

しかし、それから一週間くらい経ちまして、今度はソフトウェア工学に関わる人間としてはなかなか嬉しいニュースが。
それで、つい以下のようなツイートをしたところ、これも軽く話題になってるようで、今もまだ通知が止まらない感じです。

automatic repair、ついに来たか
これはガチで近年のソフトウェア工学の成果

Facebook、バグを自動で修正する新ツール「SapFix」開発 https://t.co/X0D6Xidmj1 via @cnet_japan

— takeo (@bonotake) 2018年9月14日

バグの自動修正（automatic repair）はここ数年ソフトウェア工学の国際会議ではかなり盛り上がってる研究トピックです。
これをFacebookがツール化した、というので、やはりこの分野の人間としては大変気になるところ。話題としてもキャッチーですしね。
しかも、この開発リーダーを務めたMark HarmanのFacebookへの投稿を読むと、

I am really delighted and also very proud that we are, today, announcing the first industrial-strength scaled-up automated program repair, now in continuous integration and deployment at Facebook.

とあって、社内の開発フローにさっそく組み込まれた模様。
ちなみにこの Mark Harman、ソフトウェア工学の世界ではプログラム解析の大御所として著名な研究者で、UCL（ロンドン大学）の教授でありながら、最近はFacebookの Engineering Manager （エンジニアの統括マネージャー？）を務めています。

research.fb.com

こういったあたり、海外のソフトウェア工学分野は産学が上手く結びついてるんだなぁ、というのを感じさせますねぇ。

で、そのMark Harmanが陣頭指揮を取って開発した自動バグ修正ツール "SapFix" なんですが、Facebookのブログに簡単な解説記事があります。
code.fb.com

ということで、この記事では残り、このブログ記事を元に、SapFix がどんなツールなのかを簡単に解説していきます。
ちなみにざっと読んだところ、実はそんなに凄いことはしていません。

Androidアプリを対象に、まず自動テストツール "Sapienz"を使って自動テストをかけます。なおこのSapienzも、search-based testing という、最近研究が盛んな技術を元にMark Harmanの研究室で開発された自動テストツールなんですが詳細は省略。ご興味ある方は（＋論文読める方は）以下の論文をば。

• Mao, K., Harman, M., & Jia, Y. (n.d.). Sapienz: Multi-objective Automated Testing for Android Applications. In Proc. of ISSTA'16

で、このテストでクラッシュが観測されるとSapFixが稼働するわけですが、その内容とは

1. 過去の修正から人手で作った修正パッチのテンプレートを、そのまま持ってくるか、あるいはそれがハマらなければミューテーションを使ってテンプレートを変形してパッチを作成。
2. 上で出来上がったパッチを元に、さらに複数のパッチを生成。
3. 生成したパッチがコンパイルを通るようなら、さらに開発者が人手で書いたテストとSapienzで生成したテストを流して、このパッチでもうクラッシュが起こらないか＋別のクラッシュが発生しないかチェック。
4. チェックを通ったパッチは人間がレビューして、良さそうならそのパッチを適用。

なお1. で使われてるミューテーションっていうのは、文法に従ってプログラムを適当に（'+' を '-' にしたり、変数名を入れ替えたり）書き換える……というもので、元々はわざとバグを埋め込んでテストがそれを見つけられるかを診る、テストを評価するために生まれた技術なんですが、早い話、要はデタラメに書き換えてるだけです。

いかがでしょう。ぶっちゃけ全然凄いことしてません*2。むしろ「えっ、これでホントにバグ直るの？？」ってレベルです。

ただ、個人的には結構感心しました。まぁこれが実用上使いものになるかどうかはこれからの評価を待たないといけなさそうですが、これで本当に使えるんならすごいなと。
automatic repair には例えばプログラムの意味まで踏み込んで理解し、バグの内容をちゃんと解析した上で然るべき修正パッチを生成する、なんて手法も研究されてます。で、第一線の研究者が開発に携わってるんで、そういうアプローチも知らない訳はないと思うんです。
でもそういうの敢えて使わずに、簡単な解析だけど軽くて実用のソースコードのサイズに耐えうる技術を使ってるんじゃないですかね、これ。 そういう、研究者の独りよがりでない「現場で使えればいいじゃん」っていう割り切りが凄いなと。

あとはこう言ったら言葉が悪いですが、こんな簡単な解析＋自動修正を「数撃ちゃ当たる」的にやっても効果が出ちゃうほど、現場ではしょうもないバグが頻発してるってことなんだと思います。
これも勝手な推測なんですけど、FacebookみたいなDevOpsベースの企業では超短期開発でひたすらアップデートをかけ続けてるはずで、開発＋リリース前テストに手間隙かけるよりは、実装はなるたけ簡素に済ませて、CI使って物量でバグを短期間に潰す、ってスタイルを採ってるのかな、と想像します。それならこの手法でも十分効果あるんではないかと。

ということで、最新鋭の技術とかを駆使してるわけでもなければ、理論的に凄い技術も使ってない、でも自らの開発現場に見合った、実用上もっとも効果がある技術を採用しているってことなのかな、と思った次第。
それでも実際の開発フローに組み込めるまで持っていくあたり、相当な作り込みをしてるんじゃないかな、とは想像しますが。これで本当に効果あったらすごいですね。

先のブログ記事によると、もうちょい手を入れた後でこのSapFix（と、テストツールSapienz）はオープンソースにする予定だそうで、ぜひ、中身を覗いてみたいです。

p.s. ……と、この記事をちょうど今書き終わろうかってところで、当の Mark Harman からFBで友達申請が来ましたｗ びっくりしたー。ツイート見られちゃいましたかね。

追記） 一晩明けてちょい読み返して思ったんですが……全体的にものすごく簡単な技術で構成してるのは事実だと思うんですが、絶対どこか一工夫は入れてると思います。特に怪しいのはパッチを複数作成するところ。脚注には元々書いてますけど。
ここは多分論文書いてどこかに投稿中なんで、まだ明かせないんだと思います。もしその論文が入手できたら補足記事を書きます。

*1:悪びれずに書くと、それなりの問題提起はできたんじゃないかと思ってます。ただあまり本質的でない、余計なところでご迷惑をかけた方面がいくつかあったようで、その点は大変申し訳なかったのでした。

*2:ただ、2. の手順でどう複数のパッチを生成してるか、元のブログには書いてません。おそらくここらへんがこのツールのミソで、詳しくは論文になるまでわからないかも。