読み書きプログラミング

日常のプログラミングで気づいたことを綴っています

ChromeでTwitterサイトをアプリっぽくする

WebApp

Twitter for Macの提供終了が発表されました。

Mac版公式Twitterアプリ、突然の提供終了 - ITmedia NEWS

iMacでTwitter for Macを立ち上げて、画面の左側に幅を最小にしていつもTLを楽しんでいる私としてはとても困りました。
なのでChromeでTwitterサイトをアプリ風にすることにしました。

1. Twitterサイトを小窓でオープンする
このためには、ブックマークレットを使います。具体的には以下のURLのブックマークを作ってください。

javascript:(function(){const win=window.open('https://twitter.com/','twitter','left=0,top=0');win.resizeTo(446,screen.availHeight);}())

446というのはTwitterサイトのレイアウトに合わせたマジックナンバーです。

これだけでは表示がずれてイケていないので、今度はTwitterサイトのレイアウトを変えます。このためにはChrome拡張を使います。

2. Twitterサイトのレイアウトを変える
フォルダを作って、以下のファイルを用意してください。

manifest.json

{
  "name": "Twitter",
  "version": "1",
  "manifest_version": 2,
  "description": "App-like Twitter",
  "content_scripts": [{
    "matches": ["https://twitter.com/*"],
    "css": ["mystyle.css"]
  }]
}

このマニフェストで、Twitterサイトにアクセスした時に、Chromeがmystyle.cssを流し込んでくれます。

mystyle.css

@media screen and (max-width: 446px) {
    /* トップ */
    .dashboard {
        display: none !important;
    }
    .global-nav .container {
        min-width: 100% !important;
    }
    .Icon--bird {
        display: none !important;
    }
    .wrapper,
    .content-main,
    .MomentsPage.MomentsGuidePage .MomentsGuidePage-content,
    .MomentCapsuleSummary--hero .MomentCapsuleSummary-details,
    .MomentsPage.MomentsGuidePage .MomentsGuidePage-capsules,
    .MomentCapsuleSummary {
        width: 100% !important;
        padding: 0px !important;
    }
    .modal {
        width: 100% !important;
    }
    .Gallery {
        font-size: 0px !important; /* .Gallery-contentがinline-blockで、タグ前のスペースが見えてしまってずれたように見えるのでサイズを0にする */
    }
    .Gallery-content {
        min-width: 0px !important;
        width: 446px !important;
    }

    /* プロフィール */
    .AppContainer {
        max-width: 446px !important;
        margin: 0px !important;
    }
    .u-lg-size1of4 {
        display: none !important;
    }
    .Grid-cell.u-size2of3 {
        width: 100% !important;
    }
    .PermalinkOverlay-modal {
        left: 0px !important;
        margin-left: 0px !important;
        width: 100% !important;
    }
    .permalink-container {
        width: 100% !important;
    }
}

2つのファイルを作ったら、Chrome拡張に追加してください。(追加の仕方は、ググると紹介ブログが色々出てきます)

3. 「新しいツイートを表示」を何とかする。
TwitterのトップページはTwitter for Macのように自動でTLを流してくれないので、ぼーっと眺めるにはこれをなんとかしたいです。がんばらなくてもそのためのChrome拡張がありました。

Chrome ウェブストアでrefresh twitterを検索

好みのChrome拡張を追加してください。
以上です。

Enjoy your Twitter life!

機械翻訳のオープンソース情報を集めます

追記
ここにたくさん集めてありました。https://github.com/jonsafari/nmt-list

  • Sockeye

URL: https://github.com/awslabs/sockeye
コメント: Sequence-to-sequence framework
プラットフォーム: MXNet

  • Fairseq-py

URL: https://github.com/facebookresearch/fairseq-py
コメント: Sequence-to-Sequence Toolkit
プラットフォーム: PyTorch

  • tensor2tensor

URL: https://github.com/tensorflow/tensor2tensor
コメント: generalized sequence to sequence models
プラットフォーム: TensorFlow

NodObjCを使ってNode.jsでPasteboardの画像データを取得する

JavaScript Mac

Node.jsでスクリーンショットを扱いたいことがあって、外部コマンドscreencaptureを起動してファイルを生成してそれを読み込むという処理をしていました。
ファイルの生成場所にはRAMディスクを使うなど高速化を図っていたのですが、やはりオーバーヘッドがあるようで、Pasteboardから直接コピーしてみたいと思いました。(screencaptureにはファイルではなくPasteboardにコピーするというオプションがあります)

