bonotakeの日記

元・ソフトウェア工学系研究者、今・AI系エンジニア

情報幾何わかった気になった

注:情報幾何の内容に触れるものではなく、ただの今の僕の心境を綴っただけのエントリーです。あしからず。

タイトルは半分誇張です。本当にわかったわけではないですが、かなり理解が進みました。
きっかけは、色々ぐぐってこの解説論文に出会ったからです。

arxiv.org

元々下記の本で情報幾何は勉強しかけていたり勉強会に顔を出し始めたりしていたのですが、仕事の合間に自習する時間がなかなか取れず、モヤモヤとしていたのです。いい本だと思うんですけどね、2冊とも。

情報幾何学の基礎 (数理情報科学シリーズ)

情報幾何学の基礎 (数理情報科学シリーズ)

微分幾何 (応用数学基礎講座)

微分幾何 (応用数学基礎講座)

GWに時間が取れたので休みのうちに勉強したいと思っていたところ、本文が実質30ページ強の程よい長さの入門が出てきたので、丁度良いと。
結局、4節の応用のセクション除いて一通り読みました。4節も読み切る時間と心の余裕が取れてなかっただけなので、このあと読もうと思います。

もちろん、この30ページがさらさらと読めるわけもなく、実際はわからないことだらけな訳ですが……ただ最近、僕が数学書を読むときわざと試していることが、幅優先で理解していくというものです。
数学書って本来、どアタマから読んで、わからない箇所が出てくれば他の文献を当たって手を動かして考えて……とやるのが王道だと思うんですが、これ、無限に時間のある学生ならOKなんですけど、それなりに仕事抱えてる社会人がやるとまず最初の導入の章読み終わるだけで余裕で1ヶ月以上かかったりするんですよ。本論にたどり着く前に半年以上かかったり。

なので最近は、敢えて

  • 一番面白そうなところから読む
  • わからないことがあってもとりあえず置いといて読む

というのを心がけています。深堀りするよりまず全体のイメージをつかむことから始めて、わからないことは後で泥縄式に調べていくという方法。
画像の描画を1ドットずつ精緻に描くのではなく、モザイクだらけでもいいから全体をまず描いて、そのあとモザイク内の各タイルを詳細化していく感じ。
英文の長文読解するときに、わからない単語が出てくるごとに辞書引くのは禁忌で、わからないならわからないなりに読み流していくというのがセオリーですが、それと同じです。

ということで、他に記事を書いたりもしつつ(この詳細はいずれ)、4日くらいかけて冒頭の解説論文をだいたい読み終わりました。
情報幾何がどういう構成でどういうことをやろうとしているのか、かなり雰囲気がつかめました。統計多様体とか情報多様体とかがどういうものかもなんとなくわかったし。
というか、解説論文が非常によくまとまっていたのでかなりわかりやすかったです。

ああそうだ、上の解説論文読む前にこの動画見たんだった。


【のんびり解説】統計多様体の超入門!【情報幾何】 #VRアカデミア #005

この動画もすごく分かりやすかったので、しょっぱなのしょっぱなに観るのオススメ。
(ただし、ここで解説されてる多様体は統計多様体という名称のものそのものではない気がします。)

そんで、先の解説論文の further reading なところに以下の本がオススメされてて、Amazonのなか見検索でPrefaceとか目次とか読む限り確かに次に読む本として良さそうだったんで、さっくりポチってしまいました。

Geometric Modeling in Probability and Statistics (English Edition)

Geometric Modeling in Probability and Statistics (English Edition)

これも次にどれだけ読む時間割けるかわからないんですが、ぜひ暇を見つけて読みたいなと思っています。

2019年GWにやったこと

今年のGWは10連休だっただけに留まらず、珍しく何かに追い立てられたり体調崩していなかったり*1したので、大変充実した休みを過ごせました。
ということで、GWにやったことをここに記す。

【おしながき】

幕張メッセに行った

2日ほど。何しに行ったかはお察し。

リビングに散らかり倒していた私物を片付けた

一方で自分が作業用にしている部屋は散らかりっぱなしである。

椅子を買った

