もともと雑だった記憶がより粗雑になり、最後に icfpc にマジメに参加したのっていつだったっけ、車焼いたやつ？くらいの感じです。最近の icfpc は昔の言葉で言うとマラソンマッチ的、現代語で言うと AHC 的な印象を持っています。これらは今でも嫌いではないのですが、フツーに仕事でマラソンタスクがあって、時間がなくて取り組めていないという状況だと、ちょっと参加するモチベが湧きづらい、そんな感じです がまぁ今回は公式サイトから張られてる画像やリンクが、明らかに icfpc の伝説回であるところの 2006/2007 を参照しているので、期待があったのでした。いや、なんか、伝説回というの、好みや、当時と今のレベル差、僕自身の過去の美化、なんかのいろいろな効果が、あるとは思います。でも、それらを全てさっぴいたとしても、主催者が投下した労力という点で、 2006/2007 はここ20年で最大級の

https://peps.python.org/pep-0703/ Python の GIL 外す話。これすごく楽しい読みものでした。参照カウントのところが一番人気だと思うのですが、他のところも色々良い。こういう、「んーこういうことするとこういう問題が起きない？」と思ったら次の章くらいでそれが説明される、みたいな読みものは大変好きです 参照カウント: オブジェクトっていうのは作ったスレッドが解放するというのがほとんどなんだから、その場合はロックをいらなくする、他に渡ったら普通の参照カウントぽくする、という話。 Swift に 2018 年に導入された 話らしい。他のスレッドに渡された後で DECREF すると他スレッド用の参照カウントが負になりうるのだけど、その時に queue に入れるということをして、ややこしいので、なんかこれ無しですむ方法はないのかなぁ……と Immortalize

社会的に成功した人は、遺伝的に有利だったのか、環境が良かったのか、本人が頑張ったのか、犯罪を犯した人は、先天的になにかあったのか、教育や環境が悪かったのか、よくそういうことが気になります。ときどきその手のことを考えるヒントになりそうな本とかを読んでみたりしてたのですが、友人から教えてもらった本のおかげで、行動遺伝学というジャンルが、この手のトピックに科学的なアプローチで取り組んだりしているぽい、ということを知りました。というわけで、冬休みの自由課題的に色々読んだりしてみたので、なんか色々と書いてみます 結論から書いておくと、最初にあげたような疑問は、行動遺伝学を学ぶことによって完全に解決する、ということはなさそうです。ですが、いろいろわかっていることもある、考えるヒントになる、というあたりが収穫かな、と思っています 読んだもの Introduction to Human Behaviora

開発イテレーションを早くすれば、かなりの問題が勝手に解決される、と信じています。なんか最近、他の要素を軽視しすぎていたり、特にイテレーション速度に影響しなさそうなことすらしている気がしていて、信仰とかのレベルかもしれない、という気がしてきたので、ちょっと書いてみようかなと。主に C++ の話です。 仕事とかしてると良い判断力が求められたりしますが、判断というのは結構難しいですよね。アプローチ A と B で悩んだ時に、手が速ければ両方できたりします。開発イテレーションを無限に速くすると、必要とされる判断力はゼロに漸近していきます。やったね。 2手で変更の正当性を高速に確認できるようにする make (かその他のビルドコマンド)てやったらビルドができて、 make check (かその他のテストスクリプト)てやったら遅くないテストが全部走る、という体勢が好きです。試すためにはあっちのディレク

20%ルールという仕組みの雑談になって色々考えていたことを思い出しました。 僕はこう、20%ルールがあまり好きじゃない。まず、時間が細切れになって効率が悪い問題というのがある。「20%ルールのおかげでイノベーティブなプロダクトが生まれた」というのは、イノベーティブなアイデアにも関わらず100%の時間をそこに費やすことができなかった、ということなんじゃないか、と思ってしまう。1ヶ月で実現できたはずのアイデアに、単純計算で5ヶ月かかるわけで ここで、僕の好きじゃないスタイルの20%ルールは、金曜日は20%、他はメインのプロジェクト、というスタイルのやつに限定している 好きなスタイルとして、 http://shinh.hatenablog.com/entry/2016/03/11/142748 に書いた「半年メインプロジェクトに集中してた僕ですが、なんかやってみたいことができました、1ヶ月時間こ