早速ですが、以下がその関数実装です。

const $ = require('nodobjc');
const ref = require('ref');

$.framework('Foundation');
$.framework('AppKit');

const PASTEBOARD = $.NSPasteboard('generalPasteboard');
const CLASS_ARRAY = $.NSArray('arrayWithObject', $.NSImage('class')); //  $.NSImage('class')は何度も呼び出すとSegmentation faultを起こすので注意。なぜかはよくわからない
const EMPTY_OPTIONS = $.NSDictionary('dictionary');

function getNSFileType(format) {
    switch (format) {
        case 'tiff':
        return $.NSTIFFFileType;
        case 'bmp':
        return $.NSBMPFileType;
        case 'gif':
        return $.NSGIFFileType;
        case 'jpg':
        return $.NSJPEGFileType;
        case 'png':
        return $.NSPNGFileType;
        case 'jp2':
        return $.NSJPEG2000FileType;
        default:
        throw new Error('unsupported format');
    }
}

function getImageFromPasteboard(format) {
    const pool = $.NSAutoreleasePool('new');
    let result = null;

    if (PASTEBOARD('canReadObjectForClasses', CLASS_ARRAY, 'options', EMPTY_OPTIONS)) {
        const nsimage = PASTEBOARD('readObjectsForClasses', CLASS_ARRAY, 'options', EMPTY_OPTIONS)('objectAtIndex', 0);
        const rep = $.NSBitmapImageRep('imageRepWithData', nsimage('TIFFRepresentation'));
        const data = rep('representationUsingType', getNSFileType(format), 'properties', null);
        result = new Buffer(ref.reinterpret(data('bytes'), data('length'))); // poolをdrainするにはコピーが必要
    }
    pool('drain');
    return result;
}

exports.getImageFromPasteboard = getImageFromPasteboard;

結果ですが、screencaptureでPNGフォーマットで保存していた場合と比べて、PasteboardでBMPを取り出すと倍ぐらい速くなりました。TIFFフォーマットで取り出すのが一番速そうですが、Node.js側でTIFFフォーマットを扱ういいライブラリがなくBMPにしました。

今、screencaptureのマニュアルを読むと、保存フォーマットにBMPも選べるらしく、BMPで保存していたらどうだったか気になります。RAMディスクのファイル読み書きよりPNGのエンコード、デコードが重かったのかもしれません。

AlphaGo Zeroの研究開発に使われたリソースを見積もってみる

コンピュータ碁

表題の中身

2018/01/30 追記その３
私の「論文のTPUはTPU1を示す」説に対してDeepZenGo代表の加藤英樹さんから「Google の misleading にマンマと騙されている。TPUはTPU2である」というご指摘があったので、なぜこんなことになってしまったのかと思いながら、ケリをつけるために、思い切ってDeepMind社のDavid Silverさんにメールで問い合わせてみました。経過すること4時間、「self-playにはTPU1を使った」という回答をいただきました。
下記のAja Huangさんのプレゼンテーションでの2000TPUと合わせて考えると、1600シミュレーションは0.4秒相当であるという論文での記述はTPU1を1つ使った場合、0.4秒だと考えるとすべての辻褄がほぼ合います。

2017/12/06 追記その２
AlphaZeroの論文が出ました。そこには「5000個の第1世代TPU」と世代が明記されていました。第1世代TPUでCNNが評価できることがはっきりしましたし、AlphaGo Zeroでも第1世代だったと推測するのが自然かと思います。
ただ、その場合、下記追記の2000TPUでは済まない気がするのでちょっと不思議です。

2017/11/10 追記
AlphaGoの開発者のお一人Aja Huangさんのプレゼンテーションによると、2000TPUを使って自己対局を行ったようです。
sports.sina.com.cn
記事にはTPUバージョンの情報はありませんが、2000TPUで済んだということはTPU v2だったのかもしれません。

AlphaGo Zeroの研究開発にどのくらいのリソースが必要になるのか気になったので見積もってみました。

AlphaGo Zero本体のリソースは論文に「Google Cloudのシングルマシンと4TPUs」と明記されています。
TPUは現在、v1とv2があり、かなり性能が違います。v1は8ビット整数で92TOPS、v2は180TFLOPS(singleかhalfか不明)です。論文にはどちらのTPUを使ったかは記述がありませんでした。

