「勉強会に行ってみた!」第27回「東京ruby会議」後編
event

「勉強会に行ってみた!」
第27回「東京ruby会議」後編

2016.06.24

「東京Ruby会議に行ってみた」前編では、rubyを使ったOSなしで動く最軽量mruby/c、分散ワークフローエンジン、最速ウェブサーバーの講演を紹介いたしました。 後編も引き続き、とってもユニークな講演をご紹介します。


(鯉渕 哲也)

■Ruby製NFCエミュレーター「Opt carrot」

「あなたの知らない超絶技巧プログラミングの世界」の著者である遠藤侑介氏。今回は自身が開発したRuby製NFCエミュレーター「Optcarrot」を紹介していただきました。正直なところ、Rubyといえば性能面であまり良いイメージがないので、そのRubyでNECエミュレーターってどうなんだろうと思っていました。
講演で早速デモを拝見。Ruby2.0で作成したエミュレーターを作動させてみると、20FPS前後しか性能が出ません。 うーん、やっぱり性能としては残念なのかなという印象です。

このOptcarrotは、「馬を走らせるための人参」という意味が込められています。「Ruby3.0はRuby2.0の3倍早くなる」と言われており、それに向けてのベンチマークとして開発したそうです。デモでは、Ruby2.0で20FPSですので、Ruby3.0にアップデートすることで60FPSを実現できるということですね。
もう一つ、Optcarrotを開発した理由として、どこまで早くできるか挑戦してみたかったとのことで、その最適化について詳しくお話していただきました。

こういったエミュレーターでは、ハードウェアの動作を擬似的にソフトウェアで実現するわけですが、ボトルネックはGPUだったそうです。通常のエミュレーター開発ではCPUとGPUをクロックごとに交互に実行するのがセオリーだそうですが、それではRubyだと3FPS程度の性能しか出なかったとのこと。そのため、CPUをGPUとの通信が発生するタイミングまで進めてからGPUに処理を切り替えて、CPUが処理したところまで追いつかせるという手法をとったそうです。

またGPUが画面を表示する際に、本来は画面が切り替わるタイミングで、screen bufferの全てのピクセルを更新するのですが、Optcarrotでは更新が必要なピクセルのみを更新することで処理数を減らし、性能を担保したそうです。

これ以外にも細かい最適化をしていますが、主にこの2つの最適化で、20FPS前後の性能を出すことができたそうです。この状態がデモのOptcarrotの状態ですね。ここまでの性能を出すまでにいろいろと工夫をされたようです。

ここからは通常の開発ではまずやらない最適化の方法で、Ruby2.0で60FPSを目指した手法を披露していただきました。

まず、可読性は著しく低下しますがメソッドの呼び出しを極力少なくすることで、40FPSまで達成。 以下のようにメソッド内の処理を直接書いてしまいます。

次に、グローバル変数へのアクセスも極力減らし、ローカル変数に切り替えます。

最後に、先ほどの説明でGPUの処理に移ったタイミングで、CPUで進めたクロック数分の処理をしていくわけですが、必ず3クロック分の処理を実行することが分かっているならば、if文でクロック数に応じて分岐処理を行うのではなく、予めその処理を実行してクロック数を進めるという手法を用いたそうです。

これらの3ステップを実行することで、Ruby2.0でも60FPSを実現できたそうです。

講演の冒頭で行ったデモを、この3ステップを実行したOptcarrotで実行すると、見事に60FPSで動作し、会場から歓声と拍手が起こりました。

もちろん、後半に紹介された3つの手法は、通常の開発で使用するべきテクニックではありませんが、プログラムの内部処理を熟知しているからこそできるテクニックであり、私としても非常に勉強になりました。Ruby3.0が待ち遠しいです。

遠藤氏の発表はこちらで公開されております。
https://www.youtube.com/watch?v=oD35gcGPGQc&feature=youtu.be

■Aaron Patterson 氏 「凄いコード」

Railsのコミッターで、RailsのWebスクレイピングとして有名な”Nokogiri"の作者でもあるAaron Patterson氏。最近、GitHubに転職されたそうです。今回の講演にあたり、Ruby会議の実行委員長である笹田氏に「凄いプログラムの発表をして欲しい」と言われたそうですが、「凄いコード」とはなんだろう?と疑問に思い、wikipediaで調べた結果、下記の2つのテーマを決めたそうです。また今回の講演のために秘密のトピックも用意したとのこと。