自宅で仕事するときに使ってる椅子が古い木の椅子で固く、ずっと座ってると腰とかお尻とか痛くなってぐったりするので、一念発起してまともなオフィスチェアを買いました。家具屋さんに2日通いました。
在庫の関係で配送は再来週。

記事を書いた

某雑誌向けに書きました。論文ではなく一般の読み物です。
ディープラーニングに対するエッセイというか考察というかポジショントークというか、そんなもの。詳細が決まったら明らかにします。

情報幾何をわかった気になった

以下を参照。 bonotake.hatenablog.com

微分可能プログラミングの由来を調べた

Differentiable programming, 別名可微分プログラミング。Yann LeCunが発祥だと思っている人が多いのだけども、そうではありません。
これも後日別エントリーにまとめたい。

ガンダムOOを1〜13話一気に観た

でも途中気を失っていたので後で一部見直す。

*1:直前まで不眠症を拗らせていたのですが、お薬で軽快しました。

『「コルーチン」とは何だったのか?』の裏話的な何か、とPythonコルーチン

いきなりですが、n月刊ラムダノートが創刊されました。めでたい。

www.lambdanote.com

で、この中にある @mametter さん執筆の記事『「コルーチン」とは何だったのか?』に僕はがっつり関わっていました。 後述しますが、僕と彼とのオンラインでのやり取りの中で記事が書き始められ、方針が決まっていった感じです。
なので、出版を記念してそのへんの経緯を振り返り、また僕なりの感想をまとめようかと思います。

……と思ったんですが、改めてやりとりのログを見返してたんですがアホほど膨大な量になっていて、とても全部振り返るのは無理だと悟りました。 なのでざっくりと。
当該の記事と一緒に読まれることを想定していますので、その記事で語られていることの説明はある程度省いています。 数時間前に @mametter さんが草稿を公開↓したので、そちらを読んでくれても構いません(できれば買ってほしいけど)。

mametter.hatenablog.com

目次:

経緯

きっかけ

去る2018年11月17日、仕事でPythonコードを書いていた僕が、ついasyncioパッケージ周りでコードを上手く書けないモヤモヤを夜になんとなく愚痴りました。
その中に、async/await で記述されたものを「コルーチン」*1 と呼んでいるらしい、なんかおかしい、という話をちょろっと入れたのです。

翌日の11月18日、僕の愚痴からアヤシイ匂いを敏感に感じ取った @mametter さんが思いをTwitterでぶっぱして、無事炎j……バズります。
外がいい感じで燃え盛る中、僕や @mametter さんがPythonコルーチンに感じ取った違和感はいったい何なのかを探る長い旅がスタートします。

コルーチンとは何かを探る旅

外がいい感じに炎……盛り上がっているさなか、最初に僕らの間で始まったのは、コルーチンが一番最初に活字にて著されたConwayの1968年の論文の読み会でした。
そこから23日までの5日間、とにかく色んな物を調べまくりました。思いつく限り列挙すると、

その他もろもろ。

そいつらを読みながら、コルーチンの定義とその変遷の様子に関してああでもないこうでもないと2人で延々議論していました。 同時に、Pythonコルーチンを使って対称コルーチンを再現してみたりもしていました。(この結果は省略。そのうち紹介するかも。)
そんな感じで、自分たちがなんとなく「これがコルーチンだ」と思っていたものを、適宜事実と照らし合わせて修正、更新、あるいは補強していく作業でした。 70年代以前の論文を短い期間にたくさん読んだのも初めてで、自分たちがしていることをある時期から2人の間で「考古学」と呼ぶようになるのですが、実際、考古学というのはこういう学問なんだろうなと思った次第。

執筆が始まる

19日に入って、裏側で延々と議論していた内容を反映して、 @mametter さんが今回の記事の草稿に当たるものを書き始めます。   当初は自分のブログに書くためのもので、もっと簡素だったし、ツイートだと書ききれない @mametter さんのポジショントークというか意思表明というかそういうノリのもので、なので @mametter さんの主張が色濃く残っていました。

23日頃を境に一旦その執筆の手は止まり、2人の間で多少話題になったり、PPL*2でなにかの形で発表しようか? などという検討をしたりはしていたものの、特段の進捗はなくそのまましばらく記事は放置されます。

 そして出版へ