転職してからやってるプロジェクトについて何か書いてみようかと思います。 https://github.com/pfnet-research/chainer-compiler/ 公式ぽいブログも書きました。 https://research.preferred.jp/2019/01/chainer%E3%83%A2%E3%83%87%E3%83%AB%E3%81%AE%E3%81%95%E3%82%89%E3%81%AA%E3%82%8B%E9%AB%98%E9%80%9F%E5%8C%96%E3%80%81%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4%E3%81%AE%E7%B0%A1%E4%BE%BF%E5%8C%96%E3%80%81/ あまり綺麗にまとまった文章を書ける気がしないので、つらつらと時系列で思い出して行こうかと思います。 転職前、 define

無職なこともあり、とても楽しい問題だったこともあり、久々にほぼガチで参加してる会になりました。いや楽しかった。順位表が凍結された段階での最終順位は2位で、1位は絶対に無理、その後にできた変更はしょうもないので、おそらく7位とかそのあたりの、5位強みたいなところに落ちついているのでないかと想像してます。暫定2位といっても特に良いところはなく、得点を決める式のおかげで、大幅なとりこぼしが無いだけで、推定1位のウナギに対して全順序がついて負けてる形のはずで、大変くやしい。が、まあ僕的には頑張ったとは思う。 初動 パーサやシミュレータを実装して、簡単なシングルスレッドAI、下から順に塗っていって、既にあるブロックとつながっていないところに置かざるを得なくなると、 Flip する、というものを Ruby で書く。デフォルトよりは大幅によくなることを確認して、いい問題だなあ……と思いつつ、寝る。 シミ

6月14日がグーグル最終日でした。8月からPFNに混ぜてもらう予定です。退職や入社も重要イベントなんでしょうけど、転職活動それ自体が大変に楽しい体験だったので、入社したからって突然次の会社についての知見にあふれているわけでもなし、このタイミングでなんか書こうと思いました。どうせ暇だし。 前回との差分 http://shinh.hatenablog.com/entry/2016/03/11/142748 が前回までのあらすじ。このちょっと後で、「ニューラルトランスレートすげー」とか思って Google Translate のチームに入れてもらって、自然言語/機械学習研究入門+プロダクショナイズ+TensorFlowまわりのあれこれおもしれーとか、その他いろいろをやってた、というのが現在との差分です。 機械翻訳というのは、他の機械学習応用分野と同じく、ニューラルさんによってすさまじく簡略化され

MJIT というのが Ruby に入ったのは聞いていて、すごいことするな、と思ってたんですが、実際に Ruby Kaigi で話を聞けて少し遊んでみたくなったのでした。そういえば https://turingcomplete.fm/5 の時に「MJITについてどう思うか聞いておいて下さい」とかリクエストしておいたのに聞いてくれなかったのであった。 https://k0kubun.hatenablog.com/entry/ruby26-jit すごいことするな、と思ったのはその手法で、 C 生成して dlopen という、よく雑談とかで言う話ではあるけど、実際広く使われる用途で使われたのは見たことが無かった(ICFPCとかでは見たことがある)ので、すごいなと。 一方で、 dlopen たくさんすると、いくつかの意味でオーバヘッドがかかると思われるため、あとでマイクロベンチに出ないところで大変

https://turingcomplete.fm/19#t=26:39 で僕のやったことに言及してくれて、「使ったスタックを消すなにかを浜地が作ったが、それは全く公開されていない」という趣旨の事が言われていました。でも実際のところなんか書いたけど、単に誰も興味を持たなかったというだけのことでした。 http://shinh.hatenablog.com/entry/20130728/1374990526 実際はclang pluginで、かつすごく適当にでっち上げただけで、効率は完全度外視だし正しく動いてるんだかもよくわからない、って感じでした。クラッシュはしなかったくらいの何か。当時の記述はすごい適当ぽいので、2点書いておきます。 当時のモチベーション 保守的GCが「やや病的なケースでポインタに見える整数値の参照先を残してしまう」てのはよく聞くわけですが、Rubyのバグかなんかで見たの