1. 素晴らしいコード
2. 恐ろしいコード
3. 秘密のトピック

一つ目の「素晴らしいコード」は、自宅に眠っている約8,000枚のマジック・ザ・ギャザリングのカードを市場データと照合するというユニークなプロジェクトに使うコードのお話。Aaron氏が所有しているカードをカメラで撮影し、その画像データを市場データと照合して、カードの価値を表示するプロジェクトです。

撮影機材は上記写真にある構成で、WebカメラをPCに接続しています。なかなか本格的ですね。
市場データはAaron氏がコードを書いて、あるサイトから情報を吸い出したようですが、実はjsonでマジック・ザ・ギャザリングの情報を提供しているAPIがあったそうです。Aaron氏はそれを知らずにコードを書いたらしく、会場の皆さんに、作る前にGoogleで調べたほうがいいよと助言。会場が笑いに包まれました。

API提供サイト
http://mtgjson.com/

画像認識で手持ちのカードの情報を取得します。Aaron氏はたったの8ステップだよと会場を笑わせておりましたが、実際はなかなか大変な作業だったようです。

まずカードを撮影ボックスの中に配置します。あとはRubyプログラムが画像イメージを抜き出してくれるのですが、行っている処理を要約すると下記の様な処理を実行しています。

1. グレースケール化(エッジ検出するための前処理)
2. エッジ(輪郭)検出
3. 一番外枠の輪郭を見つける
4. その輪郭の四方を取得する。
5. それを長方形に整える(透視変換)
6. イメージとして保存

この処理で保存されたイメージは以下のようになります。

綺麗に抜き出せています。ここまでのコードをRubyで書いたのは流石ですね。 抜き出したカードのイメージをハミング距離で計算し、一番誤差の少ないカードを判別するようにプログラムされています。

画面上では、以下のように配置されます。

一番左の画像がスキャンしたイメージ。そして右にある3つの画像が合致したと判断されたカードイメージになります。推測カードの3つすべてがスキャンしたイメージと一緒になれば、市場データのカードと一致したということですね。

カメラの焦点速度がだいたい4?5秒ほどかかるため、撮影に膨大な時間がかかったり、絵柄が同じだが違うカードが存在したりという問題もあったようですが、遊び心いっぱいで高度なプロジェクトでした。

二つ目の「恐ろしいコード」は、Aaron氏が開発したPhuby(フービ)というプログラムのお話でした。 なんと、RubyからPHPを使えるようにするライブラリーです。特に実質的なメリットは感じませんが、まさか、RubyからPHPを使うとは思ってもみなかったので、その発想に驚愕しましたね。
構造的には以下のようになっています。

C言語が中間コードの役割をしていて、Ruby、PHPにオブジェクトを再配置しているようです。railsでも動かすことができるそうです。Aaron氏が、なぜこのPhubyを作ったのか。それは、単純に「やってみたかった」からだそうです。 これはエンジニアとして非常に大事なことだと思います。Aaron氏も映画「ジュラシックパーク」の科学者の言葉を借りて「科学者は、可能なのか不可能なのかのみを考えていて、試す価値を知らない」と仰っていました。Phubyにしてもマジック・ザ・ギャザリングの市場データマッチングのシステムにしても、Aaron氏は「やってみたかったから作った」のです。これがエンジニアとして大事なマインドだと思います。「必要だから作る」もありですが、「作りたいから作る」ということも大事です!それをAaron氏の講演から学びました。
最後の「秘密のトピック」ですが、みんなが不思議に思うであろうコードを書いてみたそうです。

Homeopathic Optimizationsとは訳すと "ホメオパシーの最適化”ですが、これは講演後に調べて意味がわかりました。
ホメオパシーとは、200年前のドイツの医師ハーネマンが提唱した医療法で、同じ症状を引き起こす原因を薄めて与えることで、抵抗力を引き出し治療するものだそうです。
Aaron氏は、同じ結果を得られるコードを希釈(薄める)しても、やはり同じ結果が得られる魔法のプログラムを作ったそうです。デモを見せてくれました。