年が明けて2019年の1月下旬、@mametter さんが書き溜めてあった草稿をラムダノート社長の @golden_lucky さんに見せたところ好評を得たようで、@golden_lucky さんが以前から構想していた雑誌に載せる方向で話が進んだようです(このへんは僕は直接会話に立ち入ってないのでわからない)。そこで記事の執筆も再開されます。

で、再開早々僕が主張したことは、記事の中で「何がコルーチンか/コルーチンでないか」という断定を避けた方がいい、ということでした。
上述の通り元々は @mametter さんのポジショントークだったので当然そのへんは @mametter さんなりの意見が含まれていたのですが、そこを結論として持ってくるより、むしろ僕らが調べた事実に基づいて「コルーチンの定義が揺らいでいる/変遷している」ということだけを述べ、それ以上の判断は読者に委ねたほうがいいと考えました。   結果として記事もそういう方向に軌道修正されたし、実際そうすることでいろんな立場の人がニュートラルに読める内容になり、記事の価値は上がったのではないかと個人的には思っています。

所感

ここからは、完全に僕個人の雑感です。

今回色々見てまず感じたことは、最近の言語は並列・並行にまつわる概念がごっちゃになっているということですかね。 ファイバーコルーチン軽量スレッドfuture / promise あたりがごちゃ混ぜになってできているように感じます。 実際のところ、このへんを全部区別できる人がどれだけいるんでしょう?

1980年時のコルーチンの定義 と Pythonコルーチン

ということで、記事では最終的に「これがコルーチンだ」という断定は避ける形になりました。  ただ、 記事には載せられていないのですが、実は Marlinが「コルーチンが満たすべき基礎的性質(fundamental characteristics)」というものを書いています (Marlin’80)。 それがこれ。

  • the values of data local to a coroutine persist between successive occasions on which enter it (that is, between successive calls)
    (コルーチン内にローカルに存在する値は連続する “call” の間で保持される)

  • the execution of a coroutine is suspended as control leaves it, only to carry on where it left off when control re-enters the coroutine at some later stage.
    (コルーチンの実行は制御が離れたら停止し、その後のどこかでコルーチンに再入したときに制御の離れた箇所から再開する)

カッコ内は僕が今適当に訳しました。明らかな誤訳でなければ微妙なところは見逃して。  

これが記事に使われなかったのは、この定義もまた微妙な問題を孕んでいたからです。   どこらへんの解釈かというと “call” です。純粋に考えればコルーチン間の呼び出し/被呼び出しのことでしょう。 つまり、コルーチン間の非同期な呼び出しがあることが前提なんです。

ところが、ここにPythonコルーチンを持ってくると、解釈がとてもややこしくなります。
Pythonコルーチンって、他のコルーチンへの呼び出しで非同期的な中断するわけじゃないんですよね。 呼び出しで非同期的な中断をするのは、呼び出し先のコルーチンか、そいつが呼び出すさらに先のコルーチンか、その先か……がsleepするときだけなんですよ。
呼び出し=中断の合図ではないんです。

でも、Marlinがこれを著したときにあったのは、対称コルーチンと非対称コルーチンだけでした。 この2つは他のコルーチンを呼び出すことで非同期的な中断をする仕組みで、呼び出し=中断 なんです。 だからPythonコルーチンはこのMarlinの定義がそのまま当てはまるわけじゃないです。

てか、Pythonコルーチンってぶっちゃけコルーチンというより、仕組みとしてはスレッドに近いんですよね。 sleepで寝て、寝てる間は一緒に動いてる他のスレッドのどれかに制御が移る。sleepが解ければスケジューラによってそのうち制御をもらって処理を再開する。
これ、スレッドなんですよ。
これにfutureの仕組みを足したものがPythonコルーチンの正体だな、と。

ではPythonコルーチンはコルーチンではないのか

ただ、ある想定を置くことで、旧来のコルーチンを使ったモデルと考えられなくもないんです。 それは、スケジューラ(Pythonコルーチンでいうイベントループ)を特別なコルーチンと考えることです。
なのでPythonコルーチンのコンテクストスイッチ(敢えてスレッド用語を使う)は、イベントループがコルーチンを呼び出すことでそのコルーチンが処理を再開する。
sleepすることでイベントループに処理を戻す。
イベントループがresumeして、コルーチンがsleepのタイミングでyieldする非対称コルーチンってことです。