https://beta.atcoder.jp/contests/wn2017_1/standings むっちゃ僅差で2位。残念。この212点差がどのくらい僅差かというと、最後にいじってたところにもう2行変更を入れることを思いつけていれば、軽く2000点は差がついて勝ててたと思いますし、そうでなくても後30分もあれば実装できた細かいヘッダの圧縮で逆転できた量です。自分に悔しがる気持ちというのがこれほど残ってたのか、と驚くほど悔しいです。でも勉強になったし楽しかったです。 やったことを書きつつ、そもそも圧縮アルゴリズムについて、私としては感動的だった知見を得られたので、書いてみようかと思います。 今回のコンテストは、チャンネル1つの(RGBじゃなくてグレースケールだと思えば良い)画像を64枚を可逆圧縮するというものでした。その64枚の画像は同じ座標について光の波長と時間を変えて気象衛星が観測

https://connpass.com/event/64632/ すごく面白かった。最近こういう会に行って感心することは多いのだけど、しかしなんか書きたいと思うレベルになかなか来ない、まあそれなりに年喰ったしな、とか思ってたんですが。低レイヤとか、自分がある程度既に知ってるところの話を聞くのも楽しいけど、自分が最近勉強してて理解しはじめたことの話を見聞きする方が楽しいよねえということかと思いました。まさににわかほど語りたがる現象で、実際懇親会とかで間違ってること結構言ってそうな気がする。 ジャンルとして、他のCSのジャンルとかと違って、深層学習はとにかく論理的に確定できない話が多くて、あの論文はあやしいなあ、あれは説得力あるなあ、というような、口コミベースの情報が回してる面が、良くも悪くもあるのかなあ、という印象を持っています。 つーわけで口コミレベルの適当なことを、以下、書きます。(定

だいぶ前に左右反転させてもだいたい同じに見えるコードを書いたのですが、もうちょっと進化させて、上下反転と、180度回転してもだいたい同じように見えるコードを書いてみました。 デモサイト: http://shinh.skr.jp/obf/very_symmetric_js.html コード: https://github.com/shinh/hack/blob/master/very_symmetric_js/very_symmetric.js 普通のJS記号ゴルフと比べるとクォートが無いのが多少めんどくさく、あとは左右は一行コメントがあるから簡単なんですが、上下反転と180度回転のコードをコメントですっとばすのがパズルという感じでした。何も考えずに実行するコードの最後に /* と入れただけだと、180度回転した部分に */ が現れてしまってコメントが終わってしまうという。

オレオレワークフローエンジン作りたくなる病というのがあって、例えば make 系なんかだと Wikipediaに色々書いてあったりします。ワークフローエンジンと総称するのが正しいのか知りませんが、依存グラフを順ぐりに並列に実行していくようなもの、色々あるわけですけど、目的も粒度もバラバラですが以下のようなものは割と似たようなものに見えてます。 thread pool Tensorflow make Digdag 閑話休題。なんか微妙に10秒程度待ち時間があるような処理があって(クラウドストレージに対する例えば ls とか)、その ls の結果全てに対してまた10秒程度時間がかかるコマンドをまとめて実行、終わったら結果を集計、みたいなことをしたりすることが最近多いです。1週間から1ヶ月ほど10回とか100回使うんだけど、でもそのうち捨てる系のコード。私の場合、よくやる解決と問題点は shel

最近、 tanlog というのを作って使っていて、割と便利なので紹介してみます。 https://github.com/shinh/test/blob/master/tanlog.rb 元々は同僚と、なんか端末に出たもの前もって lv とか tee に入れておくのって、忘れることあるし、 lv とか tee に流すと isatty が false になって色出ないのうざいよねえ…みたいな話をしてたように思います。 grep については fake_isatty とか作ったりしたんですが、この時 soda さんに仮想端末作ってやる方法があると教えてもらったのを思い出して、 script とかで記録しておいたら…とか話していました。 結果、その同僚は zenlog というのを作って便利になった、とか言ってたのですが、なんか Perl と bash 混じってるとか、コマンドの切れ目をプロンプトで教

