bonotakeの日記

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

『「コルーチン」とは何だったのか?』の裏話的な何か、と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専用ハードについて語る会

以上、生存報告でした。

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

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

tech.nikkeibp.co.jp

この記事、冒頭から

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

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

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


基調講演1「ソフトウェア工学における問題提起と機械学習の新たなあり方」工藤卓哉【機械学習工学研究会 キックオフシンポジウム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!

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