これは、Dahl et al. が大昔に書いている手法で、また、Crystalのファイバーがこういうモデルを採用してたはず。
(僕が他の言語も調べた中で、Pythonコルーチンに一番似てるなと思ったのはCrystalのファイバーでした。)

このモデルを前提に、イベントループ/スケジューラによるコンテクストスイッチを先のMarlinの定義で言う”call”とみなしていいか、という点で 僕と @mametter さんで解釈が分かれて、最終的にこの定義は使えないという話になったのです。

結局何がいいたいのか

過去の論文や他の言語の仕様も調べまくって色々考えましたが、結局Pythonコルーチンって、個人的にはあまりコルーチンとは呼びたくないんですね、やっぱり。軽量スレッドと呼びたい何かです。
それが悪いというわけではないんですが、ただコルーチンとしてみるとかなり貧弱な機能しかないので、不便です。 中断する際に他のコルーチンを呼び出して、そいつに値を渡すとかできないですからね。
さっきCrystalのファイバーが似てると書きましたが、Crystalは他のファイバーとの非同期な通信機構があります。 Pythonコルーチンにはない。コルーチン間の非同期通信はfutureでやるんです。

Pythonコルーチンは一般的なコルーチンと思うとツラくて、むしろfutureを使った非同期モデルを指向してコードを書くべきなんでしょう。 積極的にfutureオブジェクトを使いまわしていくのがいいのかな、というのが今ん所のPythonコルーチンに対する僕の所感です。

*1:実際にはそれまでジェネレータベースのコルーチンはPythonに存在していましたが、それと表面上は別のものとして native coroutine という名称で導入されました

*2:https://jssst-ppl.org/workshop/2019/

兵庫県警ブラクラ摘発の何が恐怖なのか

兵庫県警によるブラクラ摘発が話題になってもう3週間ほどになるんでしょうか。

最初は中学生がこの件で「補導」(触法少年として刑法犯扱い)された事が話題になりましたけども、その後、僕は同時に摘発された男性に関する以下の記事が出て「これは本当にマズイ」と感じるようになりました。
そして、この件で僕が感じているこのザワザワした感情が 恐怖 なんだ、という認識に至りました。

nlab.itmedia.co.jp

以下、僕がこの件で何を恐怖と感じているかを書きます。
書いてあることは他でも言われていることの何番煎じかわからないものですが、あくまで僕自身の所信表明ということで。

目次:

1. ブラクラをウィルスと同列のものとして扱っている

上に挙げた記事を読む限り、兵庫県警はウィルスとブラクラの区別がつかないのではなく、むしろ区別して扱い、しかしブラクラも不正指令電磁的記録に関する罪に該当すると判断した、ということのようです。

ネットを利用する多くの人は理解していることですが、ブラクラが猛威を振るったのは2000年代前半まで。以降はブラウザが対策してほとんど何の被害も及ぼさなくなりました。ここ10年ほど、僕はブラクラの類に出くわしたことは1度もないです。
今は子どものいたずらレベルのジョークプログラムしか基本できないし、実際に今回対象になったのも子どものいたずらレベルのチャチなもの。これのリンクを貼るだけの行為を3年以下の懲役又は50万円以下の罰金に相当する犯罪として摘発する、と警察が判断したのがまず恐ろしいのです。
実際、兵庫県警は取材に「いたずらだったことは重々承知しているが、現行法では懲役、もしくは罰金刑になる犯罪」と回答したようですがそんなわけあるか。
兵庫県警は勘違いしているみたいですが、この法律は元々実害の大きいコンピュータウィルスを対象に作成されたものです。 量刑も当然そこに合わせての設定です。
厳密にはウィルスではないが同様に害の大きいマルウェアも対象にできる、ようにはしていますが、誰もジョークプログラムをウィルスと同列に扱う必要があるなんて思っていません。警察以外は。

2. ループの本質を警察が理解していない

上記の記事から、摘発されたAさんの回想による刑事とのやり取りが掲載されていますが、

Aさん:あの……僕の貼り付けたURLがそのブラクラで、そのURLをクリックした誰かのPCが壊れたんですか?