同論文でAlphaGo Leeのハードウェアは48TPUを使った分散マシンという記述があるので、このTPUはv1を示していると思われます。
The Registerの記事"How DeepMind's AlphaGo Zero learned all by itself to trash world champ AI AlphaGo • The Register"ではTPU1だと明記されていました。真偽の程はわかりませんが、辻褄が合うのでTPUはv1という仮定で考察を進めます。(脚注1)

まず、20ブロックのバージョンについて、論文に1手0.4秒(正確には1,600シミュレーション)の自己対戦を3日間で490万局行ったとあります。
3日間で490万局なので1局53msです。仮に1局の手数を300手と仮定すると、1手180usとなります。(300手は作り碁としては一般的ですが、ランダムな碁の場合、かなり控えめな数字です)
1手0.4秒を1手180usで実現するには、約2300並列が必要です。
1手０.4秒は4TPUでの数字なので、1手180usのためには約9000TPUが必要となります。

ここまでの結論として、

20ブロックAlphaGo Zeroの自己対戦には、少なくとも、約2300のGoogle Cloudシングルマシンと約9000のTPU v1のリソースが3日間必要だった。


続いて40ブロックのバージョンについて。
論文に40日間で2900万局行ったとあります。1局約120msです。20ブロックの場合のほぼ倍なので、同じリソースで1,600シミュレーションをそのまま使った(1手0.8秒相当)と想像します。

したがって、

40ブロックAlphaGo Zeroの自己対戦には、少なくとも、約2300のGoogle Cloudシングルマシンと約9000のTPU v1のリソースが40日間必要だった。

上記の考察は自己対戦のみで学習に必要なリソースは含まれていません。こちらは論文にある64GPUのハードで行ったと想像しています。

以上です。

(脚注1)
英語版WikipediaにAlphaGo ZeroのハードがTPU v2という情報が明記されていますが、リファレンスを見てもどこにもそのような情報はなく編集者の先入観と思いました。
また、TPU v1ではAlphaGo ZeroのCNNを評価できないというご意見も伺っていますが、素人の私にはAlphaGo LeeのCNNが評価できてAlphaGo ZeroのCNNが評価できない理由がわかりませんでした。CNNのサイズがかなり大きくなっていることは理解していますが。
こういう情報って、DeepMindに親しい専門家が一言確認してくれたらわかる話なんですけどねぇ。

AlphaGo Zeroの民生化の可能性について

TPU v1は8ビット整数で92TOPSで、これはCNNの評価の場合、70FLOPS相当になります。(以下のprediction比較を参考にしました)

cloud.google.com


4 TPUだと368TOPS、280FLOPS相当。民生最強のGPUは現在GTX-1080Ti(TITAN Xpは民生とは言えない…)で、単精度11.3TFLOPS、int8が45.2TOPS なので、int8を採用したとしても、GTX-1080Ti 8枚で少し届かないぐらいです。民生PCとなる日はまだまだ先か、それとももうすぐでしょうか。

rust-cudnnのcuDNN v6対応

2年ほど前にAutmunAIというヨーロッパのベンチャがRustで書かれたDeep Learning Framework "Leaf"を開発し始めて注目していました。
しかし、残念なことに1年ほど前に、TensorFlowのエコシステムの成長を見て「負け」を宣言して開発を中止したようです。
Rustによるフレームワークは速度の面で優位性はあったのですが、マイナーな言語というところが弱点だったということでしょうか。

学習フレームワークとしてはともかく、Rustはこれからシステムだけでなくバックエンドやアプリも記述する言語に成長していくと予想しています。その時、推論を使う機会は多々あるかと思うので、Leafの一部、rust-cudnnはRustプログラマに撮って貴重なものになると思います。
で、アップデートをしました。

https://github.com/y-ich/rust-cudnn/tree/bindgen


モジュール名が本家とぶつかるのでcrates.ioには公開していません。依存性はgitプロパティで指定してください。

bindingを手書きではなく、bindgenで生成するようにしたので、今後cuDNNのバージョンアップに対するメンテは比較的楽になるかと思います。

(macOSでcargo testを通そうと思うと、AutmunAI社の別のモジュールcollenchymaのlink attributeを修正する必要があります。)