はじめに 言語実装 Advent Calendar 2016 用です。 ELVMは、コンパイラをフロントエンドと中間言語とバックエンドにわけて、多言語多CPUに対応しよう……というようなLLVMの考え方を、パロディと言っていいレベルにまで単純化したものです。結果として実用性は全くないが、C言語から他言語へのトランスレータを極めて簡単に書け、 Brainfuck などのような難しい言語のコードもC言語を書くだけで生成できる、というようなことを主目的としています。 本当は ELVM のバックエンドを一つ足して、 Brainfuck とかのような難しいターゲットでなければ、こういう感じで手軽に足せますよーということを書こうかと思っていました。しかし、ありがたいことにそういう趣旨だったり、あるいはもっと難しいターゲットについても、既にあれこれと書いていただいたのでした。例えば Perl: http

Ruby の正規表現だけで Brainfuck インタプリタを作ることができました。正規表現の実行は =~ だけなので、ループなども正規表現の内部で実行してます。 https://github.com/shinh/hack/blob/master/bf_rb_reg/bf.rb つまりどういうことができるかというと、 BF_REG という Regexp と BF_SUFFIX という文字列定数があって、 bf という文字列に格納された Brainfuck のコードを BF_REG =~ bf + BF_SUFFIX で実行することができます。出力は $~['o0'], $~['o1'], ... に入っているので、 output = '' 256.times do |i| o = $~["o#{i}"] break if !o output += o end 的なコードで取り出すことができ

binjaの現地枠がギリギリ空いてそうだったので、入れてもらいました。思ったことは、みんなすごいなあ、ということと、これしんどいなあということ、ルールはともかくみんなでわちゃわちゃやるの楽しいなということ、あとまあなんと言っても俺ふがいないな、ってことでした。 今回はCTFの前日に優勝賞金2億円のDARPA主催のCyber Grand Challenge(以下CGC)というのが行なわれ、それで優勝したAIを含めて15チームで同じフォーマットで競う、という趣旨でした。CGCはELFベースにABIを簡略化してあり、いつものようにシェルコードを実行するまではやる必要がなく、 type 1: EIPを指定されたところに飛ばす type 2: 特定のアドレスにある、フラグページから4byte取り出す のいずれかを達成すればOK、というルールでした。 準備 準備の段階では、 bjmit という名前でバ

転職して7年が過ぎたというのを読んで気づいたんだけど、そろそろ入社後9年が経過したらしい。僕は結構長い期間をここで過ごしたことになるんだなと思った。ちょっと以前のことを振り返ってみようと思う。言うまでもないけどこれは僕の書ける範囲での個人的な感想と体験談であって会社の見解等を表しているものではない。 きっかけ わりと重要でない Borgチーム (の周辺) いつのまにやらBorgという名前を普通に言って良くなっている。嬉しい。まあ当時もぶっちゃけ、秘密だから出してないっていうよりは、単に誰もアカデミア的なキャリアに興味が無いから出してなかったんだと思う(私見)。 さて、当時Borgというかクラスタマネージメントのあたりでは、コンピュータのリソースて適当にたくさん使ってるけど、これ節約したらすっげー支出減ったりしない？みたいなのがホットで、なんかとりあえず色々な人々が色んなことをやっていた。い

https://github.com/shinh/maloader Linux で動く Mach-O loader を書いています。何ができるかというと、 Mac のバイナリが Linux でそれなりに動きます。今のところ、 gcc 、 otool 、 nm などの、いくつかのコマンドラインツールと、その gcc が生成した簡単なプログラムなんかが動きます。 Safari とか iTunes とかはもちろん動きませんし、動くようにしたいとも思ってないです。 仕組みとしては、引数に与えられた Mach-O バイナリを適当に読み込んで、指定された通りに mmap して、未定義なシンボルは linux の世界から探してきて再配置して、でエントリポイントに jmp する、と。まぁローダの説明そのまんまという感じです。 ローダはまぁ Mach-O のフォーマットが mach-o/loader.h か