女性刑事:いや、今回のはOKボタンをクリックするとポップアップがずっと消えずに永遠と表示され続けるループスクリプトなんだけどね。

Aさん:……ポップアップがどんな物なのかは想像付くんですけど、ループスクリプトって何なんですか?

女性刑事:まぁ簡単に言えば同じ動作を繰り返すプログラムだってことだけ理解しておいて。OKボタンを押す度にそのポップアップを何度も何度も表示させるのが今回のループスクリプトなんだよね。

ブラクラ」の一種として「ループスクリプト」があり、その「ループスクリプト」とは「同じ動作を繰り返すプログラム」だと定義しています。

この記事で、プログラマやITエンジニアが一番恐怖を感じたのはここではなかったでしょうか。僕は心底ゾッとしました。 同じ動作を繰り返すプログラムをウィルスと同等とみなして刑法の罪に問うということですから。

いや、当初からみんなこれを問題にしていたのであって、はむかずさんの「みんなで逮捕されようプロジェクト」もここの無茶苦茶っぷりを揶揄したものなんですけども、ここが兵庫県警を含む、コンピュータに疎い多くの人達に伝わってないのではないでしょうか。
恐らく警察は問題を理解してないので、このプロジェクトもただの警察への挑発としてしか受け取れていないのでは、という気がします。取材でも「自分の子どもにもそんなことが言えるのか」なんて相当頓珍漢な回答をしていますし。

プログラミングを知らない人に端的に説明すると、兵庫県警の言う「ループスクリプト」は、誰でもプログラミングをすれば絶対に書いてしまうものなんです。 それをウィルスと同様に摘発するということは、プログラミングするすべての人が摘発の対象になるということです。

以下、もう少し詳しく説明します。完全にプログラミングを知らない人向けです。

ループはプログラムに欠かせないもの

僕は情報工学科に進学した大学1年の最初に、プログラムの基本構成要素は順次、分岐、繰り返しの3つだと教わりました。今だと同じことは高校の情報の授業なんかでも教えてるかもしれません(カリキュラム知らないのでわかりませんが)。 順次は、並べた命令を順番に実行すること。分岐は、条件判断をして、判断に応じて処理を変更すること。そして繰り返しが、同じ動作を繰り返すことです。
つまりループ(繰り返し)はプログラムの中の本質的な構成要素であり、ループなしではコンピュータの機能をほとんど活かせないことになります。

どれだけループが本質的なものか。今は自動運転の開発が盛んですが、例えばアクセルの自動プログラムを作るとなったら、たいていこんな感じになるんじゃないでしょうか。

運転している間ずっと
    もし加速する必要があったら
        アクセルを強める
    もし減速する必要があったら
        アクセルを弱める
    それ以外
        アクセルはそのまま
という処理を繰り返す

つまり「アクセルを調節する」を運転中ずっと繰り返す、と書くわけです。
人間でも、運転中ずっとアクセルを調節するという行為を繰り返しているのでは。コンピュータのプログラムだって同じで、これを書けないとまともなプログラムになりません。

止まらないループは簡単にできあがる

あともう1つ、プログラミングに詳しくない人がピンとこないのでは、と思うのが、ループが止まるか止まらないかは簡単には判断できないことです。
難しい話をするなら、どんなループに対しても止まるかどうかを判断できる、という一般的な方法はないことが理論的に証明されています(チューリング機械の停止性問題の決定不能性)。 ただ、そんな小難しい話を知らなくても、プログラミングをそれなりにやったことがあればうっかり無限ループするプログラムを書いてしまって困ったという体験をした人は多いのではないでしょうか。
僕自身、もう情報科学の専門教育を受けてから20年以上経ちますが、つい先日も作成中のプログラムが止まらなくなってキーも受け付けなくなって、コンピュータを強制終了したばっかりです。 ループが意に反して止まらないのはいつでも起こり得ることなんです。

まとめると