この"dilute.rb”プログラムは3524578という結果を返します。 そして、この”dilute.rb”を6倍に希釈するとコードがほとんど消えました。

それでもきちんと正確な結果を返します。どういうことでしょう?  会場から、「これはどうなっているんですか?」という質問がありましたが、Aaron氏は冗談めいた表情で「秘密です♪」と仰いました。 本当にどうやっているのでしょうね。これは私の予想ですが、コンソール上で希釈しているように表示させているだけで、実際のコードは希釈されていないのではないかと思っています。本当のところはどうなのでしょうね?
ユーモアたっぷりで非常に楽しい講演でした。

Aaron氏の発表はこちらで公開されております。
https://www.youtube.com/watch?v=x3UANgL98wk&feature=youtu.be

■まつもと ゆきひろ氏 新作プログラミング言語 「streem」

後編最後に紹介するのは、Ruby開発者のまつもとゆきひろ氏の講演です。Ruby会議であるにもかかわらず、Rubyについて話さないというところに度肝を抜かれましたが、今回は「日経Linuxライターまつもとゆきひろ」として、自身が現在開発中のプログラミング言語「streem」についてお話をしてくださいました。
この言語は、日経Linuxで連載されている「まつもとゆきひろの作りながら学ぶプログラミング言語」で教材として使用されているプログラミング言語です。 streemは、昨年の12月から開発を始めたプログラミング言語だそうです。公開するつもりはなく、バックアップのためにgithubのリポジトリに上げておいたら、ハッカーニュースに載って、多くのstarがつき、挙句の果てにはインタープリターのpull requestが送られてきて、いつの間にか動くようになったそうです。まつもと氏の影響力がいかにすごいかがわかりますね。
streemはその名の通り、ストリームに流れている処理を逐次実行していくスタイルのプログラミング言語です。

コンカレンシー重視の言語で、パイプを挟んで左にinput、右にoutputを書くイメージです。

「Hello world」のコードだと、このように書きます。

for文のようなループはありませんが、if文はあります。

FizzBuzzを書く場合は上記のようになります。 echo serverを立てる場合はこんな感じですね。やはりループはありませんが、eachはあります。

streemの詳しい文法や仕様については、ぜひgithubを見てみてください。 これからどんどん機能を充実させていくそうですよ。
https://github.com/matz/streem

そもそも、なぜまつもと氏が新たに”streem"というプログラミング言語を作り始めたのかを話してくださいました。
Rubyは多くのエンジニアが使うプログラミング言語に成長しましたが、それゆえ、自分がこうしたいという思いが実現しにくくなってしまったからとのこと。Rubyで勝手に文法を変えたら多くのエンジニアが大変な目にあいますよね。私もその一人です。だからこそ、まつもと氏は自分が自由に実験できる言語を作ってみたかったそうです。だから、あくまでも汎用言語は目指さないそうです。

まつもと氏は講演の締めくくりとして、「プログラミング言語をデザインするのってものすごく楽しいんですよ。しかもすごく勉強になる。皆さんも自作言語で楽しんでみて!!」と仰っていました。

まつもとゆきひろ氏の発表はこちらで公開されております。
https://www.youtube.com/watch?v=TnD8HPQl2Jg&feature=youtu.be

私は、Ruby会議には初めて参加したのですが,登壇したスピーカーの方たちが本当に開発を楽しんでいるようなのが新鮮でした。私自身、近頃は業務に追われて開発を楽しむ気持ちを忘れていた気がします。技術を楽しむ姿勢が、結果的に技術力を育むのでしょうね。

Ruby会議11。まさに"技術的好奇心を改めて呼び起こし、プログラミングの難しさ、そして楽しさを再発見する場"でありました。

原稿:鯉渕 哲也
株式会社DeNAでゲーム開発&mobageプラットフォーム開発を担当。2015年7月、フリーランスのエンジニアとして独立。現在は、さまざまな会社と関わりながらサービスの開発を行う。得意分野はRubyによるバックエンドシステムの開発。

http://dosukoikoi.com/

この記事はどうでしたか?

おすすめの記事

キャリアを考える

BACK TO TOP ∧

FOLLOW