以上の2つを踏まえて今の状況を例えるなら、しょっぱい料理を他人に出したら傷害罪として摘発されるようになった、という事ではないでしょうか。
塩や醤油は料理に欠かせない調味料で、一生無縁な料理人は恐らく存在しないでしょう。しかし、塩のさじ加減を間違えたら摘発するぞ、と警察が日本国民に宣言したのです。 こんな状況下に置かれれば、世の料理人はみな震え上がるのではないでしょうか。
しかし現に今、そういう状況下にITエンジニアが置かれているのです。めちゃめちゃ怖いし、文句の一つも言いたくなるのが分かってもらえるでしょうか。

なお、法務省の解説 によれば、バグはこの罪に問われないことになっています。 しかし意図的に作ったものや、バグを突いて悪用した場合はこの限りでないそうで。上の議論も併せて考えれば、意図的かどうかの境目はとても曖昧です。
さらに言えば、以下の点で法務省の解説レベルだと警察は簡単に無視するようで、何の気休めにもならないのです。

3. 故意犯の要件を満たしていないのでは

この点、僕は法律に関しては素人なので間違っていたらスイマセン。

最初に挙げた記事の中で、Aさんは別のジョークサイト(怖い画像が出てきてビックリさせるもの)へのリンクを貼ったつもりが、間違って問題のループスクリプトへのリンクを貼ったと述べています。 つまり、Aさんがループスクリプトを貼ったのは間違い(過失)であって、この時点でAさんは故意犯ではなくなっているように思います。
この罪は本来故意犯でないと適用できないもののはずです。 先に挙げた法務省の解説でも、「その時点において,それが不正指令電磁的記録であることを認識していなければ,同供用罪は成立しない。」としています。

にもかかわらず、兵庫県警の刑事は本人に罪を認めさせようと話を進め、最後には

チーフ男性刑事:(間違って貼ったリンク先が)PC内部のデータが破損やデリートされたり、個人情報を抜き出す悪質なウイルスだった場合のこと、考えてみろよ。

(カッコ内は筆者)

と、まったく架空の話で、しかも仮にそれが成立してもこの罪は適用できない例を出してAさんに罪を認めさせています。メチャクチャじゃないです?

まとめ:僕らはずっと声を挙げ続けないといけないのではないか

僕は基本小市民で、日常生活では割と警察に対して協力的です。好感こそあれど悪感情なんて普段は持っていません。
でもこれはダメだ。敢えていいますが兵庫県警の対応は様々なレベルで間違いを犯しているし、彼らがやったことは日本国民に対する脅威であって、認められません。
コンピュータに関わることを生業にしている僕にとっては生存権の侵害だとすら感じます。

反社会的な行為に出るつもりは更々ありませんが、彼らの暴走を止めるためには、脅威を感じた僕らはずっと声を挙げ続けないといけないのではないでしょうか。

[追記] 昨日から日本ハッカー協会が、摘発されたうち2人の弁護士費用を工面すべく募金活動を始めました。

www.hacker.or.jp

僕も募金しましたが、もし僕と同じくこの事件を脅威に感じている人は、ぜひ募金して下さい。
協会のページにも書かれているのですが、

今回のアラートループの事案がこのまま正式裁判で争われることなく略式命令が確定してしまうと、過去の有罪事例として「実績」となってしまい、他の地方警察や検察の判断にも影響し、次々と際限なく不正指令電磁的記録の対象が拡大されていってしまう事態になりかねません。

ということで、他人事ではありません。この事件で摘発された人達の罪を確定させれば、次に苦しむのは僕らです。

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

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

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

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

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

www.youtube.com

Chiselについては今まで

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

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

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

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

Chisel は自身をハードウェア構築言語(Hardware Construction Language)と名乗っています。そもそもこれが聞き慣れない用語。
よく知られているのはVHDLVerilog 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を強力にプッシュしたい。

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

こいつを買った経緯(自分語り)

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

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

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

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

f:id:bonotake:20190217043026j:plain
Microsoft Wireless Comfort Keyboard & Mouse 1.0a

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

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

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

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

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

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

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

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

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

ということで(まとめ)

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

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

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

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

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

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

fpgax.connpass.com

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

www.slideshare.net

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


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

以上、生存報告でした。

注:bonotakeは、amazon.co.jpを宣伝しリンクすることによってサイトが紹介料を獲得できる手段を提供することを目的に設定されたアフィリエイト宣伝プログラムである、 Amazonアソシエイト・プログラムの参加者です。